This change fixes a bug that notice files for some module type (e.g.
prebuilt_etc) were not included in APEX. This happened because we relied
on WalkPayloadDeps which actually doesn't traverse module types that
don't implement ApexModule interface. prebuilt_etc is one such module
type. Fixing the problem by also iterating the filesInfo array which
has info about all modules that are included in the APEX.
Bug: 166575301
Test: m com.android.tzdata and inspect the built artifact.
NOTICE.html.gz is there.
Change-Id: Iceb055b60184aef2a3e65e44680304853eb79a53
bpf program is put to an APEX via 'bpfs' property. It is
placed under etc/bpf directory in it.
Fix: 167530625
Test: m
Change-Id: Ia36b486f0cffb619ecc4f7a318cde881abc5baf4
prebuilt_firmware module is one of many prebuilt_etc-like modules. When
it is soc-specific, it is installed in /vendor/firmware. Similarly, when
prebuilt_firmware is embeded in a vendor apex, installing it in
<apex>/firmware instead of <apex>/etc.
Bug: 162701747
Test: lunch sunfish-userdebug
m && device boots && vibrator works
Change-Id: I00d28cde42259aaf8221e3897df77efc42b0c1ca
The affected modules weren't actually built in the affected build,
delay the platform availability check in Make instead to allow
the build to proceed.
Bug: 154888298
Test: m checkbuild
Change-Id: I21778e38e04635545b352dee2043a33ec9da246b
Add the new property payload_fs_type in apex module type. Either 'f2fs'
or 'ext4'. Default 'ext4'.
Test: m
Bug: 158453869
Change-Id: I36f373251bd597e11acb62af75437a87e2a531ec
Merged-In: I36f373251bd597e11acb62af75437a87e2a531ec
When we package both 32/62, there could be two instances of the same
library. We need to dedup the list of jni_libs.
Bug: n/a
Test: m com.android.cronet (which uses jni_libs)
check apex_manifest.pb
Change-Id: I9a9f42f0f5219ab7bc50d945b54113b5d823b7f3
AddFarVariationDependencies was broken, which allowed sdk modules to
request dependencies using image and version variations, even for
host modules that do not have image or version variations. Make
the image and version variations conditional on device sdk modules.
Test: go test ./sdk
Change-Id: I59b7a32a3782254fd5feb828a5258ee13d4db812
AddFarVariationDependencies was broken, which allowed dependencies
on non-libraries to be added even though a link variation was
requested. When AddFarVariationDependencies is fixed, attempting
to add a non-library to jni_libs results in the usual missing
variant error.
Test: none
Change-Id: I6aa281491b8af5f141a2d132e248c75f95d68ab5
APEX variants that share the same SDK version and updatability
almost always use identical command line arguments to build but
with different intermediates directories. This causes unnecessary
build time and disk space for duplicated work.
Deduplicate APEX variants that would build identically. Create
aliases from the per-APEX variations to the new shared variations
so that the APEX modules can continue to depend on them via the
APEX name as the variation.
This has one significant change in behavior. Before this change,
if an APEX had two libraries in its direct dependencies and one
of those libraries depended on the other, and the second library
had stubs, then the first library would depend on the implementation
of the second library and not the stubs. After this change, if
the first library is also present in a second APEX but the second
library is not, then the common variant shared between the two
APEXes would use the stubs, not the implementation.
In a correctly configured set of build rules this change will
be irrelevant, because if the compilation worked for the second
APEX using stubs then it will work for the common variant using
stubs. However, if an incorrect change to the build rules is
made this could lead to confusing errors, as a previously-working
common variant could suddenly stop building when a module is added
to a new APEX without its dependencies that require implementation
APIs to compile.
This change reduces the number of modules in an AOSP arm64-userdebug
build by 3% (52242 to 50586), reduces the number of variants of the
libcutils module from 74 to 53, and reduces the number of variants
of the massive libart[d] modules from 44 to 32.
This relands I0529837476a253c32b3dfb98dcccf107427c742c with a fix
to always mark permissions XML files of java_sdk_library modules as
unique per apex since they contain the APEX filename, and a fix
to UpdateUniqueApexVariationsForDeps to check ApexInfo.InApexes
instead of DepIsInSameApex to check if two modules are in the same
apex to account for a module that depends on another in a way that
doesn't normally include the dependency in the APEX (e.g. a libs
property), but the dependency is directly included in the APEX.
Bug: 164216768
Test: go test ./build/soong/apex/...
Change-Id: I2ae170601f764e5b88d0be2e0e6adc84e3a4d9cc
APEX variants that share the same SDK version and updatability
almost always use identical command line arguments to build but
with different intermediates directories. This causes unnecessary
build time and disk space for duplicated work.
Deduplicate APEX variants that would build identically. Create
aliases from the per-APEX variations to the new shared variations
so that the APEX modules can continue to depend on them via the
APEX name as the variation.
This has one significant change in behavior. Before this change,
if an APEX had two libraries in its direct dependencies and one
of those libraries depended on the other, and the second library
had stubs, then the first library would depend on the implementation
of the second library and not the stubs. After this change, if
the first library is also present in a second APEX but the second
library is not, then the common variant shared between the two
APEXes would use the stubs, not the implementation.
In a correctly configured set of build rules this change will
be irrelevant, because if the compilation worked for the second
APEX using stubs then it will work for the common variant using
stubs. However, if an incorrect change to the build rules is
made this could lead to confusing errors, as a previously-working
common variant could suddenly stop building when a module is added
to a new APEX without its dependencies that require implementation
APIs to compile.
This change reduces the number of modules in an AOSP arm64-userdebug
build by 3% (52242 to 50586), reduces the number of variants of the
libcutils module from 74 to 53, and reduces the number of variants
of the massive libart[d] modules from 44 to 32.
Bug: 164216768
Test: go test ./build/soong/apex/...
Change-Id: I0529837476a253c32b3dfb98dcccf107427c742c
In preparation for reusing the same variation for multiple apexes,
rename ApexName to ApexVariationName.
Bug: 164216768
Test: all soong tests
Change-Id: I88f2c5b192ffa27acd38e01952d0cefd413222a0
Remove ipmemorystore-aidl-interfaces-java in allowlist for
com.android.tethering
Bug: 146436251
Test: m nothing
Change-Id: I8b7f97d59c2fd191f467ad50a8fd66d9a5d37704
With the addition of apexes and /system_ext some of the bootclasspath
and system server jars have moved from /system to the new locations.
This has been implemented by using lists of colon-separated strings
called "apex-jar pairs" (although "apex" was misleading as it could
refer to "platform" or "system_ext", not necessarily a real apex).
Using the colon-separated string representation is inconvenient, as it
requires splitting and reassembling the list components many times,
which harms performance and makes error handling difficult. Therefore
this patch refactors the colon-separated lists into a struct that
hides the implementation details.
Test: lunch aosp_cf_x86_phone-userdebug && m
Change-Id: Id248ce639a267076294f4d4d73971da2f2f77208
Previously, the prebuilt mutators were added by the
cc.RegisterRequiredBuildComponentsForTest() function as a convenience
but unfortunately it lead to some of the mutators being in a different
order in the tests than in the normal build.
This change:
* Extracts the RegisterPrebuiltMutators() call from
cc.RegisterRequiredBuildComponentsForTest()
* Makes sure that the prebuilt mutators are registered before the
visibility gatherer and enforcer mutators.
Bug: 162505935
Test: m nothing
Change-Id: I7d959b558200b502f0a5e4653c41ea01414e142a
com.android.gki.* matches any APEX with the prefix com.android.gki.,
like com.android.gki.bar.
Test: use it
Bug: 162267963
Change-Id: Ie46fcb08b031611d26b2b6cde157253f51ba9bfc
Multiple GKI APEXes may write to the same path
under $OUT/apex. Prevent it.
Fixes: 162366062
Test: build GKI APEX
Change-Id: I1b19870b10d6da2a85c3f7b9d93408d3a0fe90bc
dependencyTag uses a set of predefined tags to identify different types
of dependencies. There are already multiple bits of metadata stored
in the dependency tag (Library, Shared, ReexportFlags), and supporting
them all requires a combinatorial explosion of predefined tags and
causes issues when using equality comparisons if a new bit of metadata
is added.
Add a new libraryDependencyTag type that will contain the metadata
bits, and replace the quality comparisons with checks on the metadata
bits.
There are 5 TODOs where modifying the checks identified problems with
the existing checks. These were left in place to produce identical
build output and will be fixed separately.
Bug: 162437057
Test: no change to build.ninja or {Android,make_vars,late}-${TARGET_PRODUCT}.mk
Change-Id: I72d4207dcf381c07c92e00e5a03968ebb5ed8d30
When a vendor APEX sets use_vndk_as_stable: true, then the apex doesn't
bundle VNDK libraries but instead it uses them from the "vndk" namespace
at runtime.
":vndk" is a pseudo-name for VNDK libraries, which is processed by
linkerconfig so that the generated linker configuration allows the
namespace for the apex to access VNDK libs.
Bug: 159576928
Test: test with a test-only vendor apex
it runs okay with VNDK libs. (lsof shows that it opens libs from
VNDK APEX)
Change-Id: I924ce0fea696162575f59589b8f858deddf436b3
Update android_app_set to use word install rather than master for
android_app_sets, this better matches the phrasing used for apex_set.
See https://source.android.com/setup/contribute/respectful-code for
reference
Bug: 161896447
Test: m nothing
Change-Id: I429e7f8b16c42c10ad4d9543110f5ce814a893b1
Vendor APEXes(in general, APEXes for non-system partitions) which is
supposed to be tied to a specific VNDK version can set this new property
so that it excludes VNDK libs and use them from VNDK APEX (provided by
system parition).
For these APEXes to use VNDK libs from VNDK APEX, linkerconfig should
link "vndk" linker namespace to the namespaces of these APEXes.
Bug: 159195575
Test: m (soong test added)
Change-Id: If90650973239ef7aab0ff084488bda57d9b0364e
This change fixes this error:
```
TARGET module com.android.adbd.flattened requires non-existent TARGET
module: prebuilt_libclang_rt.ubsan_standalone-arm-android
```
apexFile.moduleName is used as Make dependency name, so it should use
m.BaseModuleName() instead of m.Name(), because soong may prepend
"prebuilt_" to or mutate the output of m.Name() in other ways.
android/androidmk.go emits Android.mk modules with
`LOCAL_MODULE := module.BaseModuleName() + <SubName>`, so replace
apexFile.moduleName with BaseModuleName() + <SubName> as much as
possible.
Bug: 7456955
Test: Add unit test in apex/apex_test.go
Test: lunch blueline_hwasan && SANITIZE_TARGET='hwaddress fuzzer' m nothing
Test: Verify out/soong/Android-blueline_hwasan.mk
Change-Id: If8537fc1bedbe6c3405de3662a5df210a073c43f
Previously, an APEX variant was created for a module that was a member
of an SDK just in case it had to be replaced with an APEX requested
snapshotted version of that member. That was necessary because that was
the only way to have APEX specific replacements.
Since then a new method called ReplaceDependenciesIf() has been added
which provides fine grained control over which dependencies are
replaced. This change uses that new method to handle the replacements
which allows the APEX variants to be removed.
Bug: 161928524
Test: m nothing
Change-Id: If3869dd6753dc182b099af566b20fbc9c9c6eff7
apexDepsMutator marks all dependencies of apex modules. Previously, it
was converted from WalkDeps() to Top-down mutator to avoid the pitfall
of WalkDeps() bug. (It did't handle multiple visits via different
paths.)
Because WalkDeps() problem solved in aosp/1277516, apexDepsMutator can
be reverted to use WalkDeps().
Even though there's no observable difference between them, I revert this
for the up-coming change, which requires different pruning strategies
per apexes.
Bug: 159195575
Test: m
Change-Id: Ib09cbc7a3dfd143dd37b660b1aea6c71392ce2e3
The RelativeInstallPath is currently unused for apexes; however, as it
stands, relative install paths would be handled differently for
flattened and unflattened apexes.
Test: go java test
Test m nothing
Change-Id: Iad9350642cad27c4f745cea6e5fc9e11e7b06ee4
prebuilt_apex has been disabled when the device is configured for
flattened APEXes, sanitized, instrumented, or built unbundled. However,
apex_set which is another type of APEX prebuilt wasn't disabled for the
same conditions.
This change fixes the discripency. apex_set modules are also force
disabled when the prebuilts are not expected.
Bug: 161316762
Bug: 160933444
Test: OVERRIDE_TARGET_FLATTEN_APEX=true m
The built image has only the flattened APEXes and the device boots
Change-Id: I6c90dfb28d565861a473a1bdce93269ec370601d
We put reproducible timestamps in zip files so that the artifacts
are consistent, but that leads to old timestamps in the output
directory if they are unzipped as part of the build. Use
unzip -DD when unzipping to update the timestamps.
Bug: 161015009
Test: touch -d 2020-01-01 ref; find $OUT/system -not -newer ref
Change-Id: I70407a627cb070e24be510faa6a774e3d9eae3a8
Pass a list of unstripped JNI libraries to Make so that they can be
installed into the symbols directory.
Bug: 159726429
Test: forrest
Change-Id: Ieb4bffbb3d0a09f476da011399c5b8b1611929d7
* changes:
Prepend default to allow overriding in the bp file.
Do not follow SDK member dependencies for APEX payloads.
Do not follow prebuiltDependencyTags in APEX payload walks.
Previously, java_sdk_library_import added the dependencies on its child
components in the deps mutator after prebuilts without a matching
source module are renamed to the source module name. That meant that
the java_sdk_library_import has to use the source module name and ended
up depending on the source module unless it was preferred.
This change adds a new component deps mutator that runs before the
PrebuiltRenameMutator so that the java_sdk_library_import can add
dependencies onto the prebuilt modules. It also updates an affected
test.
Bug: 159902351
Test: m nothing
Change-Id: I3576c4873302743e51aff547ea1497bef6d748ac
If prebuilts are active they will have the other direct dependencies
from the source modules.
Bug: 151303681
Test: m nothing
Test: `m` with prebuilts/runtime in the manifest (along with other
fixes)
Change-Id: I1ffc7e7b528ed9db5ce6ca2ee96c9d23c6548c49
* changes:
Make native_coverage clause work with ClangCoverage
Introduce product variables to select Java code coverage paths in Soong.
Rename native code coverage paths product variables in Soong.
Make uses NATIVE_COVERAGE to enable gcov coverage and CLANG_COVERAGE
to enable clang coverage. NATIVE_COVERAGE is translated to the Soong
Native_coverage product variable which triggers the native_coverage
clause in Android.bp files. The clause also needs to be triggered
for CLANG_COVERAGE.
Rename the existing Native_coverage product variable to GcovCoverage,
and regenerate Native_coverage when either GcovCoverage or
ClangCoverage are set.
Also remove NativeLineCoverage, it wasn't doing anything differently
than Native_coverage.
Bug: 159059537
Test: m checkbuild
Merged-In: I215124a9b35a2ad50ad562079d392e3d33da11f4
Change-Id: I215124a9b35a2ad50ad562079d392e3d33da11f4
apex_set is a set of prebuilt apex files. To support GSI which installs
both flattened and unflattened APEXes when apex_set is used, we extract
the contents from the selected APEX file.
Bug: 159711661
Test: TARGET_PRODUCT=gsi_gms_arm64 m
should install flattened apexes in /system/system_ext/apex
Change-Id: I0a51b9f4a4537d3230aaa3eece532664ea18bc7c
apex_manifest.pb is added to payload.img by the build system and is
supposed to be read by apexd during activation.
So, / and /apex_manifest.pb should be labeled as "system_file" so
that apexd can read it regardless of how file_contexts is defined.
580eb4fe38 adds /apex_manifest.pb and this
change adds / as well to file_contexts.
Bug: 159767275
Test: add an apex with file_contexts with everything as vendor_file
apexd should activate the apex.
Change-Id: I827fa3af49ca7f20f3f82fcb16868f60d94d9531
apexBundle keeps the required dependencies for native modules which are
external dependencies and then records it in .mk file as
LOCAL_REQUIRED_MODULES key.
LOCAL_REQUIRED_MODULES should list module name which are made of
cc.BaseModuleName() + SubName.
By the way, because a use_vendor:true apex is supposed to be installed
in /system/apex, we don't append SubName(.vendor) suffix.
Bug: 159211312
Bug: 155841765
Test: m
Change-Id: Ifd2858dda0b373110a0cd18a0c55db41f0fc2a99
When an apex sets "vendor: true", it becomes a vendor apex.
Vendor apexes use vendor variants for native modules and are
installed in /vendor/apex.
Bug: 159211312
Test: m
Change-Id: I2585dd990ba857a2ab3ec6ab24e09d4652e867f2
AndroidMkEntries handles bunch of common properties(e.g. LOCAL_INIT_RC,
LOCAL_VINTF_FRAGMENTS, etc).
However apex defines its own Custom() writer, so those properties should
be handled manually.
For example, when an apex defines "init_rc" properties, the value should
be passed to Make via LOCAL_INIT_RC.
Bug: 159211312
Test: m
Change-Id: I65e7a456486c9f5fe70c91b78ff181425035fcf2
This allows the unbundled master-art branch to still use flattened
APEXes in its test builds.
Bug: 159109002
Test: art/build/apex/runtests.sh on master-art
Test: m nothing
Change-Id: I768c6b7f5afbc348cd7730e4ba96507678434778
apex_manifest.pb is added to payload.img by the build system and is
supposed to be read by apexd during activation.
So, it should be labeled as "system_file" so that apexd can read it
regardless of how file_contexts is defined.
Bug: 159767275
Test: add an apex with file_contexts with everything as vendor_file
apexd should activate the apex.
Change-Id: Ie34eb7ad905828976152d67a7dfabf0add0a5de4
Enforce min_sdk_version for every payload dependency of updatable
APEX/APKs.
android.CheckMinSdkVersion() calls ApexModule.ShouldSupportSdkVersion
for every transitive dependency from APEX/APK modules to see if it
meets the min_sdk_version requirements.
The common implementation for apex/android_app is provided in
android/apex.go.
Bug: 145796956
Bug: 152655956
Bug: 153333044
Test: m nothing
Change-Id: I4a947dc94026df7cebd552b6e8ccdb4cc1f67170
Make uses NATIVE_COVERAGE to enable gcov coverage and CLANG_COVERAGE
to enable clang coverage. NATIVE_COVERAGE is translated to the Soong
Native_coverage product variable which triggers the native_coverage
clause in Android.bp files. The clause also needs to be triggered
for CLANG_COVERAGE.
Rename the existing Native_coverage product variable to GcovCoverage,
and regenerate Native_coverage when either GcovCoverage or
ClangCoverage are set.
Also remove NativeLineCoverage, it wasn't doing anything differently
than Native_coverage.
Bug: 159059537
Test: m checkbuild
Change-Id: I215124a9b35a2ad50ad562079d392e3d33da11f4
Because override_apex can modify the contents of the base apex,
allowed_files (which describes the contents) should be overridable.
Bug: 159503079
Bug: 159392784
Bug: 158169437
Test: m (soong test added)
Merged-In: I12744b0465dc3cfc90a66643867e65b4092cd0f7
Change-Id: I12744b0465dc3cfc90a66643867e65b4092cd0f7
(cherry picked from commit faa5399b3f)
Previously, when a boot jar was provided by a java_sdk_library_import
module the check-boot-jars check failed because the file it depended on
was not available. In an incremental build the build failed due to the
file in the out directory not having a rule to generate it.
That was because the module was named prebuilt_<module>.<apex> instead
of <module>.<apex>. This was fixed by simply removing prebuilt_ prefix
from the name if it was present.
After fixing that the check-boot-jars still did not work properly
because it was expecting a jar file containing .class files but instead
was given a jar file containing .dex files which meant the check did
not work properly.
This was fixed by defining a new ApexDependency interface for use by
the apex/apex.go code to use instead of java.Dependency for generating
the androidmk entries. The *SdkLibraryImport type then implemented
those, by delegating to the implementation library.
Bug: 158304459
Bug: 159112414
Test: m check-boot-jars
m checkbuild
manual inspection of the .jar file used by check-boot-jars to
ensure it contained .class files and not .dex files.
Change-Id: I545c5c9072dd472337d2f9b4dfdf08f53c981662
Merged-In: I545c5c9072dd472337d2f9b4dfdf08f53c981662
Because override_apex can modify the contents of the base apex,
allowed_files (which describes the contents) should be overridable.
Bug: 159503079
Bug: 159392784
Bug: 158169437
Test: m (soong test added)
Change-Id: I12744b0465dc3cfc90a66643867e65b4092cd0f7
Previously, when there is apex_set that is overriding another module,
the entry for the overridden module is removed from apexkeys.txt.
However, this is wrong because the existence of the apex_set module
doesn't necessary mean that the module is insatalled instead of the
overridden module. That is determined by PRODUCT_PACKAGES which Soong
has no knowledge of. Therefore, we don't delete the entry for the
overridden (actually possibly overridable) modules in the file.
Bug: 158729168
Test: m
Merged-In: I85d0c756f862323bae556bf657d66ec50038985f
(cherry picked from commit ac5e79f900)
Change-Id: I85d0c756f862323bae556bf657d66ec50038985f
Q+ and R+ mainline modules may only add code in a restricted set of Java
package prefixes, that may never be changed.
If a mainline module owns the Java package prefix "foo.bar", it may have
classes in "foo.bar", "foo.bar.baz", "foo.bar.baz.bat" etc.
Test: m
Bug: 156725734
Change-Id: I30bf510ed473309871469bf439d7c81575450931
Previously, when there is apex_set that is overriding another module,
the entry for the overridden module is removed from apexkeys.txt.
However, this is wrong because the existence of the apex_set module
doesn't necessary mean that the module is insatalled instead of the
overridden module. That is determined by PRODUCT_PACKAGES which Soong
has no knowledge of. Therefore, we don't delete the entry for the
overridden (actually possibly overridable) modules in the file.
Bug: 158729168
Test: m
Change-Id: I85d0c756f862323bae556bf657d66ec50038985f
Previously, when a boot jar was provided by a java_sdk_library_import
module the check-boot-jars check failed because the file it depended on
was not available. In an incremental build the build failed due to the
file in the out directory not having a rule to generate it.
That was because the module was named prebuilt_<module>.<apex> instead
of <module>.<apex>. This was fixed by simply removing prebuilt_ prefix
from the name if it was present.
After fixing that the check-boot-jars still did not work properly
because it was expecting a jar file containing .class files but instead
was given a jar file containing .dex files which meant the check did
not work properly.
This was fixed by defining a new ApexDependency interface for use by
the apex/apex.go code to use instead of java.Dependency for generating
the androidmk entries. The *SdkLibraryImport type then implemented
those, by delegating to the implementation library.
Bug: 158304459
Bug: 159112414
Test: m check-boot-jars
m checkbuild
manual inspection of the .jar file used by check-boot-jars to
ensure it contained .class files and not .dex files.
Change-Id: I545c5c9072dd472337d2f9b4dfdf08f53c981662
apex_sets is a new module type that can be used to deliver pre-signed
APEXes, which previously could be done only via prebuilt_apex.
Soon gnow understands apex_sets module types and emits the signing info
of the modules to apexkeys.txt
Exempt-From-Owner-Approval: cherry-pic from AOSP
Bug: 158729168
Test: m
Merged-In: I9507375342ec053309660d94c931a79bf4f21218
(cherry picked from commit 8d6c51ebcc)
Change-Id: I9507375342ec053309660d94c931a79bf4f21218
If a java_sdk_library_import has a corresponding java_sdk_library then
make the java_sdk_library_import export both the xml and impl modules
created by the java_sdk_library.
Makes java_sdk_library_import consistent with java_sdk_library by
providing libraries within the same APEX access to the implementation
library instead of the stubs.
Bug: 158304459
Test: m nothing
Test what happens when building com.android.tethering with and without
a preferred "framework-tethering" java_sdk_library_import. Make sure that
it does not change the generated APEX.
Merged-In: I2f4edea937ac377431a5696c92cbd467bded62ef
Change-Id: I2f4edea937ac377431a5696c92cbd467bded62ef
(cherry picked from commit eedc5d55ce)
Don't emit an empty LOCAL_OVERRIDES_MODULES line if APEX is not
overriding any module.
Test: TH noop
Change-Id: I7abbaccd54bf2ffa25a6c798260c81284ea5ecb2
If a java_sdk_library_import has a corresponding java_sdk_library then
make the java_sdk_library_import export both the xml and impl modules
created by the java_sdk_library.
Makes java_sdk_library_import consistent with java_sdk_library by
providing libraries within the same APEX access to the implementation
library instead of the stubs.
Bug: 158304459
Test: m nothing
Test what happens when building com.android.tethering with and without
a preferred "framework-tethering" java_sdk_library_import. Make sure that
it does not change the generated APEX.
Change-Id: I2f4edea937ac377431a5696c92cbd467bded62ef
While libz has stubs for other mainline modules, it doesn't provide
stubs when it is used as a VNDK lib.
In general, VNDK libs are only for vendor modules. So, we skip them even
if they have stubs.
Bug: 155456180
Test: m com.android.vndk.current
provideNativeLibs of the APEX should be empty
Change-Id: I22401a2b1732a8560802c5be850181682e183a8e
apex_sets is a new module type that can be used to deliver pre-signed
APEXes, which previously could be done only via prebuilt_apex.
Soon gnow understands apex_sets module types and emits the signing info
of the modules to apexkeys.txt
Bug: 158729168
Test: m
Change-Id: I9507375342ec053309660d94c931a79bf4f21218
Ida6f7bb784efe74cc1fa0e8d370eaee803f08b0f made it possible to add
dex_import modules into apex, but that change had a bug. When creating
Android.mk for the dex_import module, the code executed an unchecked
type assertion to convert java.DexImport to java.Dependency, which
cannot be successful. This change fixes the bug by doing a checked type
assertion instead.
Exempt-From-Owner-Approval: cp from AOSP
Bug: 157886942
Test: m (test added)
Merged-In: Id22c20d42effce539fab10b0d349bf340d467f02
(cherry picked from commit 9e83f0b531)
Change-Id: Id22c20d42effce539fab10b0d349bf340d467f02
Ida6f7bb784efe74cc1fa0e8d370eaee803f08b0f made it possible to add
dex_import modules into apex, but that change had a bug. When creating
Android.mk for the dex_import module, the code executed an unchecked
type assertion to convert java.DexImport to java.Dependency, which
cannot be successful. This change fixes the bug by doing a checked type
assertion instead.
Bug: 157886942
Test: m (test added)
Change-Id: Id22c20d42effce539fab10b0d349bf340d467f02
This reverts commit b0dc851ff4.
Reason for revert: relanding original change. Build failures were
caused by a race with another CL: https://r.android.com/1320920
Test: lunch aosp_cf_x86_phone-userdebug && m
Change-Id: Ic9016582dae7773b4d4f84a63425f1ef7a5d061f
This is a prerequisite change before adding DexJarInstallPath.
Test: lunch aosp_cf_phone-userdebug && m
Change-Id: I033e08b8bb06c0a844a6bbbfcdc48ce33e9c95cf
Give prebuilt_etc and sh_binary their own packages and split the
gigantic main Android.bp up to small, per-package ones.
(This is a cherry-pick change.)
Test: m nothing, TreeHugger
Bug: 156980228
Change-Id: I7b00cd344b9f16861f1ff39edf0029f016b853d0
Merged-In: I7b00cd344b9f16861f1ff39edf0029f016b853d0
Give prebuilt_etc and sh_binary their own packages and split the
gigantic main Android.bp up to small, per-package ones.
Test: m nothing, TreeHugger
Bug: 156980228
Change-Id: I7b00cd344b9f16861f1ff39edf0029f016b853d0
apex now respects stem of java_library modules.
As a follow-up we need to suppor the same for other types of modules.
Exempt-From-Owner-Approval: cherry-pick from AOSP
Bug: 157638999
Test: m
Merged-In: Iaf5023020b5440f1ffd4f5414b5a7864655fc22a
(cherry picked from commit a62aa23990)
Change-Id: Iaf5023020b5440f1ffd4f5414b5a7864655fc22a
apex now respects stem of java_library modules.
As a follow-up we need to suppor the same for other types of modules.
Bug: 157638999
Test: m
Change-Id: Iaf5023020b5440f1ffd4f5414b5a7864655fc22a
The marked library(ies) were available to the APEX via the
hand-written whitelist in build/soong/apex/apex.go. Trying to remove the
whitelist by adding apex_available property to the Android.bp of the
libraries.
Exempt-From-Owner-Approval: cherry-pick from internal
Bug: 150999716
Test: m
Merged-In: I2b792657b444f0c963e1e92b7c91f6a0cfe1688c
(cherry picked from commit be6e2b6a18)
Change-Id: I2b792657b444f0c963e1e92b7c91f6a0cfe1688c
Previously, if a data source was included in multiple APEX, it would
appear multiple times; however, this caused errors for overriding
commands for targets
Test: apex_test.go
Test: m nothing with change I54d92eca88fc04c949209d490e838d0a92ce8f87
Bug: 155820504
Change-Id: I98f04e0fd9fa3238f2bb0e5da3a86fc0797c38ba
Introduce a singleton apex rule to merge contents of individual
deps-info results into a single output file.
Bug: 149622332
Test: m
Change-Id: I4ab7e1a3527fead97a81a5a2cb0e1e93a429117c
Merged-In: I4ab7e1a3527fead97a81a5a2cb0e1e93a429117c
Exempt-From-Owner-Approval: cp from aosp
(cherry picked from commit 849f844252)
For a given variant of a module that implements ApexModule interface,
the "updatable" property tests if this variant comes from an updatable
apex. For platform variants it is always false.
Test: lunch aosp_walleye-userdebug && m nothing
Bug: 138994281
Merged-In: I2d4c54fb397e29dc9b3203be7fb17be4536529f7
Change-Id: I2d4c54fb397e29dc9b3203be7fb17be4536529f7
Exempt-From-Owner-Approval: cp from aosp
(cherry picked from commit 7c140d828a)
Access to the implementation JARs is restricted to avoid code from
depending on implementation details that could change from one release
to the next which could cause compatibility issues. That is not a
problem when referenced from within the APEX that contains the
java_sdk_library.
As references from within the same APEX often need to access
implementation specific details of the java_sdk_library and doing that
from within the same APEX is safe this change all references to a
java_sdk_library made within the same APEX to use the implementation
jars instead of stub jars.
Bug: 155164730
Test: m droid
Change-Id: If239059690de61683c2ad2d8a0ce2e47286a3637
(cherry picked from commit 9b879594ed)
Access to the implementation JARs is restricted to avoid code from
depending on implementation details that could change from one release
to the next which could cause compatibility issues. That is not a
problem when referenced from within the APEX that contains the
java_sdk_library.
As references from within the same APEX often need to access
implementation specific details of the java_sdk_library and doing that
from within the same APEX is safe this change all references to a
java_sdk_library made within the same APEX to use the implementation
jars instead of stub jars.
Bug: 155164730
Test: m droid
Change-Id: If239059690de61683c2ad2d8a0ce2e47286a3637
This reverts commit c9c7116721.
This revert is to avoid merge conflict when ag/11299431 is auto-merged
to master.
This change will again be reverted when ag/11299431 lands.
Bug: 150999716
Test: m
Change-Id: Ia0f7a0e0eb8cf6f6f4d0693de01777a8a750c769
