The first hack has been introduced to facilitate the creation of the
com.android.btservices apex without the need to upload 100+ cl close to
the release date.
We now want to delete com.android.bluetooth apex and replace all the
apex_available rules to target the new apex name
It will be way much easier to do this in separate CL and without forcing
us into a single topic.
Bug: 243054261
Test: Build
Change-Id: Ia03698db839db4684871eb38c088f88d6bdcba4b
This hard-coded list causes inconsistent behavior regarding -target
triple and _ANDROID_APEX_MIN_SDK_VERSION_ macro for native modules.
Bug: 158059172
Test: m
Merged-In: Iae3ecb3bfaefc2ee73ed38a9268c68b6673f30c5
Change-Id: Iae3ecb3bfaefc2ee73ed38a9268c68b6673f30c5
(cherry picked from commit 870ab9c0f78327d92a871ac58c0337db8ae92245)
Set min_sdk_version/apex_available for modules used by
com.android.permission APEX.
Bug: 147364041
Bug: 158059172
Test: m
Change-Id: I93ff72ed765354d44a2ccb5105b5f2820f0358f5
Hard-coded min_sdk_version is not necessary for kotlinx-* modules
because they are already marked by updater script.
Bug: 158059172
Test: m nothing
Change-Id: I42cf26c9390244f93059af68027cca4f8518a828
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
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
This is to help following refactor for individual modules to have their
own version of checking where needed.
For example, apk in apex may want to enforce it's own version of
CheckMinSdkVersion.
Bug: 205923322
Test: presubmit
Change-Id: Ia2fad6c52af39e21f65385bcb283f1e3adab5548
Many modules requiring min_sdk_version have been used without setting
it, but hard-coded in allowlist.
Bug: 158059172
Test: m
Change-Id: Ibb09ddfdb11df0791a28eb8a0a49f1780084fd95
Many modules requiring min_sdk_version have been used without setting
it, but hard-coded in allowlist.
Bug: 158059172
Test: m
Change-Id: I6d11425f9c5db11cd52dd81f7500e4424555bfb5
The property is used to allow non-updatable APEXes to use platform APIs
(e.g. symbols marked as "# platform-only").
Bug: 191637950
Test: m com.android.virt com.android.compos
Merged-In: Id2410b4e38a78ec2146a42298840954381a7c472
Change-Id: Id2410b4e38a78ec2146a42298840954381a7c472
(cherry picked from commit fb63625a7f)
Neither InApexVariants nor InApexModules should have them. This allows
us to get rid of InApexVariantByBaseName as well.
Test: m nothing
Test: m nothing SOONG_CONFIG_art_module_source_build=false
Bug: 180325915
Change-Id: Icbe4e025ce1a4c8dd258ff95d326ca2f27905188
CopyDirectlyInAnyApex was documented to copy from child to parent, but
was copying from parent to child. It is unused, so reverse it to
match the documentation.
Bug: 183759446
Test: next CL
Change-Id: I950c9b5416d66e83d76ca489aeb5e0572e005d5d
Consider this case:
apex {
name: "com.android.foo",
native_libs: ["foo"],
}
override_apex {
name: "com.mycompany.android.foo",
base: "com.android.foo",
}
cc_library {
name: "foo",
}
There are two APEXes defined: "com.android.foo" and
"com.mycompany.android.foo" which is a copy of "com.android.foo" with
some properties overridden (e.g. signing keys).
The module "foo" is mutated into two variants by the apex mutator: the
platform variant and the apex variant. The former has the variation name
"" and the later has "apex<min_api_ver>" which usually is "apex10000".
Internally, the apex variant has an alias "com.android.foo".
ApexInfo.InApexVariants() returns only "com.android.foo" when called for
the module "foo".
We can see that the information that "foo" is also part of
"com.mycompany.android.foo" is completely lost. This is causing problem
when we compare the apex membership by their "soong module name", not
the "apex name". In the example above, the two modules have different
soone module names, but have the same apex name: "com.android.foo".
To fix that, this CL introduces a new field `InApexes` to the `ApexInfo`
struct. It has the actual name of the APEXes that the module is part of.
With the example above, `InApexes` is ["com.android.foo",
"com.mycompany.android.foo"].
Bug: 180325915
Test: m nothing
Test: m nothing on non-AOSP targets with ag/13740887 applied.
Change-Id: I4e7a7ac5495d2e622ba92a4358ed967e066c6c2e
.. in preparation for the upcoming change. This change doesn't alter any
behavior.
InApexes is a misleading name. People expects that it has the list of
soong module names of the APEXes that a module is part of. So, for
example, `core-oj` is a part of both `com.android.art` and
`com.google.android.art`. However, in reality, that's not true. The
field has `com.android.art` only. This is because the two APEXes
(android and Google) have the same apex name which is `com.android.art`.
That apex name is used in various places like the `apex_available` and
allows us to keep using the same name regardless of whether the APEX is
overridden or not.
However, this is causing problems in some cases where the exact list of
soong module names is required. The upcoming change will add a new field
to handle the case and the new field actually will get the name
'InApexes'. So, the existing field is renamed to a less misleading name
`InApexVariants`.
Bug: 180325915
Test: m nothing
Change-Id: I0c73361b452eddb812acd5ebef5dcedaab382436
ApexInfo is not part of the properties struct. It can handle structs
having private fields.
Bug: 1663140
Test: m
Change-Id: Ib07d4410f0ce187c9de347da34b84b814b2eb537
building test_for modules.
This extends the current approach where test modules always depend on
the platform variants of the APEX libs, and only skips the stubs on
them. It still has the limitation that the internal libs must have the
exact same apex_available lists.
Also some improvement of the test accuracy in TestTestFor.
Test: m libartagent-target
with http://r.android.com/q/topic:libdexfile-noext applied
Bug: 183217299
Change-Id: I2118b8a22c887077867a3ddbbe73437b4a29a6ad
The ExcludeFromApexContentsTag marker interface was added to avoid
every implementation of DepIsInSameApex() from having to deal with the
special tags, like PrebuiltDepTag. Unfortunately, when adding that
not all calls to DepIsInSameApex() were protected which meant that the
BootImageModule, which panics if it doesn't recognize a tag, was
causing failures. This change documents the need and improves the
consistency.
A follow up change will add a test for this.
Bug: 182992071
Test: m nothing
Change-Id: If0bf9a7447ebf7a0bb0c88e91951a7220d4af45c
Adds the AlwaysRequireApexVariantTag interface to enable
ApexInfoMutator to differentiate between a tag that is excluded from
apex contents but still requires an apex variant and a tag that is
excluded from apex contents and does not require an apex variant.
That is needed to support the sdkMemberVersionedDepTag which excludes
the target from being added to the APEX but requires an APEX variant.
A more detailed explanation is in the comments.
The AlwaysRequireApexVariant() method follows the pattern used in
ReplaceSourceWithPrebuilt of having a method that returns a bool to
trigger the behavior and not say ExcludeFromApexContentsTag that simply
relies on the tag implementing an interface to trigger. That is because
the former is more flexible and allows a tag type to parameterize the
behavior if necessary.
The tags that this will exclude from creating an apex variant are:
* PrebuiltDepTag - by the time the apex variant has been created any
preferred prebuilts will have replaced the sources so there is no
need to create an APEX variant if the only dependency path from the
APEX to the prebuilt is via this tag.
* hiddenApiAnnotationsDependencyTag - the target of which is a purely
build time artifect and MUST NEVER end up in the APEX.
It will also stop calling DepIsInSameApex for any dependency created
by the sdkMemberVersionedDepTag. Which will fix the issue reported in
the bug.
Bug: 182992071
Test: m nothing
Change-Id: I9569e488d6446ca45d3ea8f32a9b74524eb865df
Modules that are not available for platform are developed with
updatability in mind, and do not require manual approvals.
Bug: 181223240
Test: checkbuild
Change-Id: I10b91053b3ef5a9ff5400d9d7a68fae3144a671c
1) suggest a fix at the end of the message
2) add new lines around the dependency path so that they are visually
separated from rest of the error message
Bug: N/A
Test: m with an intentional break
error: bionic/apex/Android.bp:32:1: module "com.android.runtime" variant "android_common_com.android.runtime_image": "libutils_headers" requires "libsystem_headers" that doesn't list the APEX under 'apex_available'.
Dependency path:
via tag apex.dependencyTag: { name:executable payload:true}
-> crash_dump{os:android,image:,arch:arm_armv8-a,sdk:,apex:apex10000}
via tag cc.libraryDependencyTag: { Kind:staticLibraryDependency Order:normalLibraryDependency wholeStatic:false reexportFlags:false explicitlyVersioned:false dataLib:false ndk:false staticUnwinder:false makeSuffix: skipApexAllowedDependenciesCheck:false excludeInApex:false}
-> libtombstoned_client_static{os:android,image:,arch:arm_armv8-a,sdk:,link:static,apex:apex10000}
via tag cc.libraryDependencyTag: { Kind:staticLibraryDependency Order:normalLibraryDependency wholeStatic:true reexportFlags:true explicitlyVersioned:false dataLib:false ndk:false staticUnwinder:false makeSuffix: skipApexAllowedDependenciesCheck:false excludeInApex:false}
-> libcutils{os:android,image:,arch:arm_armv8-a,sdk:,link:static,asan:,apex:apex10000}
via tag cc.libraryDependencyTag: { Kind:headerLibraryDependency Order:normalLibraryDependency wholeStatic:false reexportFlags:false explicitlyVersioned:false dataLib:false ndk:false staticUnwinder:false makeSuffix: skipApexAllowedDependenciesCheck:false excludeInApex:false}
-> libutils_headers{os:android,image:,arch:arm_armv8-a,sdk:,asan:,apex:apex10000}
via tag cc.libraryDependencyTag: { Kind:headerLibraryDependency Order:normalLibraryDependency wholeStatic:false reexportFlags:true explicitlyVersioned:false dataLib:false ndk:false staticUnwinder:false makeSuffix: skipApexAllowedDependenciesCheck:false excludeInApex:false}
-> libsystem_headers{os:android,image:,arch:arm_armv8-a,sdk:,asan:,apex:apex10000}
Consider adding "com.android.runtime" to 'apex_available' property of "libsystem_headers"
Change-Id: I09f92c3086ea433780133a33ba0ad73baee6dc41
are present.
1) The boot jar to APEX mapping is maintained by the base names for
both of them. When building with prebuilt modules and APEXes, that
means we need to take care to compare them without regard to any
"prebuilt_" prefixes.
2) VisitAllModules can visit disabled modules and both source and
prebuilt modules, so they need some conditions to skip modules that
aren't applicable for boot jars.
Test: `m droid`
Test: `m droid SOONG_CONFIG_art_module_source_build=false`
with fresh ART Module prebuilts in place
Bug: 171061220
Change-Id: Iced269d29127bc8b8f9b3171adb60a97d115628b
If we don't check "current", it won't be checked even in the finalized
branch.
If we don't check "preview", it should be done during the SDK
finalization. It'd be better done before the SDK finalization regarding
that setting min_sdk_version is to get approval from deps library owners.
Bug: 177833148
Test: m (soong tests)
Change-Id: I712b61cfe5a134fbb69c73956d26fb3a1e5c011e
Dexpreopt and boot jars package check all require access to dex
implementation jars created for java_library and java_sdk_library. They
were available when building from source but not when building from
prebuilts, even though they are embedded within the .apex files that
are referenced from prebuilt_apex.
This changes adds support to prebuilt_apex to export the dex
implementation jars and updates java_import to use those exported dex
implementation jars.
In a source build dexpreopt/boot jars package check access the apex (or
platform) specific variant of a java_library, e.g. core-oj, from which
it retrieves the dex implementation jar path.
After this change in a prebuilt build dexpreopt/boot jars package check
behave in the same way except in this case they retrieve the dex
implementation jar path from the apex (or platform) specific variant of
the java_import, e.g. core-oj.
The work to export files from a `.apex` file for use by other modules
is performed by a new `deapexer` module type. It is not used directly
in an `Android.bp` file but instead is created implicitly by
`prebuilt_apex`,
In order to do that this contains the following changes:
* Adds a new `dexapexer` module type to handle the exporting of files
from the `.apex` file.
* Adds an exported_java_libs property to prebuilt_apex to specify the
set of libraries whose dex implementation jars need exporting.
* Creates apex specific variants of the libraries listed in the
exported_java_libs property.
* Adds the set of exported files to the ApexInfo to make them available
to the apex specific variants.
* Prevents the prebuilt_apex variants from being merged together as
they will not be compatible.
* Modifies java_import to use the exported file for variants of a
prebuilt_apex.
* Adds a ninja rule to unpack (using deapexer) the contents of the
prebuilt_apex's apex file, verify that the required files are present
and make them available as outputs for other rules to use.
* Some minor refactorings to support these changes.
* Adds tests to cover prebuilt only, prebuilt with source preferred,
and prebuilt preferred with source.
Test: m nothing
Bug: 171061220
Change-Id: Ic9bed81fb65b92f0d59f64c0bce168a9ed44cfac
To avoid adding ubsan to the apex allowed_dep list, this commit adds a
check on depedency tags to see if apex check should be skipped.
The check is only used on sharedLib dependencies when diag mode are enabled
for sanitizers.
Bug: 158010610
Test: make build for aosp-sargo and aosp_cf_x86_phone-userdebug
Change-Id: I3d7dbb70d8c80ffae1854819cf8cf9e6b0b15c00
When a shared library providing stubs is included in an APEX, only the
stub variant (i.e. version:"1", etc.) gets emitted to Android.mk. This
enforces that everything in the Make world to link to the stub providing
only the public APIs of the library. The non-stub variant (i.e.
version:"") isn't exposed, otherwise, others will be able to access
private part of the lib which isn't guaranteed to be stable.
This has been done by unhiding the stub variant when it is known that
the library is actually included in an APEX. Note that stub variants are
by default hidden.
The above mechanism however doesn't work when the shared library is
replaced by a prebuilt and when the APEX is also replaced by a prebuilt.
Then, the fact that the prebuilt library is actually in the APEX gets
lost. In that case, AnyVariantDirectlyInAnyApex() returns false for the
prebuilt library. As a result, the stub variant remains hidden and not
emitted to Android.mk.
This change fixes the problem by checking if the lib isn't available for
the platform at all. If not available for the platform (e.g.
apex_available doesn't have "//apex_available:platform"), the lib is
assumed to be included in an APEX even when it actually didn't go
through the apex mutator (... because it's a prebuilt).
Bug: 175166063
Test: m nothing
Change-Id: I41fabd5b368baecf4dc3c5a080b466f8bcd79d77
Generally ...DepsMutator methods add dependencies between modules but
the apexDepsMutator does not which can be confusing. This renames
apexDepsMutator to apexInfoMutator and adds some extra documentation to
clarify its function. It also renames the registered name for the
mutator and its associated providers from apex_deps to apex_info.
Test: m nothing
Bug: 171061220
Change-Id: Ic074a281215b23e982448ccff7ac075236123bee
Mostly documentation changes, but includes a few refactorings like
changing the variable names, reording functions, reordering statements
in logical order, etc.
Bug: 173472337
Test: m
Change-Id: I000c76e818722ed06bac03d9de87588b23552b08
The android.WriteFile rule takes careful escaping to produce the
right contents. Wrap it in an android.WriteFileRule that handles
the escaping.
Test: compare all android.WriteFile outputs
Change-Id: If71a5843af47a37ca61714e1a1ebb32d08536c31
