If a lib is directly included in an APEX (via native_shared_libs
property) and the lib has stubs (via stubs.versions property), then the
ordinary non-stubs variant of the library is renamed to
<libname>.bootstrap in the makefile. At the same time, the stubs variant
of the lib becomes visible and it's name is <libname>.
This ensures that modules in Android.mk build against the stubs
variant thus preventing them from using private APIs in the lib.
The non-stubs variant, however, is used if the module explicitly has
set the new 'bootstrap' property to true. This is useful for building
some early binaries (such as init and vold) which need to run before
APEXes are activated. Since they can't use the bionic libs from the
runtime APEX, they should use the bionic libs left in the system
partition which is called the boostrap bionic.
Bug: 120266448
Test: m
Test: m with https://android-review.googlesource.com/c/platform/bionic/+/849044
Change-Id: I882b8aeb5b29460f07b4424e4f8eb844d6c9a9b0
It is a list of <module_name>:<manifest_name> pairs. When the module
name of an APK or an APEX matches with <module_name>, then its app
manifest name is overridden to <manifest_name>.
<module_name> and <manifest_name> can be patterns as in
com.android.%:com.mycompany.android.%.release
Note that, in case of APEXes, the manifest name refers to the name of
the zip container. The apex manifest name (which is specified in
apex_manifest.json) is not overridden.
Test: m with PRODUCT_MANIFEST_PACKAGE_NAME_OVERRIDES for
1) an APK in Android.mk
2) an APK in ANdroid.bp
3) an APEX
and check that manifest names are modified as specified
Change-Id: Ie58882d90884695e893944c43d9c8803b283e93d
shouldUncompressDex has already been computed and stored in
deviceProperties.UncompressDex, pass it to dexpreopter instead
of recomputing it.
Also add a stub for java libraries to set UncompressDex.
Test: no change to build.ninja
Change-Id: I663d9fbbe768a8dc9a97c7d456dd7a010f43162d
This change fixes a bug where androidmk assumes all-*-files-under
function only takes one directory parameter.
Test: androidmk_text.go, manual execution
Change-Id: Ib1614a2ddde7ea1120c1c37126231988f4862165
Executables under /system/bin are configured as (uid:gid)=(root:shell)
by fs_config.cpp. Therefore, an executable that is moved/copied from
/system/bin to an APEX should be configured as such.
Test: adb shell ls -al /system/bin/linker
/apex/com.android.runtime/bin/linker shows
-rwxr-xr-x 1 root shell 1133528 1970-01-01 09:00 /apex/com.android.runtime/bin/linker
-rwxr-xr-x 1 root shell 1133528 1970-01-01 09:00 /system/bin/linker
Change-Id: Ibb698aab237362fed312da2af809cceead8a1092
Now java_import with a host flag set to true is converted to
java_import_host.
Bug: 122372359
Test: bpfix_test.go + manual test with real examples.
Change-Id: Ie38fa51a44c83c434927db4b742d6839c64b3d63
Modules shouldn't be dexpreopted and possibly stripped when
compile_dex is set but installable is not set. This matches the
previous behavior when the dexpreopt rules were in Make.
Bug: 121317615
Test: dexpreopt_test.go
Change-Id: I6f80b7b37a990c475b91aa5d98a19a3baa85eb1b
I6bb2c971cee65d2338839753aa0d84939f335b1b accidentally caused
java_test modules to be dexpreopted and possibly stripped.
Test: dexpreopt_test.go
Change-Id: Ida8f046c509c97e38bd3bce66944d32f01530db4
Add methods to TestingModule that return an empty BuildParams instead
of panicking, which can be used to test if a module has a matching
rule. Also add godoc to the TestingModule methods.
Test: m
Change-Id: Iea2ab9be57d3f3f60437041f4e5a7e2100e1fe48
Test: Dumped the text formated based metrics file to out dir,
and checked the file.
Bug: b/63815990
Change-Id: Iff476f72a0be74eb53b6b26ef468d11c0f24a404
This solves a problem where javac fails to find patch-module targets
when a build diretory is not under the project root.
Bug: 117770838
Test: java_test.go + manual build
Change-Id: If70d0d388a3f6c87b3f78a927df2063616d50c8a
Prevent problem for some users using PAR file built by android's
build system which cause by the different site package of python
installed by user themselves.
Bug: 120469915
Test: 1. m atest
atest --help
2. apply aosp/861470
full build
Change-Id: I72c83f9397f0e88eecfcd32806f1746520299447
.s files (unlike .S files) aren't run through the preprocessor, so -M*
doesn't actually write out a depfile.
Since our ninja is now going to be verifying that the depfile is created
(https://android-review.googlesource.com/861510), don't specify a
depfile for .s files.
Bug: 121058584
Test: apply https://android-review.googlesource.com/861510
Test: cd external/libavc; mma
Change-Id: I1697aa020c63639317c8f4771147026601ae72fc
This commit stops building lsdump files for APEX variants since APEX
variants are local to APEX modules themselves.
Bug: 121986692
Test: make findlsdumps # compare $ANDROID_PRODUCT_OUT/lsdump_paths.txt
Change-Id: I37fcd152d0d84d235a354ea53e53e808dd71464a
This commit renames `_platform` suffix to `` (empty string) so that
non-apex variations are not renamed to `_core_shared_platform` or
`_vendor_shared_platform`.
This commit makes sure that `_core_shared` and `_vendor_shared` is
always under `$OUT_DIR/soong` regardless the usages from apex modules.
Furthermore, this avoids the confusing stale lsdump files (e.g. both
`_core_shared` and `_core_shared_platform exist) while creating
reference ABI dumps for VNDK ABI checks.
Bug: 121986692
Test: lunch aosp_arm64-userdebug; make # no more _platform variants.
Change-Id: Ic02a60ac45f982580349661c22331d114617fd92
As tnorbye@ mentioned, the check-API comptibility needs the annotations
that were merged in so that the behavior will be consistent with
signature file.
Test: check the ninja file.
Bug: N/A
Change-Id: I0c06c838cf7ddfd43f583fc8c1b1ad999a4cc066
This CL fixes the problem that when a lib is defined with stubs, the
stubs variantof the lib is installed to the APEX. This was happening
because the non-stubs variant is the last variant of the 'version'
variants and addFarVariationDependencies selects the first variant when
the 'version' variant isn't specified.
Fixing the problem by making the non-stubs variant (whose name is "")
the first variant.
Test: m (apex_test)
Change-Id: I1505fd2f29a0d70c916bad51000aa06f2b80b137
When an apex key is marked as 'installable: false' and the build is
debuggable, the pubic key file for the apex key is bundled with the APEX
that is signed with the key.
This eliminates the need to install the public keys for the
testing-purpose APEX in the system partition.
Bug: 122047804
Test: m
Change-Id: Ifa5914891463dbf4c21484ea440836521b2f90b1
Jiyong Park