Revert submission 2067907-apk-in-apex
Bug: 230873680
Reason for revert: Change broke aab generation b/230873680
Reverted Changes:
I9cef1418c:Append APEX version instead of build ID for APK-in...
Ic37eeba8b:Make apexer replace instances of version placehold...
Change-Id: Ib113d56901e815435f71bf878049cdabd210503c
This CL removes the build_id.mk suffix and replaces it with a hardcoded
placeholder string that will be replaced with the actual version in
apex_manifest.json by apexer at apex construction time.
This means that as long as the apex version is incremented, the
APK-in-APEX will be installed to a new directory path from the package
manager's perspective.
Fixes: 229574810
Bug: 229625490
Bug: 226559955
Bug: 224589412
Bug: 227417611
Bug: 228157333
Bug: 228803590
Bug: 229136249
Test: atest StrictJavaPackagesTest
Test: soong tests
Test: deapexer list out/dist/com.google.android.permission.apex
Change-Id: I9cef1418c3fc7e0970d96995b8398f5e82f479e0
This fixes an issue with package manager's cache invalidation.
Test: CI
Bug: 226559955
Bug: 224589412
Change-Id: I8af49d51ff99cf8184d0e4d1136fff1cdb29c23e
Merged-In: I8af49d51ff99cf8184d0e4d1136fff1cdb29c23e
When a library is included in two APEXes whose platform_apis settings
are different, two apex variants of the library is created: apex1000 and
apex1000_private.
This change was introduced with ag/15061306, especially by the commit
[1].
However, that part should be reverted because it actually creates
unnecessary variants. It's unnecessary because the two variants of the
library are compiled (excluding the linking) exactly the same. If a
private symbol of its dependency was actually used when compiling the
apex1000_private variant, then the other apex1000 variant wouldn't have
been built because that private symbol must have caused a linkage error.
[1] https://googleplex-android-review.git.corp.google.com/c/platform/build/soong/+/15061306/2..4/android/apex.go#b527).
Bug: 228785792
Test: m
Change-Id: Id58d3e98a51de5e628ca72ef86e9cd11b0ee8971
The proguard test files are duplicated in apex and sysprop and will
be needed by app tests, move them to the java package.
Test: run all soong tests
Change-Id: Ie13817dcda8d98801d16a97ffceef1100c7d5380
Override all mainline updateable apexes' min_sdk_version
to same version to get single shared native libs on DCLA.
Test: Run "vendor/google/build/go/mainline_go_modules_arm.sh" and inspect built apexes
Bug: 212609891
Change-Id: Ide7d3f2bc772ac6240f1c917b87285d051d6f605
Merged-In: Ide7d3f2bc772ac6240f1c917b87285d051d6f605
(cherry-pick of ag/17524387 into aosp)
Summary:
- updates the Q and R maps, the new keys are the bcp jars and not the
apexes. neverallow build rules ensure that these bcp jars have a
restricted set of permitted_packages
- remove BootclasspathJar from the neverallow rule. This is no longer
necessary since the keys in the maps are the bootjars themselves, and
not apexes
Bug: 205289292
Test: In build/soong, go test ./apex
Change-Id: Icb91de934181a8b6f085e03a0ce8c5e08504ff94
Merged-In: Icb91de934181a8b6f085e03a0ce8c5e08504ff94
(cherry picked from commit 440ff96728)
This reverts commit 1fdd6ca88a.
Reason for revert: b/205289292 tracks the real fix for this
Test: presubmit
Change-Id: I5a2edaf4f930dafa26659f85d9425e9041c72275
Merged-In: I5a2edaf4f930dafa26659f85d9425e9041c72275
Switch from generate-notice-files.py and mergenotice.py to htmlnotice.
Bug: 151177513
Bug: 213388645
Bug: 210912771
Test: m droid dist reportmissinglicenses
Change-Id: I6cac049d24f35ec358c6f341a04f4ba6161703bf
* changes:
Do not propagate strict updatability linting to libcore/
Create allowlist to skip strict updatability lint check
Propagate strict_updatability_linting to transitive deps of updatable apexes
Export LintDepSetsIntf from java package
The clang prebuilts now provide a single module with per-architecture
variants instead of a module per architecture.
Bug: 220019988
Test: m checkbuild
Change-Id: I39e2cf8ae14edf8510276dab38011afaef85822c
Merged-In: I39e2cf8ae14edf8510276dab38011afaef85822c
In addition to the current "apps", support overriding
bootclasspath_fragments, systemserverclasspath_fragments, and java_libs.
This is useful to build APEXes with slightly different contents, for
example where the base APEX could contain libraries that only use stable
APIs, but the overriding APEX could contain a variant that also uses
non-finalized APIs.
Bug: 222247869
Test: m (runs apex tests)
Change-Id: I14da6f835c58b44be31e517598695ec8ff830648
The primary boot image is a required dep of the ART APEX. It needs to be
installed no matter the APEX is flattened or not.
Bug: 220991677
Test: 1. m OVERRIDE_TARGET_FLATTEN_APEX=true com.android.art
2. See boot.art in /system/framework/<isa>
Change-Id: I1a69ae1b86df97fc44ea6c75c8bb9ec960c8d249
dependencies of rust library registered as jni_lib are correctly
tracked.
Bug: 220397949
Test: m nothing
Change-Id: I43016a77656d04f59f798b02d541c6a19288ec9c
propogation of this flag is determined by the location of the Android.bp
where a library is defined.
libcore/ libraries that are transtive deps of updatable apexes will
- inherit strict_updatability_linting:true if defined in libcore root
- not inherit strict_updatability_linting:true if defined in libcore
subdir
Note that the module can explicitly list `lint:{strict_updatability_linting: true}'
in their Android.bp file, in which case they will not be allowed to
baseline NewApi errors
Test: m lint-check
Test: TH
Bug: 208656169
Bug: 182349282
Change-Id: I4c373b2960a7af16301d7f06aab448f39b937ea9
Create a topdown mutator to walk the deps of updatable apexes. If a dep
is lintable, set its strictUpdatabilityLinting to true
Creating a new mutator after apexInfoMutator makes it easy to maintain
an allowlist (e.g. override_apex does not require an entry in the
allowlist, its canonical name can be retrieved using ApexVariationName())
Test: In build/soong/, go test ./apex
Test: TH
Bug: 182349282
Change-Id: I1b390b0e3a8fb20754ce50c6b253d68d2b3f263b
In case there are two vendor apexes(one with "use_vndk_as_stable:true",
and the other with "use_vndk_as_stable:false") a VNDK lib used by both
will have "APEX" variant and the former APEX will use "apex" variation.
For example,
apex1(use_vndk_as_stable) -> foo -> libvndk
apex2 -> bar -> libvndk
Since foo, bar and libvndk are mutated into two APEX variations("",
"apex10000"), foo will use the apex variation of libvndk.
To fix this, VNDK libs can use "unique" APEX variations. Then, in the
above example, foo will have "myapex1" variation and libvndk will have
two APEX variations("" and "apex2"). So foo will link to ""(non-APEX)
variation as fallback.
Bug: 216847402
Test: m nothing (soong tests)
Change-Id: I116932860ef79e22dc338a58b251e3ca693ab4f3
Even though a vendor APEX sets use_vndk_as_stable:true it was possible
to include a VNDK lib by directly depending on it with
native_shared_libs.
But it's contradictory to have a VNDK lib while declaring not to include
VNDK libs. It was missing since pruning dependencies on VNDK libs was
done only for transitive deps.
Added a check to reject this.
Bug: 216847402
Test: m nothing(running soong tests)
Change-Id: I8d79a434b1bfe8e563cf8968fa76830b0e582f66
Discourage jarjaring code where there are alternatives with
better system health implications.
Test: m
Bug: 215233995
Change-Id: I1b076d00e1ad6aa32b41da6bda1033978b5e829d
Currently, the bpf module netd.o (source system/netd/bpf_progs/netd.c)
will be built to /system/etc/bpf/netd.o. In Android T, it will be moved
to mainline module com.android.tethering.
The expected behavior is:
- In T device, it uses the netd.o in mainline module.
- In pre-T devices, it uses the original netd, built from platform.
However, netd.o will be double loaded if the tethering module is
installed in Pre-T devices. Because:
1. bpf in apex is packed into /apex/MAINLINE_MODULE/etc/bpf/
2. bpf in platform is packed into /system/etc/bpf/
3. bpfloader in pre-T loads ANY bpf modules under
/apex/com.android.tethering/etc/bpf/ and /system/etc/bpf/.
We can't change the behavior of bpfloader in pre-T devices. We can't
delete the /system/etc/bpf/netd.o from pre-T devices. Both of them are
not mainline modules. So the mainlined netd.o needs to be packed into a
folder other than /apex/com.android.tethering/etc/bpf/ or
/system/etc/bpf/.
This commit adds a tag 'sub_dir' for bpf module. The installation path
of bpf modules will be:
- /system/etc/bpf/SUB_DIR/ (for platform code)
- /apex/MAINLINE_MODULE/etc/bpf/SUB_DIR/ (for mainline module)
Bug: 202086915
Test: add test in apex_test.go and build
Change-Id: Icc6619768ab006de9f86620a7df1bb2853eaba13
After this change, `bootImageConfig.installDirOnDevice` can be set to a
path outside of the APEX, in which case, the boot image will not be
installed in the APEX. Instead, it will be installed to the given path
by Make.
This is a no-op change. Current behavior is not affected.
Bug: 211973309
Test: m nothing
Test: -
1. m com.android.art
2. See the boot image still being installed in the ART APEX.
Test: -
1. Change `installDirOnDevice` of the ART boot image config to
`system/framework`.
2. See the boot image being installed in `/system/framework/<arch>`.
Change-Id: Ib13b17cc9e94dc5754c9b51b04df3307323b8783
This change adds support for dexpreopting standalone system server
jars from prebuilts.
Bug: 203198541
Test: -
1. Add a standalone system server jar (e.g., by patching
aosp/1906158)
2. Build and drop a module SDK and an APEX.
3. Build a system image from prebuilts.
4. See the odex and vdex files generated in
$ANDROID_PRODUCT_OUT/system/framework/oat/
Change-Id: I8f4eaed10a1053cd560b8583efa12dc495f58db1
... in preparation for adding the support for custom canned fs config
Bug: 209971551
Test: m nothing
Change-Id: I7f2576ff99c65bdb6c9ce4ace61bc783eea2f0d4
The ART AOT exemption only applies to Q/R/S, so module jars that have
min_sdk T+ do not need to follow the module package restriction, even if
they are part of a Q/R/S module (but not loaded on Q/R/S).
Relax the restriction to only apply to jars that have min_sdk before T.
Bug: 208773835
Test: m (runs apex tests)
Change-Id: I2c3ad8984ca05ad763bf6162bd478f93ab4ee650
Inidividual boot or system server jars may have higher min_sdk_version
than the contianing apex, since the runtime respects the values of
min/max_sdk_version; e.g. runtime would not load a boot jar with
higher min_sdk_version. This allows shipping new boot jars via apexes
that target older platforms.
Bug: 190818041
Test: presubmit
Change-Id: I08ec0b4463a17bc8265b948fe09da55eb4e52ac3
Without these errors, the last encountered deapexer would silently be
used. However with PRODUCT_INSTALL_APEXES there will only be deapexer
for installable APEXes, and we can assume only a single installable
APEX exists for each APEX variant, so make it an error if it isn't the
case.
Corresponding to http://ag/15156931.
Test: m nothing SOONG_CONFIG_art_module_source_build=true
Test: m nothing SOONG_CONFIG_art_module_source_build=false
Test: m nothing SOONG_CONFIG_art_module_source_build=false
with installable:true for the com.android.art.debug prebuilt APEX -
check that it fails with an "ambiguous duplicate deapexer" error
Bug: 192006406
Bug: 192542393
Change-Id: I44566fd26b12f82a8a67fe4a69e56303460756d0
We will need the profile when we generate the primary boot image on
device.
Bug: 203492478
Test: Run `banchan com.android.art x86_64 && m` and see
`$ANDROID_PRODUCT_OUT/apex/com.android.art/etc/boot-image.prof`.
Test: Run `lunch aosp_cf_x86_64_phone-userdebug && m` and see both
`$ANDROID_PRODUCT_OUT/apex/com.android.art/etc/boot-image.prof` and
`$ANDROID_PRODUCT_OUT/system/etc/boot-image.prof`, in different
sizes.
Test: Start Cuttlefish with the built image and see both
`/apex/com.android.art/etc/boot-image.prof` and
`/system/etc/boot-image.prof` on device.
Change-Id: Id879dc49b234133dfbb9563814328661a1f4a6c0
Vendor APEXes do not formally support updates outside of the main OTA
process. We should clarify this at build time.
Test: set vendor apex to updatable, observe failure
Test: apex_test.go
Change-Id: Ife8d242a42415ebf00d7dced72c07cda1fde1839
The sh_binary module is not supported the vendor variant. So, even if
there is "vendor: true" in sh_binary module, the image variant is
"image:" instead of "image:vendor.Tiramisu".
But the vendor APEX has vendor variant, so vendor APEX module and
sh_binary module have different variants and the sh_binary cannot be
added to vendor apex.
So the Sh_binaries property is added, and the image variant is removed
at DepsMutator.
Bug: 205065320
Test: make -j40 && sh_binary is added to vendor APEX && install check
Change-Id: I30e2d96a73b45e7b06eff24550542cb010008c41
Perform consistency checks as per http://go/updatable-shared-libraries
These include:
* no attribute can specified can be less than T
* max-device-sdk can't be less than min-device-sdk
* min and max-device-sdk need to be at least the module's
min_sdk_version
* using on-bootclasspath-before implies that the module's
min_sdk_version is at least T or the library has min-device-sdk of at
least T
Test: m nothing
Bug: 191978330
Change-Id: Iaca5cf23fb0bc7e65effb3529c8e829560894c2e
Merged-In: Iaca5cf23fb0bc7e65effb3529c8e829560894c2e
(cherry picked from commit f9e584dd20)
We are expanding PackageManager's supported attributes and this change
enables the developer to define them in the .bp file.
Test: m nothing
Bug: 191978330
Change-Id: I01d579190fb585662086a7fc456f3b33cb89fb57
Merged-In: I01d579190fb585662086a7fc456f3b33cb89fb57
(cherry picked from commit 826863c8e0)
This CL fixes a bug that `required` property of apex modules is not
reflected to the generated Android.mk file.
Bug: N/A
Test: m nothing
Change-Id: I36ccf538882f083f9433bd3eb05b3a5127f3822b
