Which branch are you using? Newer branches (Marshmallow+) use LOCAL_CXX_STL
to chose a STL for non-NDK modules (LOCAL_NDK_STL_VARIANT for NDK modules).
In Lollipop, you could include external/libcxx/libcxx.mk for libc++
- Dan
On Fri, Jun 3, 2016 at 8:27 AM Michael Robbeloth
TARGET_ROOT_OUT_SBIN would put that executable in /root/sbin,
which is the root ramdisk, not the system partition. There isn't a
/system/sbin, we just put everything in /system/bin.
- Dan
On Sat, Feb 18, 2017 at 8:15 AM 'Ryan Philips' via Android Building <
android-building@googlegroups.com>
You don't need to use USE_MINGW anymore, the build system understands how
to do host cross-compiles natively now. Just doing 'mma' in
system/core/fastboot will build both the linux and windows versions. You
could also use:
m -j8 host_cross_fastboot
As the most similar command to what you were
Try removing `USE_CLANG_PLATFORM_BUILD := false` so that you're building
with Clang instead of GCC. All the AOSP devices that I checked are building
with Clang by default in android-7.0.0_r1, and the default for that
variable if unset was switched to true.
On Wed, Oct 26, 2016 at 10:01 AM
You'll need this change to build with 10.12:
https://android-review.googlesource.com/c/297536/ (I just submitted it a
couple hours ago, so syncing again should work)
- Dan
On Mon, Oct 31, 2016 at 2:52 PM 'Burkhard Mittelbach' via Android Building <
android-building@googlegroups.com> wrote:
>
I’ll be submitting https://android-review.googlesource.com/286781 shortly
in order to move the `build` project to `build/make`. This will only affect
the master branch.
-
If you don’t have any local changes to the build project, just sync like
normal, everything should just work.
The instructions on how to download repo are in the link in Glenn's
message: http://source.android.com/source/downloading.html#installing-repo
- Dan
On Fri, Jan 13, 2017 at 11:29 AM Jamie Jackson
wrote:
> Where do I get a fresh copy of the repo? I def found the
It looks like you ran out of space on /tmp:
failed to write to output: No space left on device
- Dan
On Tue, May 2, 2017 at 4:09 PM Nate Robbins wrote:
> Hi! I synced AOSP 7.1.2 r_8 for my Nexus5X (bullhead) and I ran make -j6.
> It completed sucessfully. However, then
+Tao Bao
You should be able to build that with 'm
-j out/host/linux-x86/framework/dumpkey.jar' (or 'm -j dumpkey'), it's a
bug that it wasn't built automatically though.
- Dan
On Wed, May 3, 2017 at 12:15 PM 'pierre taillard' via Android Building <
> FAILED:
out/target/product/hikey960/obj/STATIC_LIBRARIES/libedify_intermediates/parser.cpp
> /bin/bash -c "prebuilts/misc/linux-x86/bison/bison -d
--defines=out/target/product/hikey960/obj/STATIC_LIBRARIES/libedify_intermediates/parser.h
-o
It looks like bison is looking for `m4` in your path, so you'll need to
install it with apt. We don't currently have a prebuilt of m4 to go along
with the bison prebuilt.
- Dan
On Thu, Oct 19, 2017 at 4:12 AM, Marco Tommolini
wrote:
> HI, I'm trying to buid an AOSP and
You're missing the 'm4' tool, which we currently require to be installed on
the host system. This should be fixed if you follow these instructions:
https://source.android.com/setup/initializing#installing-required-packages-ubuntu-1404
- Dan
On Sat, Nov 18, 2017 at 9:33 PM, Yathavan Parameshwaran
Please don't do that, your build will fail in some other way, since that
check is there to ensure that the two build systems agree about options
that they both need to use.
On Sat, Dec 9, 2017 at 12:58 PM, Blaze Ristov
wrote:
> In the file
Somewhere in your modifications or device configuration you're setting
TARGET_GLOBAL_CFLAGS to "-DNO_SECURE_DISCARD". We no longer support setting
target-specific global cflags -- in the vast majority of cases it's not
necessary, and should be set for just the components that are interested in
it.
> This means that in my current opinion, the software environment is the
same except for hardware (VMware vs. Bare metal).
I don't recognize the above error, but this difference is strange. Is the
source on the same type of filesystem in both cases? I know there have been
issues with a few
Yeah, subdirs is likely the issue here. In master, we do a full search of
all Android.bp files (ignoring subdirs), which would avoid this problem.
- Dan
On Fri, Jan 19, 2018 at 12:43 PM, Wesolowski, Krzysztof <
krzysztof.wesolow...@volvocars.com> wrote:
> Android.bp uses glob patterns instead
It looks like there was a typo in device/generic/car/vendorsetup.sh. The
other files in that directory don't have the "emu_" part, so try `lunch
aosp_car_x86-userdebug`.
- Dan
On Wed, Jan 31, 2018 at 10:23 PM, Henri Hildebrand <
henri.hildebr...@gmail.com> wrote:
> Yes, I selected the
Which branch is this? This works fine on master for me.
`mma` should work, but running `m -j out/target/common/obj/JAVA_
LIBRARIES/metrics-helper-lib_intermediates/link_type` once should fix this
particular error (there may be more behind this though).
I wouldn't expect `mma` to take 10x as long
I'm not sure, but I suspect your SONAME is incorrect in your shared
library. Make sure that you've specified -Wl,-soname,libmyLibrary.so (or
equivalent) when building your library.
- Dan
On Mon, Feb 26, 2018 at 10:50 AM, Vasishath Kaushal
wrote:
> I dont know if this
LOCAL_ADDITIONAL_DEPENDENCIES can be used to add additional dependencies
that must be built before anything in the current module is built. So
something like this:
LOCAL_ADDITIONAL_DEPENDENCIES := $(HOST_OUT_SHARED_LIBRARIES)/LLVMPlugin.so
- Dan
On Wed, Aug 15, 2018 at 8:58 PM Yibai Zhang
It appears to be a bug in the kernel makefiles, not mkdtimg itself.
Specifically here:
https://android.googlesource.com/kernel/msm/+/android-8.1.0_r0.31/scripts/Makefile.lib#327
`stat` takes different arguments on Mac and Linux.
The kernel builds are really only tested on Linux, so you may have
It's an experimental configuration for building host tools using bionic
instead of relying on the host glibc. So the Android.bp files have
linux_glibc and linux_bionic to differentiate options that need to be
different between the two.
- Dan
On Mon, Sep 10, 2018 at 11:11 AM bx L wrote:
> Hello
Have you run `mma` successfully before running `mm`? `mm` can really only
handle rebuilds, since it doesn't attempt to build any required
dependencies.
- Dan
On Mon, Mar 12, 2018 at 7:05 AM wrote:
> On Android version 8.1.0 project specific build with mm cmd is
I do have some documentation posted on how to debug slow issues like this:
https://android.googlesource.com/platform/build/soong/+/master/docs/perf.md
-- It can definitely be caused by $(shell) commands in Android.mk files,
but from the first log here, you may also be hitting a known issue:
If you're actually using AOSP, and only AOSP, that library does not exist,
so no.
- Dan
On Wed, Apr 11, 2018 at 9:04 AM Shikhar wrote:
> Thanks for the reply. Are you saying it's not required while building AOSP?
>
> On Sunday, April 8, 2018 at 3:19:18 AM UTC, Dan
I've uploaded
https://android-review.googlesource.com/c/device/linaro/hikey/+/670443 to
fix the WITH_DEXPREOPT issue. After that, the build completes successfully
on my mac.
the compilation failed for me too, but for a different reason:
> there are places where "linux" is hardcoded in some
This is the failure from that log:
Out of memory error (version 1.3-rc6 'Douarn' (441800
> 22a11d4b264ae70e366aed3025ef47362d1522bb by android-jack-t...@google.com))
> .
> Java heap space.
> Try increasing heap size with java option '-Xmx'.
The root problem here is that you don't have enough
No, keep prebuilt APKs in an Android.mk for now -- it's safe to have both
an Android.mk and Android.bp, even in the same directory.
In general we've kept most prebuilts in Make for now, unless they're
depended upon by something in Soong. For the prebuilts that we do have, we
mostly just pass them
It sounds like this is this bug: https://issuetracker.google.com/74084489
(there are some patches linked that you could try)
- Dan
On Mon, Mar 26, 2018 at 8:16 AM wrote:
> Hi Dan,
>
> thanks for looking in to this.
> Attached is the full output of the mma command at the
Generally it's a good idea to use the tools paired with the branch. But in
ccache's case, the binaries are the same for M, N, O, and newer. With the
build system you're always going to use the ccache binary paired with the
tree anyways -- you just set USE_CCACHE=1. The only time you'd use the
What version of Android are you trying to build? This has been fixed on
master, older versions generally aren't supported on new Mac versions
(there's a range check for compatible SDK versions, but this is a runtime
issue, so that may not catch it).
- Dan
On Wed, Mar 21, 2018 at 7:04 AM Suyash
There was a typo in the shell script used to create that lunch menu.
Directly use `lunch aosp_car_x86_64-userdebug` instead (without the _emu).
- Dan
On Wed, Mar 21, 2018 at 7:04 AM Birender Singh
wrote:
> Unable to compile any of car emulator.
>
> You're building
>
> "apt-get install ia32-libs git gnupg flex bison gperf build-essential zip"
E: Package 'ia32-libs' has no installation candidate
>
My experience with this error is that your system is set up as 64-bit only.
That's currently not supported to build android, we still execute some
32-bit
For the master branch on AOSP, you need the preview blobs, not the ones
from PPR2: https://source.android.com/setup/build/requirements#binaries
For your 9.0.0_r10 build, why do you have a hardware/qcom/sdm845.mk file?
Is it left over from a previous checkout?
- Dan
On Mon, Oct 29, 2018 at 7:33
Yes, you should be able to share them across branches. We used to do this
on our builders, but we removed ccache from our builders (and master),
since it was causing more problems than it was saving in time. Incremental
builds are a bigger win (they've been increasingly safe with newer
versions,
It sounds like you're using at least some of the code from Oreo, but didn't
take the repo manifest updates that added entries to put those
back into place. Which may mean that you're also missing new projects, or
still have projects that have been removed as well.
- Dan
On Wed, Sep 19, 2018 at
Download the source and set up your machine as described on
https://source.android.com/setup/build/requirements
Basically, do everything up to the "lunch" step, then use "tapas" instead:
$ tapas LatinIME arm64
$ m
The APK will be
in
I'm not sure anyone is using the systemtarball functionality anymore,
especially with the lack of selinux as you've discovered.
Generally we put the prebuilt APKs as inputs into the Android build, since
they may be modified and transformed by the build (uncompress shared libs,
strip dex files,
To compile that
frameworks/base/services/core/java/com/example/sevice/myservice.java file,
you'd need to add your lib to the libs section of services.core.unboosted
in frameworks/base/services/core/Android.bp.
- Dan
On Tue, Sep 25, 2018 at 10:23 AM shankar kumar yellapu <
AOSP does not have a minimal manifest for Latin IME -- with enough work,
it's likely possible, but I suspect it would need at least 30-40 different
repositories (the build system, different compilers, dependencies, etc).
- Dan
On Fri, Sep 21, 2018 at 8:36 AM Vedant Roy wrote:
> Thank you so
The Settings app reaches into enough private APIs that you're going to need
a significant portion of the platform in order to build it. (It does not
build against the public SDKs)
- Dan
On Mon, Sep 24, 2018 at 8:11 AM BugWrapper wrote:
> Is it possible to build the settings apk individually ?
You'll need to define your prebuilt using java_import:
java_import {
name: "my-services",
jars: ["my-services-prebuilt.jar"],
}
You shouldn't need the my-services vs my-services-prebuilt differentiation
like you did with make.
- Dan
On Mon, Sep 24, 2018 at 8:11 AM shankar kumar
Just like anything else you want installed, put it in PRODUCT_PACKAGES,
either in the core build system's core product makefiles, or in your
product's makefiles.
I'm not sure why those builds are failing without more information -- at
least the normal SDK build is passing on our CI systems:
Ah, that's right. The SDK targets build with different TARGET_PRODUCT
values -- use sdk_phone_arm64-userdebug instead of aosp_arm64-userdebug.
It's nearly the same (and should be a quick incremental build), it just
triggers those missing files to be installed:
You can actually hold the timestamp stable in system/build.prop too, by
setting the BUILD_DATETIME environment variable to a stable value (it's the
number of seconds since the unix epoch, normally generated with `date +%s`).
Since we've focused on keeping the individual files identical while
You should be able to just run `m mkstubs` from any build configuration to
build mkstubs (as it's a host tool).
It'll be in out/host/linux-x86/framework/mkstubs.jar (or darwin-x86 if
you're on a Mac) once built.
- Dan
On Tue, Dec 18, 2018 at 1:46 PM
wrote:
> Hey there,
>
> I am rather new to
No, this is intentionally not supported by Android.bp. All Android.bp files
are always loaded.
First, instead of changing variable.go / soong_config.mk, we do have
extension points for user-defined plugins:
I don't believe the Soong transition is directly causing the increase -- in
fact, as part of the transition we've enabled a number of optimizations. In
addition to a growing codebase, the build has gotten more complicated,
especially as Treble has been isolating the system and vendor partitions
The hidl module types create new modules behind the scenes, and likely
aren't forwarding the notice property. Can you file a bug at
https://issuetracker.google.com/issues/new?component=381517 ? I can route
it appropriately.
Thanks,
Dan
On Thu, Nov 29, 2018 at 9:40 AM Sascha Effert wrote:
> Hi
This is an error within the go compiler. Which version of android are you
using, and what does `prebuilts/go/linux-x86/bin/go version` return?
- Dan
On Tue, Apr 2, 2019 at 8:51 AM wrote:
>
> when i build android code, found soong panic like this below:
>
> [ 49% 53/108] compile
>
In AOSP master, you should be able to set `min_sdk_version: "25"` in your
Android.bp (or `LOCAL_MIN_SDK_VERSION := 25` in an Android.mk). Older
branches you may need to do some workarounds with merging in another
manifest, but I think you'd only get the above error on master.
- Dan
On Tue, Apr
I definitely recommend upgrade to at least the 4.4 kernel that is/was
supported with 14.04:
https://wiki.ubuntu.com/Kernel/LTSEnablementStack#Kernel.2FSupport.A14.04.x_Ubuntu_Kernel_Support
We, and a number of other build farms hit a SIGBUS in the kernel rather
frequently with 3.13, upgrading
Had you downloaded the appropriate device blobs from here:
https://developers.google.com/android/blobs-preview ?
- Dan
On Sun, Mar 24, 2019 at 9:21 AM Yuan Zhou wrote:
> I am flashing the original AOSP master to my Pixel. I used many methods
> but still failed.
>
> I make AOSP used following
To run the emulator, you'll need to build for one of the
aosp_arm/aosp_arm64/aosp_x86/aosp_x86_64 targets -- aosp_blueline only
works with the real device.
- Dan
On Thu, Mar 28, 2019 at 8:35 AM wrote:
> build completed successfully (05:33:52 (hh:mm:ss))
>
> im running the emulator
I'm not sure what's happening here, but a few questions/comments:
What Android version are you using?
srcs: [
> "*.java",
> "*.kt",
> "**/*.java",
> "**/*.kt",
> ],
This will duplicate the list of java and kotlin files in the current
directory, since **
We don't maintain the -darwin group -- in general, if you have a manifest
that hasn't been carefully stripped down, you may need to specify
ALLOW_MISSING_DEPENDENCIES=true, but that may only push the error until
later in the build process (and won't work in this case).
In this case, it looks like
It looks like you need to install libncurses5 (sudo apt install
libncurses5), as that's the package that provides the 64-bit
libncurses.so.5 on Ubuntu 18.04.
Let me know if that fixes the issue and we'll add it to the instructions on
source.android.com.
Thanks,
Dan
On Thu, Mar 7, 2019 at 7:40
The behavior up until a few weeks ago was to build everything in
PRODUCT_PACKAGES for both host and device. I'm in the process of splitting
them up, but right now that means that you need to add them to both
PRODUCT_PACKAGES and PRODUCT_HOST_PACKAGES. I hope to fully disconnect them
this week, so
The ninja compilation database support doesn't work very well for our ninja
files due to kati using a rule per command. This upstream ninja feature
request may help, but that's assuming that whatever is parsing the compdb
files can understand the raw rules (which is usually a bash script, not
just
Which branch are you working on? verbose.log.gz is new in master(Q), before
then, the ckati info should be in soong.log.
I believe the persist-after-ctrl-c behavior should also be gone in master,
but I haven't done any extensive testing to make sure.
- Dan
On Fri, Mar 22, 2019, 6:49 AM wrote:
This forum is for discussing building AOSP, not custom ROMs, so I can't
help you with what missing. But decoding the error message:
ninja: error:
'/home/vamsi/ctos/out/target/common/obj/JAVA_LIBRARIES/sap-api-java-static_intermediates/classes-header.jar',
needed by
There's a manifest.xml in that project that should have all of the exact
revisions:
https://android.googlesource.com/platform/prebuilts/build-tools/+/refs/heads/master/manifest.xml.
It's a snapshot of the platform/manifest build-tools manifest
As I posted before: "Please don't do that, your build will fail in some
other way, since that check is there to ensure that the two build systems
agree about options that they both need to use."
- Dan
On Mon, May 13, 2019 at 12:36 PM Old3nglish 800 <0ld3nglish...@gmail.com>
wrote:
> Thank you,
Strange. Are you able to do regular builds of AOSP master on your machine?
(If not, don't worry, it's just a data point if you have)
What does the end of out/soong.log look like? That'll narrow down the
problem.
If you have a slow disk, the first time you run this, it may take a while
as it
It's easy to use prebuilt tools from the source directory (or built tools)
from your own rules that need them, either just refer to them by name, or
you may be able to set up your own directory to be added to PATH inside a
rule:
What version of Android are you using?
Which file did you change? There may be some missing dependencies.
- Dan
On Fri, Jul 12, 2019 at 5:13 AM xie doye wrote:
> I'm trying to customize the AOSP, And After compiled success once, I
> changed some selinux rule due to Android SElinux
What is your pre-build-script.sh script doing? Right now, since it has no
dependencies and no output files, you're essentially running it on every
build, even when the user is only trying to compile a single file in a
different section of the tree. That's deprecated since it has a huge
performance
No, there's nothing you need to do. vendor_available defines two
installations -- one into the vendor partition and one into the system
partition. To trigger the installation of the vendor version, you may need
to specify `m .vendor` instead of `m `
If you don't need both copies of the module,
1. Which version of Android are you building against? host_required is only
supported on AOSP master. Unknown properties are errors, as they're often
typos.
2. Including Android.mk files from Android.bp files doesn't make sense,
what are you trying to do?
We do forbid all path references that
proguard_flag_files was a typo -- it should be proguard_flag*s*_files. It
was fixed here:
https://android-review.googlesource.com/c/platform/build/soong/+/691330
- Dan
On Wed, Jul 31, 2019 at 11:32 PM jw wang wrote:
> Hi Google
>
> I'm coming across two similar build break after converting the
>
> And for me visibility property is not working, Is this available only on Q?
visibility is actually only available on master -- it was recently
implemented, and didn't make it into Q. That only lets you limit visibility
though, which it doesn't sound like what you're looking for.
Are there
Android 9 did not support the hwaddress sanitizer, I believe that support
is in AOSP master, and should be in the Q release.
- Dan
On Tue, Jul 16, 2019 at 9:08 AM H Sai Manikanta Eadapalapati <
saimanika...@eximiusdesign.com> wrote:
> I'm trying to boot the pixel3 xl with aosp hwasan build, for
Android.bp files must have all of their dependencies in Android.bp as well.
There is no way to work around that.
- Dan
On Thu, Jul 18, 2019 at 7:37 AM Amit Agrawal wrote:
> So In Android P, It supports both .bp as well as .mk. What if I want to
> compile a module which is in .bp format but it
Building the sdk generally requires using the 'sdk' product when calling
lunch -- it looks like that's why you were building a bunch of tools
independently.
I wouldn't be surprised if the sdk generation code didn't support
OUT_DIR(/OUT_DIR_COMMON_BASE) that was anything other than "out".
- Dan
; Here the xyz_defconfig is the file name which you might have found in
> AndroidBoard.mk.
> This is the usual way but I am not sure about the device you are using.
>
> ~Abhishek Dwivedi
>
> On Thu, Jul 18, 2019 at 10:01 PM 'Dan Willemsen' via Android Building <
> android-buildin
Have you read https://source.android.com/setup/build/building-kernels?
- Dan
On Fri, Jul 19, 2019 at 11:25 AM Saurabh Sakhare
wrote:
> Hello, I'm newbie in kernel development. I want to know where can I get
> pixel 2 kernel and Clang toolchain and commands. I've been trying to
> compile it
Those variables aren't exposed, partially because it becomes very difficult
to understand which pieces of the system are then product-specific vs
generic. Is there a reason why you wouldn't just read the runtime
properties rather than trying to embed those values in code?
- Dan
On Mon, Jul 15,
Use `mmma` or `m libdump` instead of `mmm`, at least once. I suspect that
will fix it up. Note that to be correct, you need to specify
LOCAL_SDK_VERSION := , since you compiled with the NDK.
- Dan
On Mon, Jul 22, 2019 at 6:11 AM FlamurBerisha wrote:
> Hello everyone, thanks for helping.
>
> I
All dependencies of an Android.bp file must be in Android.bp, not
Android.mk. So you'll need to convert your libmine description to an
Android.bp file.
- Dan
On Wed, Sep 18, 2019 at 1:51 PM Jack Rong wrote:
> I have a scenario that is to link in a Java static library built from an
> Android.mk
You'll need to execute conan before running the android build. It's not
enforced yet, but the source tree is expected to be read-only during the
build -- in particularly we start caching the Android.bp files nearly
immediately upon build startup, so adding new ones isn't going to work.
Nothing
How did you download it? Based on the banner, that's at least partially
master, not 9.0. A mismatched source tree could explain that error (or it
happened to be broken when you synced, and you should try syncing again if
you do want master).
- Dan
On Fri, Jun 28, 2019, 7:56 AM 岳羽
Which version of Android are you using? Starting in Android P (IIRC),
`subdirs` stopped doing anything, and we always load all Android.bp files
(nothing really gets executed when they're loaded -- they're just used to
build the action graph that we later execute). Depending on your use case,
+Anton Hansson who did a lot of this work.
If you're building a phone-like product, then yes, I believe using
handheld_* is appropriate (or maybe mainline_system.mk, which is the effort
towards a unified system image for multiple devices), though if you're
having to remove things, maybe using
If you check out/soong.log, there should be trace logs that include the
parent processes all the way up to ninja.
It sounds like one of the existing tools that we allow through is always
trying to call manpath? Let me know what you find, we've definitely been
shrinking this list on master.
- Dan
Pie was API version 28, so `BOARD_VNDK_VERSION := current` should give you
a v28 vndk. The v27 that comes with Pie is just the prebuilts so that you
can run older vendor images.
- Dan
On Mon, Nov 18, 2019 at 9:34 AM M.S. Mac-Donald
wrote:
> Hello,
>
> I'm trying to build AOSP branch:
It can still be the quickest way to download the least data to get an
initial tree. But you do lose all the history, uploads tend not to work
well, nor do cherry-picks, and the next download is quite possibly bigger
(even if it doesn't fail and you've got to remove and re-download that
project
that it's coming from bash itself. I've looked into the
>> local and system profile/bashrc and anything I could think of, but I can't
>> really pinpoint where it's coming from.
>>
>> On Mon, Nov 18, 2019 at 12:40 PM 'Dan Willemsen' via Android Building <
>> android-buil
We've recently updated our documentation around conditionals (and most use
of make variables fall into the same category):
https://android.googlesource.com/platform/build/soong/+/master/README.md#how-do-i-write-conditionals
tl;dr: we'd prefer you didn't use them, but if you need to, you can via
> 1. How fatal is it, do I need a machine running Ubuntu natively.
It's not fatal, the build should continue and work successfully. I know
that there are problems with docker-like systems (eventually tracking down
to some workarounds for a kernel bug -- turning off a lot of the security
helps,
Which branch are you using? `android_app_import` is the module type, but it
didn't make it into Android Q(10), it's only in master.
- Dan
On Wed, Oct 23, 2019 at 7:52 AM REGURI AKANKSHA
wrote:
> I tried above think, but I am getting Androidmk translation errors like
> unsupported include etc..
This was a bug -- the build failed when there wasn't a vendor partition
(which isn't a built configuration anymore inside Google to due Treble).
You should be able to cherry-pick
https://android-review.googlesource.com/c/platform/build/+/970728 to fix
the problem.
- Dan
On Mon, Oct 28, 2019 at
So the actual error that's blocking you is:
build/make/target/product/updatable_apex.mk:21: error:
> _nic.PRODUCTS.[[device/oneplus/fajita/lineage_fajita.mk]]:
> "vendor/oneplus/sdm845-common/sdm845-common-vendor.mk" does not exist.
But that's off-topic for this list, as Glenn mentions.
The
+Matthias Männich for further investigation
It looks like this isn't in the AOSP version of the kernel/build project
(or the internal master branch either, only some of the older branches that
never made it to AOSP).
- Dan
On Tue, Oct 22, 2019 at 9:08 AM 阿嚏 wrote:
> aosp kernel
Why does a header library need another module to be compiled first? It's
not actually compiling anything. I'm assuming you actually want to export
the dependencies that generated some header files? Depending on the full
compilation of a dependency will cause your builds to be more linear (and
thus
LOCAL_MODULE_PATH wasn't strictly necessary in make either -- if you had
set `LOCAL_PROPRIETARY_MODULE := true` like the `proprietary: true` in the
Android.bp, it would get installed into the correct location. The
`androidmk` tool tries to auto-fix some cases of LOCAL_MODULE_PATH, but it
can't
We don't allow references outside of the current directory and its
subdirectories in Soong. We require the directory with the sources to
opt-into being used by others, either by directly defining the modules, or
by defining filegroup modules that can be used in the src[s] fields via
":myfilegroup"
COPY_HEADERS is deprecated in Make, and unsupported in Soong. Use a header
library instead. That may require re-arranging your source tree, or
creating a directory full of symlinks, as we don't support rewriting the
directory structures the same was as COPY_HEADERS, you just export
everything
), but both would function.
- Dan
On Thu, Oct 17, 2019 at 3:08 PM REGURI AKANKSHA
wrote:
> Thanks,Dan I was able to tackle the above error. I am new to these things.
> Can u explain this filegroup with an example, like by defining some
> module, that would be really helpful
> Than
lution for this
> issue? How to convert APPS module class
>
> On Fri, Oct 25, 2019 at 12:30 PM 'Dan Willemsen' via Android Building <
> android-building@googlegroups.com> wrote:
>
>> Which branch are you using? `android_app_import` is the module type, but
>> it didn'
Where are you trying to use sub_dir? (which module type? at the top level?)
It's only supported on some of the prebuilt module types (and sh_binary).
For some other module types, relative_install_path is used instead
(cc_binary, cc_library, etc)
You can see the documentation about supported
1 - 100 of 227 matches
Mail list logo