strict_updatability_linting currently only makes it so
that NewApi can't be added to the lint baseline.
However, since we're updating NewApi to work on a lot
more apis than before, we need to baseline many issues
across the android tree. Temporarily disable
strict_updatability_linting so that we can add these
baselines.
Bug: 193460475
Test: Presubmits
Change-Id: I8d92df95a46e9b903f0cc0e3be56f17722c50430
When set true, use file_contexts file as is and do not force-label / and
/apex_manifest.pb
Bug: 268439003
Test: m (soong tests)
Change-Id: I252eef9569deeac87bb71a3425a8eb07bab3c634
The type of min_sdk_version is being migrated from
android.SdkSpec(kind+level) to android.ApiLevel(level). This affects
`ShouldSupportSdkVersion` for java modules. This function skips the
check for modules compiling against `core`, and that requires access to
SdkVersion and not MinSdkVersion after the migration.
Skip the check explicitly using SdkVersion.
Test: go test ./java
Test: No change in ninja file
Bug: 208456999
Change-Id: I14eca4f8e8c5d7477ded00c4fe54097323fab4a2
Implement APEX stub of API surface so any stub can be replaced with API
surface when APEX stub interface is required.
Unlike other stub interface, APEX stub can be decided if it should be
used after APEX postdeps mutator analyzes which modules should be
included in which APEX. To cover this, APEX stub is being added to the
dependency if the dependency should not be covered with LLNDK or NDK
stub, and APEX stub exists. From depsToPaths, if dependency to both
original module and API library exists, then it choose one of the
dependency and ignore the other.
To cover this logic, a new property is added to the api_surface :
apex_libs. This is introduced as it is difficult to
gather all api library with apex stub before DepsMutator.
Bug: 264963986
Test: cf_x86_64_phone_vendor build succeeded
Change-Id: I9f0b1f70968e32eba94d3e0d7bb1f4bb29ff2438
There are no current users of overriding rros, so it's dead code.
Additionally, there is some evidence of accidental misuse, so remove it
for now as we don't want arbitrary properties of AOSP modules to be
overridable in the general case.
Bug: 270542561
Bug: 269568074
Test: presubmit
Change-Id: I030abd644358baefc0d1543649c8a2a81a7491d0
This reverts commit be90172f0a.
Reason for revert: not used, and not desired
Bug: 270542561
Test: presubmit
Change-Id: I415440dbae965f3c07c6f3ccf6ab4bc9ec57fbf6
This reverts commit dd2c76e772.
Reason for revert: This was submitted without build system team +2 with no rationale for why it's needed.
Change-Id: I86b9849122ec2b7a382d4f39bbbc0ea1ff70c4bc
This property allows an APEX bundle to ignore the apex_available rules
defined in its dependencies, effectively allowing it to use any APEX
as its dependency.
Bug: 269660351
Test: m
Change-Id: Ib2797e04438ad908ac10b256dce07a7819e836b3
Previously, the symlink optimization for APEXes assumed that the target
of the symlinks are in the system partition. The assumption however
doesn't hold always because the file that was added to the APEX might be
with system_ext_specific: true or vendor: true.
Bug: 265598720
Test: m nothing
Change-Id: Ieb9a6769320c0ec697a88c0cae977e7d65288362
* changes:
Use the profiles in the APEX to dexpreopt system server jars.
Add tests for the ignored "profile_guided: true" property.
Output dex_preopt to SDK snapshot.
After this change, if "profile_guided: true" is set, profile-guided
compilation will be enabled for the jar and the ".prof" file next to
the jar in the APEX ("javalib/<name>.jar.prof") will be used as the
profile when dexpreopting for the prebuilt APEX.
Bug: 241823638
Test: m nothing
Test: -
1. (on internal master) Patch aosp/2426453.
2. Build the APEX bundle and the module SDK of com.android.wifi
3. (on tm-dev) Patch this CL and aosp/2141972.
4. Copy the APEX bundle and the module SDK built on step 2 to the
source tree
5. Disable hiddenapi check
6. lunch cf_x86_64_phone-userdebug && m MODULE_BUILD_FROM_SOURCE=false com.google.android.wifi
7. cat out/soong/.intermediates/prebuilts/module_sdk/Wifi/current/prebuilt_service-wifi/android_common_com.android.wifi/dexpreopt/oat/x86_64/javalib.invocation
8. See the profile being used.
Change-Id: I55a5a295e9c5d6f0564afb139c5fb7da91ab8cae
The tests in bootclasspath_fragment_test setup the environment to have
two APEXes: a source one and a prebuilt one. Before this change, the
tests for prebuilt incorrectly check the contents in the source one.
This change introduces a new function that properly checks files
deapexed from the prebuilt one.
Bug: 241823638
Test: m nothing
Change-Id: I1865c20b198d50e7ebc8ebfb9f7c71394a225ab7
filesInfo should not be used for an apex that's converted to Bazel,
since all information should come from the Bazel starlark provider.
filesInfo is populated when there's a full Android.bp module graph of
the apex deps.
Test: presubmits
Change-Id: I4b9c596ca7841f4ea76e21f929039282113b6752
So that it can be used in the bazel implementation.
Bug: 268006095
Test: m nothing, check that it's in out/soong/soong_injection
Change-Id: I1520dd874076dee7fa083648d0790b060d658e5a
This reverts commit d1209a89c7.
Reason for revert: apex_name was still in use in the internal/intermediate branch. Fixed(removed apex_name) in the internal branch.
Change-Id: I10b8e0cfdb01dcdb6b623bddf9c04f4dac71fc90
After this change, if profile-guided compilation is enabled for an APEX
system server jar, the profile will be installed next to the jar with
the ".prof" suffix, ("javalib/<name>.jar.prof"). This file will later be
used by odrefresh and dexpreopt from prebuilt APEX.
Bug: 241823638
Test: m nothing
Test: -
1. Patch ag/20581649 PS2.
2. banchan com.android.btservices x86_64 && m
3. Check that "javalib/service-bluetooth.jar.prof" exists in the APEX.
Change-Id: Ibcfc6257dade92bd40a6d4b7368148717d0863b9
apex_name was used to install symbol files under /apex/<apex name>,
which caused duplicate rules when there's two apexes with the same
apex_name. (e.g. override_apex or multi-install apexes)
Since symbol files can be looked up via ELF Build-Id, we don't have to
install symbol files with the actual "apex name", but instead we can
install them with soong module name.
Bug: 267581665
Test: m (soong test)
Change-Id: I1cbe5c86d287f180c7deef93ba85ea5552680011
Previously in mixed builds, only the tidy files for the boundary module
were built, whereas all of its transitive dependencies' tidy files were
not being built. Instead we should export the list of transitive tidy
files for a module so that we can run clang-tidy for the boundary module
as well as its dependencies.
Bug: 195029134
Test: WITH_TIDY=1 DISABLE_ARTIFACT_PATH_REQUIREMENTS=true mss tidy-packages-modules-NeuralNetworks --bazel-mode-dev
Change-Id: I463646d2ae1fc4aa075a54c264e1c34571c3fd5c
This has been a workaround to avoid duplicate build rules for
multi-install apexes. The reason for duplicate errors was that apex_name
was used to install symbol files.
We don't need to rely on apex_name for symbol files, hence no need for
the workaround.
Note that symbol files for apexes are still available via the paths
based on "soong module name".
Bug: 267581665
Test: cuttlefish (which uses multi-apex) build & run
Change-Id: Icaca667e139ef2aca32339a75b54b12a00449c2d
VNDK APEX has been using "apex_name" property to set "name" field in
apex_manifest. But setting apex_name had a side-effect of emitting
duplicate rules for symbol files for VNDK APEX and its override_apex.
(Please see the removed comments for more details about error)
Not using "apex_name" fixes the duplicate errors.
There're a few more vendor apexes with the same issue, which I will
handle in follow-ups.
Bug: 267581665
Test: m (soong test) && boot
Change-Id: I00f617cef8af4d21880d4e8b9c0b9ab9322ba15c
Since fe4ff29b4d47fa8ae242fb7e084215d3afada4b5 (in system/apex), apexer
doesn't check keyname (--key vs --manifest.name). So, passing
--do_not_check_keyname doesn't make any sense.
This is a preparation to remove (or deprecate) "apex_name" property from
"apex" module.
Bug: 267581665
Test: m
Change-Id: I3737d1e36d305375a523a23a6bbeb2d23586e578
It makes sense to make min_sdk overridable because the override_apex is
a variant of the original apex, and this variant might be
created/introduced in the newer Android release compared with the base
apex. Despite the fact that the source of the variant apex is the same
as the original one, the variant may not support the older version, like
Go modules, trimmed modules. If we consider the variant as a "new"
module, then it makes sense to have a new min_sdk to make it only
available for the newer Android released version only.
Bug: 266945903
Test: Build locally, and check if the override works
Change-Id: I7f4c7169e15b7e57f44a4abafe012151dbc226a0
Disable VNDK apexes when their version is below the minimum
supported API level for the primary architecture.
Test: TestVndkApexCurrent
Change-Id: Ie72a5beb9da432660d3fec5c520402224326f961
This piggybacks onto the ApexInfo cquery handler, so we're issuing a
single bazel query call that reads two providers in the starlark expr.
Also rename requiredDeps to makeModulesToInstall to differentiate it from
APEX's required/provided libs in the apex manifest.
Test: unit test
Test: mkdiff
Fixes: 263123189
Change-Id: Ib7e43f1586f29864eee8627dba3631bfaff27afa
This reverts commit eb8cd3122a.
Reason for revert: mainline module jacoco jar do not contain JAVA_LIBRARIES needed for coverage, see: b/266679012
Change-Id: If756f7aaf40c6bcfed170c59c494bcc426620039
Apex builds are setting LOCAL_REQUIRED_MODULES to include external
dependencies into the system image. This make sense for device builds,
but just causes extra unnecessary builds for unbundled apex builds
that are not building device images. Skip the dependency during
unbundled builds.
Test: aosp-master-art mainline_modules_x86_64-userdebug builds
Change-Id: I363995b7309cc3c90b0a584d051050f105b5b915
