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
Checks to make sure that every module that is part of the platform
bootclasspath has been initialized property for hidden API processing.
Bug: 177892522
Test: verified that the out/soong/hiddenapi/... files are unchanged
by this change
Change-Id: Ic4368963f2011784b537b8aebf5ef97ea22b2db5
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
incompatibilities.txt doesn't exist anymore, only
"<module>-incompatibilities.txt". Clean up the associated logic that
mapped incompatibilities.txt to android-incompatibilities.txt.
Bug: 178171189
Test: m
Change-Id: I61eeb5dcc82770fa2af356bad11b7205551d6d83
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
Previously attempting to use m UNSAFE_DISABLE_HIDDENAPI_FLAGS would
cause a build failure.
It is necessary when UNSAFE_DISABLE_HIDDENAPI_FLAGS=true to create
empty files for the monolithic files so that those usages which are not
protected by the build flag, e.g. in dists or CTS tests like
CtsHiddenApiBlocklistTestApiTestCases do not cause ninja failures due
to reliance on a file that does not exist and has no rule to create it.
Bug: 177892522
Test: m nothing
m UNSAFE_DISABLE_HIDDENAPI_FLAGS=true CtsHiddenApiBlocklistTestApiTestCases
Change-Id: I05d0b3680dbc0b5b7c7c0d792550faf848829647
Change https://r.android.com/1673266 introduced some code that does
nothing. This change removes that.
Bug: 177892522
Test: m nothing
Change-Id: I349b17c7fe7e2f68a807dab43a4300da7fe0ad4d
A skeleton of a classpath fragment's interface and base to be used by
any modules that provide entries for *CLASSPATH variables at runtime.
In follow up changes, this would be extended to generate
packages/modules/SdkExtensions/proto/classpaths.proto configs for such
modules to be bundled into system and individual apex binaries.
Bug: 180105615
Test: m
Change-Id: I2df550862e97222c5650c4d0480c90231fd78ef0
Makes the monolithic hidden API files accessible from the
platform_bootclasspath so they can be output to the dist build target
and used by other modules, e.g. by doing something like this:
java_resources: [
":platform-bootclasspath{hiddenapi-flags.csv}",
],
It makes the paths relative to the out/soong/hiddenapi directory rather
than the out/soong directory to make them easier to use in the
java_resources property without changing the structure of the APK.
Without that attempting to use them in a java_resources property will
result in them being copied to a hiddenapi/ within the APK instead of
being used at the top level as existing APKs like
CtsHiddenApiBlocklistTestApiTestCases expect.
Bug: 177892522
Test: m nothing
Change-Id: I829412fc7d25411e0c2e0713d0d219a18f4af2ee
This change moves the generation of the global hidden API flags from
the singleton to the platform_bootclasspath module. It involves:
1. Moving the ruleToGenerateHiddenApiFlags to hiddenapi_modular.go.
2. Adding HiddenAPIAugmentationProperties to be used by the
platform_bootclasspath type.
3. Moving the file paths into the platform-bootclasspath module
definition in frameworks/base/boot/Android.bp.
The flagsRule is kept as a placeholder for now. The emptyFlagsRule is
also kept so that builds continue to work even when the frameworks/base
repository is not present.
Bug: 177892522
Test: verified that the out/soong/hiddenapi/... files are unchanged
by this change
Change-Id: Idf4dd414a016831bfe04a01f93234c1c33819881
Extracts the code for creating the rule that creates the monolithic
hidden API flags file which is encoded into dex implementation jars.
This refactoring is in preparation for moving the functionality from
the hiddenapi_singleton into the platform_bootclasspath.
A follow up change will move the method into the new
hiddenapi_modular.go alongside the hiddenAPIAugmentationInfo as they
will both be used to perform hidden API processing for a
bootclasspath_fragment.
Bug: 177892522
Test: verified that the out/soong/hiddenapi/... files are unchanged
by this change
Change-Id: I2729afa80cdfd2d1d4717365001648453d65632f
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
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 public stubs were being matched against the string ".stubs.public"
which was never the suffix that these stubs used
- Remove obsolete naming pattern matching
Test: m
Change-Id: I1f7bd54e4629f42e34fb3c09828d8853813ba2a7
Remove a date from the lint HTML output to make it deterministic.
Bug: 183509050
Test: m out/soong/.intermediates/packages/apps/DocumentsUI/DocumentsUI/android_common/lint/lint-report.html
Change-Id: I796c0b571780814b657b9427a17c248668053983
From an ART perspective, calling module-lib APIs requires the
ability to bypass hiddenapi enforcement entirely. This CL ensures
that if an APK compiles against module-lib APIs, it will be able
to call those APIs. Currently, compiling against module-lib APIs
is not safe because APKs that are subject to hiddenapi protection
will crash at runtime.
Bug: 181309531
Test: made NetworkStackNext compile against module-current, and:
Test: aapt dump xmltree .../NetworkStackNext.apk AndroidManifest.xml | grep usesNonSdk
Change-Id: I5ca3328c64412078d803e0e3ffa1d8383602416f
SdkSpec.Version was an int type. Now it becomes ApiLevel type which
is a better abstraction of the version (or api level).
Bug: 1655587
Test: m
Change-Id: I4d67b9b9eae45f653b6af4f5b73da9e091b3dfab
... 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
Initially, this is just a placeholder but functionality will be added
in follow up changes.
Bug: 177892522
Test: m nothing
Change-Id: I890b0d5a117c51a19c9ac5df98c766761d3aa16c
