This change moves the monolithic hidden API index file creation rule
from the hiddenAPIIndexSingleton into the platform_bootclasspath. It
also moves the corresponding test from java/hiddenapi_singleton_test.go
to java/platform_bootclasspath_test.go.
Bug: 179354495
Test: verified that the out/soong/hiddenapi/... files are unchanged
by this change
Change-Id: Ia295d0f7ae9b51ea816f16921aa42339ed91704e
As part of the work to modularize the hiddenAPI processing the
generation of the monolithic hidden API index file needs to be moved
to the platform_bootclasspath module type. Doing that broke the
TestBootDexJarsFromSourcesAndPrebuilts tests which checks the inputs to
the rule that creates that file. Fixing that required added a
platform_bootclasspath module to the test fixture for those tests which
highlighted an issue with the prebuilt_apex module.
Previously, when the prebuilt_apex created apex variants it would use
its own name as the apex variant name, even when that name included the
prebuilt_ prefix. That broke the platform_bootclasspath logic as it was
looking for apex variants for "myapex" but the only ones available were
"prebuilt_myapex".
This change ensures that it always uses the unprefixed name and fixes
the TestNoUpdatableJarsInBootImage to match. This also adds some
improved error reporting in platform_bootclasspath which helped debug
this problem.
Bug: 177892522
Test: m nothing
Change-Id: I3e88b5cec767f77dcc0e94b3ae38b499d07eadf0
Boot jars, updatable boot jars and art apex jars are part of two
separate but related configuration objects, the main Config struct
(actually the nested productVariables struct) and the dexpreopt
specific GlobalConfig. The fields in both are initialized from the same
data in the make config files but handled separately.
Previously each test that used one of the configuration objects would
generally just initialize the one it used. That would make the test
sensitive to the specific configuration object that was used. A
refactoring that change the code from using one configuration object to
the other would cause the test to fail.
Also, some tests would inadvertently create invalid configurations by
setting ArtApexJars without also setting BootJars. While the ability to
create invalid configurations is useful (and there are some tests that
exist to verify the behavior in that case) most tests should not be
using them.
This change simplifies the configuration of the tests and improves
their realism by:
1. Providing a new FixtureConfigureBootJars method that takes a set of
boot jars and sets ArtApexJars, and BootJars in the
dexpreopt.GlobalConfig and BootJars in the product variables too.
2. Providing a new FixtureConfigureUpdatableBootJars method that takes
a set of boot jars and sets UpdatableBootJars in both the
dexpreopt.GlobalConfig and productVariables.
3. Migrating existing tests to use these new methods.
Some tests still use the dexpreopt.FixtureSet...Jars() methods directly,
generally to create invalid configurations.
Bug: 177892522
Test: m nothing
Change-Id: I4d8f0b9762cfcc7ae6383bef08563d7c3fa13955
Adds the fragments property to the platform_bootclasspath to allow the
fragments that contribute to it to be specified.
Bug: 177892522
Test: m nothing
Change-Id: I14f83d9336f6984442c7315cc86dfdd0a0fd2d20
Adds a FinalDeps mutator to add dependencies from the
platform_bootclasspath to the configured boot jars which can be from
either the platform or any apex. It adds dependencies for every
configured boot jar, whether in ArtApexJars, BootJars or
UpdatableBootJars.
At the moment the dependencies are only used for testing purposes
but following changes will make more use of them.
Bug: 177892522
Test: m nothing
Change-Id: I981305bf45bc20539a3d36987252f490e2b885cc
This change fixes a bug that shared lib dependencies of an rlib is not
installed to the APEX even when the rlib is part of the APEX.
Bug: N/A
Test: m
Change-Id: I88fe461584499839d8018d6b4292374592e7562b
Previously, SdkSpec was constructed only from the user string. It didn't
make use of the Config struct where information about the latest stable
SDK version, etc. is recorded. As a result, the build system couldn't
check if the sdk version "current" is referring to the in-development
(i.e. not-yet-frozen) SDK version or the latest stable version.
"current" was always assumed to be in-development (IsPreview() returns
true) even when Platform_sdk_final == true.
As the first step for fixing that, this change requires
android.EarlyModuleContext to be passed when constructing SdkSpec from
the user string.
In the following changes, "current" will be mapped to either
FutureApiLevel (10000) or one of the FinalApiLevels() depending on
whether the platform SDK was finalized or not.
Bug: 175678607
Test: m
Change-Id: Ifea12ebf147ecccf12e7266dd382819806571543
The property init_rc accepts paths and references to other modules;
however, none of that is passed onto make, resulting in errors if a
non-local path is used.
Test: m
Bug: 184567830
Change-Id: Idbbf9de66c5182784d055e1cd64bcef34a7dbd79
This follows the same pattern as is used by the prebuilt_apex in order
to make files encapsulated with a prebuilt .apex file available for use
by the rest of the build. It separates the extraction of the
appropriate apex from the zip supplied to apex_set into a separate
module type whose output is used by the apex_set and will (in a follow
up change) be used by the deapexer module too.
Bug: 181267622
Test: m droid
Change-Id: Icd13ce1f21845494e875d3e092abd4a9d2efca57
This dedups the apex selection (which was previously being done by both
the apex.Prebuilt module type and the Deapexer module type) by
separating it out into its own module.
The apex.Prebuilt module retrieves the selected apex from its
selected_apex property which is simply initialized with
":<selector-module-name>".
The Deapexer module retrieves the selected apex it should use from its
src property which is initialized in the same way. That makes it easy
for the Deapexer module to be reused by the apex_set in a similar way.
Bug: 181267622
Test: m droid
Change-Id: I90cfb55698d35a97dcf28b95afcb1f58584bc90c
Previously, the private deapexer module type was treated as a prebuilt
as that was the quickest way to implement it. However, there is no
reason why it should be as there is no corresponding source module type
which it might replace.
This change removes the prebuilt support to simplify the module type in
preparation for future work. As part of that it extracts the logic for
retrieving a single path from a PrebuiltSrcsSupplier to ensure
consistent behavior.
Bug: 181267622
Test: m droid
Change-Id: I1b2bb49601c13a3fff99a0026c235eaa70d2e612
Previously, if an appropriate src property was not specified it would
return "" which resolves to the top level directory. This change causes
it to report an error.
Bug: 181267622
Test: m droid
Change-Id: Ia5be324a0eff18e43b352d71c6768c8767986053
When `test_for` dependencies are added from libraries to APEX modules,
they can be created from the platform variants of the libraries, since
those are used for building tests. Hence we need an alias from the
platform variant of the APEX module to have a target for those
dependencies.
This is only necessary for libraries that are split by the APEX
mutator, i.e. is a member of some APEX. Normally that's not the case
for test libraries, but there may be exceptions (read
com.android.art.testing).
This relands https://r.android.com/1654679 after decoupling it from the
topic that caused b/184239856.
Test: m nothing
Bug: 183882457
Change-Id: If643c75ce9bc25fa01ad9d1e3ba8e1d060d03bb2
All version names will go through ApiLevelFromUser which triggers an
error when the name is not a valid one.
Bug: 175678607
Test: m
Change-Id: Id33bf64085603914d45ad7942cb8908a4734493f
Remove Android-targeting gcc toolchain libraries -- libgcc,
libgcc_stripped, libatomic, and libgcov. Also remove libunwind_llvm,
which is replaced with a libunwind toolchain prebuilt.
The __atomic_* library functions are now part of the compiler-rt
builtins library:
https://android-review.googlesource.com/c/toolchain/llvm_android/+/1625025
Bug: http://b/153025717
Test: treehugger
Change-Id: I971d0a4a49f1aaeb3546e80b6d94208277a171ac
... in preparation for making the handling of sdk versions consistent
across java and cc modules.
Bug: 175678607
Test: m
Change-Id: I598f0454bce9b7320621022115412fbe97403945
This reverts commit 6d15d63556.
Reason for revert: Broke git_sc-mainline-prod on test_suites_x86_64
Fixes: 184305592
Change-Id: I4b2e2675e0dd9e2e84966f545a52f45d5b731bab
Revert submission 1658000
Reason for revert: Breaks full-eng build: b/184239856
Reverted Changes:
I4f8ead785:Avoid internal APEX stubs for libsigchain and clea...
I68affdf69:Allow dependencies from platform variants to APEX ...
I54b33784e:Rename libdexfile_external_static to libdexfile_st...
Id68ae9438:libdexfile_external is being replaced by libdexfil...
I12ac84eb4:libdexfile_external is replaced by libdexfile.
If05dbffc8:Rename libdexfile_external_static to libdexfile_st...
Ia011fa3a8:Merge libdexfile_external into libdexfile.
Change-Id: If494dc5385042a4620a76a9eadc1613ae0eb1655
So far, when a library `libfoo` has `stubs.versions: ["10", "11"]`, then
`shared_libs: ["libfoo"]` is linked to the version 11 of the stub.
This requires the author of `libfoo` to manually update the property
whenever a new version is introduced. Otherwise, clients are not able
to use the newly added APIs because the latest stub is for an old
version.
This change eliminates the need for manual updating. "current" version
is always implicitly added to `stubs.versions`. It is added even when
nothing is set on the property, if `stubs.symbol_file` is set. i.e.
```
cc_library {
name: "libfoo",
stubs: {
symbol_file: "libfoo.map.txt",
// no versions: [...] needed
},
}
cc_library {
name: "a_client",
shared_libs: ["libfoo"],
apex_available: ["myapex"],
min_sdk_version: "29",
}
apex {
name: "myapex",
native_shared_libraries: ["a_client"],
min_sdk_version: "29",
}
```
`a_client` links to the "current" stub of `libfoo` that has all symbols
shown in the map file.
Note that, above doesn't mean that the client has unlimited access to
APIs that are introduced even after the min_sdk_version of the client
(29 in this example). The use of such APIs still has to be guarded with
`__builtin_available` check.
Bug: N/A
Test: m
Change-Id: I70bb1600c18e74d36c6b24c3569d2149f02aaf96
Adds PrepareForTestWithNeverallowRules to make it easy to test
neverallow rules. Avoid exporting any unnecessary neverallow related
methods from the android package.
Bug: 181070625
Test: m nothing
Change-Id: Idfc6955cb23f1a4d1790be7879388154b03f3980
Deprecated the method to try and prevent any other uses being added.
Bug: 183650682
Test: m nothing
Change-Id: Ia6f43851e5a00c9d96af780e3bd21e03175e1a2f
Fixes the few tests that break due to this and which cannot easily be
separated into their own changes.
Bug: 183650682
Test: m nothing
Change-Id: Ia2f31213a1f114a78e66a81d89279ecde9f4c465
When `test_for` dependencies are added from libraries to APEX modules,
they can be created from the platform variants of the libraries, since
those are used for building tests. Hence we need an alias from the
platform variant of the APEX module to have a target for those
dependencies.
This is only necessary for libraries that are split by the APEX
mutator, i.e. is a member of some APEX. Normally that's not the case
for test libraries, but there may be exceptions (read
com.android.art.testing).
Test: m nothing
Bug: 183882457
Change-Id: I68affdf69d7ec05c0ee8730e8ec04d7cb9e0e44a
* changes:
Make test_for arch variant.
Don't use APEX stubs between internal libs in the same APEX when building test_for modules.
Add FilterListPred.
Don't panic on "go test" invocations from the command line.
This avoids having to specify boot libraries in both the boot_image
and separately as java_libs on the apex. Simply add them to the
boot_image (happens automatically ATM when using image_name: "art")
and add the boot_image to the apex.
Bug: 177892522
Test: m nothing
Change-Id: I7e0c41665604b73780cdf0dc555067497b1e6ef0
Allows boot_image modules to be created for any module that contributes
to the boot class path, e.g. core-i18n from the com.android.i18n.
A boot_image module with a contents property cannot specify an
image_name, and vice versa. Only those boot_image modules with an
image_name create .art, .oat and .vdex files, either in their
associated APEX or as part of the framework "boot" image.
Bug: 177892522
Test: m nothing
Change-Id: Idfc2bcf00dd6d3ed36ac4df46fcf18e8aa7e2c92
Adds dependencies for the art boot image. The art boot image only
includes modules from the com.android.art APEX and so this change adds
some verification to make sure that the APEX component of the
configuration is compatible with the boot_image's apex_availabilty
settings and then just adds dependencies on the modules. It relies on
the normal APEX processing to cause the com.android.art variant of the
boot_image to depend on the equivalent variant of its contents.
This purposely does not check that the configuration specifies an APEX
of com.android.art and instead relies on the apex_available property
being set.
Bug: 177892522
Test: m nothing
Change-Id: I75a8238546b01e1f166a1d1444215f4afb441780
This is part of the work to rename boot_image to bootclasspath_fragment
which is being done for two reasons:
1. To avoid clashing with the bootimg module type.
2. To better reflect what this represents.
While a bootclasspath_fragment can create what ART calls a boot image
(which is different to what the bootimg module type represents) it does
not have to do so.
Bug: 177892522
Test: m nothing
Change-Id: Ib45604be7adc790ded9e27a2ac812dd7522ca8db
Previously it was unrealistic because the "boot" image cannot be added
to an apex (because it references modules from multiple different
apexes). Only the "art" image can be added to an apex. So, this change
switches to use the "art" image which requires the apex name is changed
to "com.android.art".
This change also adds an equivalent test for prebuilt_boot_image as
well as a check of the module dependencies for the mybootimage module.
Bug: 177892522
Test: m nothing
Change-Id: I20089b02c80bedc072dbb950dce09bc4e8397f3a
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
Test behavior was changed a while ago so that tests by default ignore
non-existent source paths (unless they explicitly check for/rely on
them). Prior to that CheckSnapshot() could detect when files were
missing from the snapshot but it no longer can.
This change disallows non-existent source files in all the sdk tests
which means that they are disallowed when processing the snapshots as
they use the same preparers as were used to process the sources.
This caused a test failure which has been temporarily ignored and has
a TODO and bug associated with it.
Bug: 183184375
Test: m nothing
Change-Id: I969d8515d20ef5ae515f2b5f93d8ed4e4f8ede75
This change needed to add some additional files to the registered
files for PrepareForTestWithJavaDefaultModules because otherwise they
would fail when "TestAllowNonExistentPaths = false". Those files were
being added by the TestJavaLintRequiresCustomLintFileToExist (albeit in
some cases in different locations to that required by the default
modules but as the files are needed by the modules defined in
PrepareForTestWithJavaDefaultModules they should be defined in it.
A couple of other places also provided some files so moving them into
PrepareForTestWithJavaDefaultModules caused some conflicts which needed
to be resolved.
Bug: 183184375
Test: m nothing
Change-Id: I76ce9f1673c1c1c4000635b76b8377d582224bf1
Creates a new deptag type for it so that it can implement the marker
interfaces that will exclude it from being added to the APEX and from
visibility enforcement. The latter is probably not an issue ATM because
the dependencies are added after visibility checks are enforced but
this code is undergoing lots of refactoring so that may change.
Bug: 177892522
Test: m nothing
Change-Id: Ibd167d557adec761a2e3eed78f4d334c40a04fb9
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
This allows the testCustomizers to be switched to FixturePreparers
incrementally rather than in one go.
Bug: 181070625
Test: m nothing
Change-Id: Idd9d2e28abf9b17fc46b5566ab8d3affa330287e
Not all branches have packages/common/module, which breaks the build
for them.
Bug: 179234385
Test: removed allowed_deps.txt && m apex-allowed-deps-check
Change-Id: I38f47c7200e1afbd899e29843d0214bef826fcf9
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
It just provides the metadata needed by the global singleton as the
rest is in the apex.
Bug: 182402754
Test: m nothing
Change-Id: I511df7a3a06dab13ddb9ad63392ae5310dfee9c4
An upcoming change to create a prebuilt_platform_compat_config module
will break if the apex tries to use it instead of a
platform_compat_config because the former does not provide all the
information that the apex needs. This change will allow the
compatConfigsTag to be configured to prevent the prebuilt from being
used even when it is preferred.
Bug: 182402754
Test: m nothing
Change-Id: Ib9dc06c038f7cf3fc229f3c4d2b025335a4715b4
As this test is the only test in the apex package to use the
platform_compat_config module type it does not make sense to include
that in all the tests so instead this converts the test to use fixtures
so it can easily customize it with the additional module type.
Bug: 181070625
Test: m nothing
Change-Id: I56fda772ee336db6cfb677143aa28b1a18911bff
__ANDROID_VNDK__ is defined for the modules that are able to use the
VNDK libraries. As both product and vendor variants define
__ANDROID_VNDK__, we don't know if a module is built for vendor or
product on build time.
__ANDROID_VENDOR__ and __ANDROID_PRODUCT__ macros can be used to
specify the image-variant-dependent codes.
Bug: 180646847
Test: m nothing
Change-Id: Id6c3e1e3d47deaf3684c0c02964718658cf2fec5
These tests rely on changing the definition of the "libc" module which
is a default module provided by the cc.GatherRequiredDepsForTest()
function. That function is called from within testApexContext() and so
added by default.
Previously, the tests relied on a number of factors to work:
1. All the default cc modules were added to the bp contents that were
passed to testApexContext().
2. testApexContext() passed the augmented bp contents to
TestArchConfig().
3. TestArchConfig() only stored the supplied bp contents in the root
Android.bp file if it did not exist.
So, in order to override the default modules it simply made sure to add
its own Android.bp file into the file system first.
Unfortunately, that does not work with the test fixtures as the default
modules are defined in their own specific paths to avoid conflicting
with each other. To achieve the same effect as previously, i.e. no
default modules, this test uses an emptyFixtureFactory and only adds
preparers for cc and apex build components and ignores the default
module definitions altogether.
Bug: 181070625
Test: m nothing
Change-Id: Ic6b961dd2bd78c32cb326b2c7905426ee971c2d8
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
Unlike the similar changes in other packages this change separates the
addition of the fixture factory and the conversion of the test...
methods to use them as there are a few tests that need converting to
use test fixtures first.
Bug: 181070625
Test: m nothing
Change-Id: Ic76523ba89fc1967631aeb682935935b5af116df
While debugging an issue with some work I was doing on boot image
modules I noticed that markPlatformAvailability() is calling
DepIsInSameApex() even when the dependency tag indicates that it is
excluded from the apex contents.
Test: m droid
Change-Id: Iac49049546a886f7a3a0d9640ffd31ce24c61364
The sdk_version: "core_platform" refers to the stable core platform
unless the module is in the exception list. This change makes sure that
CheckStableSdkVersion() reflects that behavior.
Bug: 180399951
Test: m nothing
Change-Id: Ia0b1e13322352b87f5a3c6621e37f23ba637ffb6
