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 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
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
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.
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.
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.
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
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
The android_library module type can be used within an android_app that
can itself be added to an apex but android_library does not call
android.InitApexModule(module) and so it does not support apex variants
and so is treated as if it cannot be part of an APEX even though it
actually is.
Now, android_library supports AEPX variants.
Due to this change, the whilelist for apex_available got bigger.
Exempt-From-Owner-Approval: cherry-pick from internal
Bug: 156978407
Test: m
Merged-In: I3a21d653fe9c4159e3a89791fe1a8597865eeae6
Change-Id: I3a21d653fe9c4159e3a89791fe1a8597865eeae6
(cherry picked from commit bd133b1bdc)
