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
If the build file contains the apex_test module, add the
testOnly attribute to the application element of the
corresponding AndroidManifest file and set its value to true.
If the testOnly attribute is already present and has value
false, then do nothing.
Tests added in manifest_fixer_test.py to check if the updated
AndroidManifest file has the testOnly attribute set to true or not.
Bug: 213310150
Test: atest --host manifest_fixer_test
Test: m nothing
Test: manually checked the AndroidManifest file generated
Change-Id: I36247dbe0261c342d451a4422c314fd8fe0c2369
This change is similar to aosp/1947127, but for prebuilts.
After this change, if `bootImageConfig.installDirOnDevice` is set to a
path outside of the APEX, the build system will build a boot image from
the dex files and the profile extracted from the prebuilt APEX.
Otherwise, it keeps the current behavior: extracting the boot image from
the prebuilt APEX.
This is a no-op change. Current behavior is not affected.
Bug: 211973309
Test: m nothing
Test: -
On internal master:
1. Patch aosp/1947128.
2. Patch ag/16743847 and ag/16746804.
3. m SOONG_CONFIG_art_module_source_build=false com.google.android.art
4. See the boot image being installed in `/system/framework/<arch>`.
Change-Id: I24ca525309fecaf3ab7a67960fbf118cd00ecd1d
Bug: 214466457
Bug: 207551677
Test: b build //build/bazel/examples/apex/minimal:build.bazel.examples.apex.minimal
Test: b test //build/bazel/tests/apex:build.bazel.examples.apex.minimal_apex
Test: b test //build/bazel/tests/apex:build.bazel.examples.apex.minimal_capex
Change-Id: I6bf12c1b0c52d4486968bb430a67a3c3110766db
This is needed to allow the Android Go versions of modules
(com.google.android.go.*) to select a different compression toggle than
their non-Go (com.google.android.*) conterparts. go/go-updatability
Bug: 203024418
Test: Preloaded go variants on wembley, booted Android.
Change-Id: Ic96aff5fafb65fbd08e8a69d47c994532e27819e
Merged-In: Ic96aff5fafb65fbd08e8a69d47c994532e27819e
(cherry picked from commit 2c4a96375a)
As requested by reminv@, their team wants the source code in
sc-mainline-prod to be strictly the same as the code in AOSP. Therefore,
we need to ignore `standalone_contents` in the
`systemserverclasspath_fragment` module and
`systemserverclasspath_fragments` in the `sdk` module in order to merge
aosp/1925682 into sc-mainline-prod.
- `standalone_contents` in the `systemserverclasspath_fragment` module
does nothing but adds its contents as dependencies of the APEX.
- `systemserverclasspath_fragments` in the `sdk` module does nothing.
Bug: 203198541
Test: TARGET_BUILD_APPS=com.android.tethering vendor/google/build/mainline_modules_bundles.sh
Change-Id: I56ca22aa91a807cd113dfda2fabaeb49ecabe289
Merged-In: I09a6fd1d3db85c194330da9b751702a9bf069e26
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
Merged-In: Icc6619768ab006de9f86620a7df1bb2853eaba13
Change-Id: Icc6619768ab006de9f86620a7df1bb2853eaba13
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
The property is used to customize uid/gid/mode/capabilities of files in
an APEX.
Bug: 209971551
Test: m
Change-Id: I484e46ff819a5266c1e8046dae337e18ef3fefea
... in preparation for adding the support for custom canned fs config
Bug: 209971551
Test: m nothing
Change-Id: I7f2576ff99c65bdb6c9ce4ace61bc783eea2f0d4
App compact impact is hard to judge (see http://b/124106384#comment9
ff), so this tries it early in the dessert cycle.
This is also a workaround for b/209867137 where the symlink install
rules interact badly with the artifact_path_requirements.mk check.
Test: m installclean && m droid
verify that $(PRODUCT_DIR)/system/bin doesn't have dalvikvm and
dex2oat symlinks
Bug: 124106384
Bug: 209867137
Change-Id: I044fb40f656beeb7c6e61f1d418fa13f56714a70
Each conversion required defining a separate mutator, which will each
operate on _all_ modules and requires each to repeat checks whether the
mutator should operator. Instead, we introduce a single mutator and
modules can define a ConvertWithBp2build to implement bp2build
conversion for that module.
Test: bp2build.sh
Bug: 183079158
Change-Id: I99d4b51f441c2903879092c5b56313d606d4338d
