Remove all modules from legacyCorePlatformApiModules that exist
in internal master and build without the legacy stubs in an
aosp_sunfish-userdebug build.
Bug: 161973015
Test: builds
Change-Id: I2e6248ec0cde0d751f66f32bc7e787b7adbfb75b
Remove all modules from legacyCorePlatformApiModules that exist
in AOSP and build without the legacy stubs. The remaining modules
that exist in AOSP in all products and still need the legacy stubs are:
framework-jobscheduler
framework-minus-apex
framework-minus-apex-intdefs
FrameworksCoreTests
services
services.core.unboosted
Settings-core
SettingsLib
SettingsRoboTests
telephony-common
TeleService
The remainder of the modules still in the list either only exist in
internal master or are product-specific.
Bug: 161973015
Test: builds
Change-Id: I8995670aaaa8dce8e4a870ec1700d1dd7be7c95e
Remove modules that don't exist in an internal master
aosp_sunfish-userdebug build and also have no references in
codesearch.
Bug: 161973015
Test: builds
Change-Id: I4372f140b3fc7d6a9cda01a243f200fe084ef099
Sort the modules in legacyCorePlatformApiModules to simplify removing
unnecessary entries. Also remove a comment that doesn't add any value
and makes it harder to run scripts against the list.
Bug: 161973015
Test: builds
Change-Id: I0886baa42209600cfd1e16e5d4919a784efe29ab
SystemUI seems to build fine against the stable core platform API.
Bug: 161973015
Test: m SystemUI-core SystemUISharedLib SystemUI-tests
Change-Id: I584f98f991e0b9c8b1a5dba1fcc1bef0745dbdc0
There are no riscv64 prebuilts in apex sets, use arm64 ones for
now.
Test: lunch aosp_riscv64-userdebug && m droid dist
Change-Id: Iee2d669e01d93504642223939857634b7fd1c1ba
Allow genrules to access the turbine header jar outputs
from java_library modules using the .hjar output file
tag.
Bug: 251871740
Test: m checkbuild
Change-Id: Ib1ec9734323a51583057fb458f791e1e0bd0d767
Since Bazel's java_import requires a jars attribute to be specified,
the generated neverlink-duplicated module is of type java_library
Change-Id: I14a866dfc583507a9462add50d95060cbfe540c5
Bug: 244210934
Test: m bp2build, go test ./bp2build, manual inspection of generated Build and jar files
Any device java_binary that doesn't have a specific wrapper must
have a main_class property, which is used to generate its default
wrapper. Otherwise its build should fail.
Bug: 250851599
Test: TestDeviceBinaryWrapperGeneration in java_test.go
Change-Id: Ice4c580bcfc1b92f95e217b39e984c55d25a3a02
Rather than individually denylisting filegroups until we prioritize a
solution for mixed builds that will correctly integrate into uses such
as proto, aidl, gensrcs, etc.
Test: mixed_droid
Change-Id: Iddbd391af7dd7cabc892b2b26dbc68e3aa506471
Allow new robolectric to break soong's exepected machine type restrictions
Test: mma in /external/robolectric
Bug: 244627502
Change-Id: If58a36b2d84804d586d9c8a773e2e739867fa987
Soong supports string properties, but they are overloaded, and can mean
one of three things:
* path reference
* module reference
* string literal
Bazel has different types: label and string attributes. Thus there needs
to be a way to categorize them correctly in bp2build.
This CL introduces a new function to be used on properties like
apex_key.private_key / apex_key.public_key, as well as
android_app.certificate / apex.certificate.
It is important to disambiguate the prop betenn a string literal
attribute or file/rule target label attribute, so this functions does
just that. The new attributes are then further handled by their
respective macros (apex_key, android_binary, apex).
Bug: 253557437
Fixes: 253557437
Test: presubmits, new tests
Change-Id: Id8111cdd60d3aabcae7d17fe9da84d0ee3966023
android_test_import is to import prebuilt test apks into the build rule.
It doesn't support properties like test_config, test_config_template,
and etc, but those properties were anyhow added to the module type and
setting those properties didn't trigger any error.
Fixing this surprising behavior by adding only the properties that are
actualy being used.
Bug: N/A
Test: N/A
Change-Id: I93e821e108861fa1249bc5e0882d706849bcf43f
ag/19500070 causes errorprone to fail with out of memory errors.
Also in aosp/2215048 the regular javac heap sized was increased
to 4096MB, so the errorprone heap size wasn't any larger anymore.
Bug: 240473481
Test: m RUN_ERROR_PRONE=true SystemUIGoogleScreenshotTestsLib on internal master
Change-Id: Ie6bdce9f2e7620c076213f4c3313960fd537967b
Follow-up to aosp/2065271. "private" is a Soong internal `SdkKind`
definition and is probably more meaningul for devs who work on
the build system. Changing it to "private platform APIs" should
hopefully make it more meaningful to a wider audience.
(Context: https://yaqs.corp.google.com/eng/q/4927173287831666688)
Test: None
Change-Id: Ied7198bb529eeaa85bc741177b414e06a7262365
suggested-fixes.zip is useful even when lint is exiting with an
error. Save the exit code from the lint executable, create the
zip file, then re-exit with the exit code.
Bug: 216456886
Test: Introduce lint error, verify suggested-fixes.zip is created.
Change-Id: I0ba6190e3de0744e53b2a59ba3016861f2f115e2
Currently, Robolectric test written in Kotlin may not run, especially
when shards are in used, for example SettingsRoboTests has 10 shards.
This is because Robolectric test currently only recognize java files,
adding kt files to fix.
Rename current uniqueSrcFiles to uniqueJavaFiles, and compiledJavaSrcs
to uniqueSrcFiles. uniqueSrcFiles will contains both Java and Kotlin
files.
Note: android.FirstUniquePaths cannot be used, seems the behavior is
different and cause build error.
Bug: 252355400
Test: cd build/soong && mm
Test: m RunSettingsRoboTests with Kotlin tests
Change-Id: Id530ae4dcabffe01a06f44fe4234ffc67b73a601
Previously, in a build containing source and prebuilt art
bootclasspath_fragments, the bootImageVariant.licenseMetadataFile was
set twice with the source always being set after the prebuilt and
so winning.
This change only sets bootImageVariant.licenseMetadataFile for the
active module so it will use the prebuilt's license file if that is
preferred.
Bug: 245956352
Test: m nothing
Change-Id: I948c7e5123169452f67c85ad98c4bbdb90a5d2de
Most of the fields in the bootImageConfig/Variant structs are assigned
inside a Once func so are guaranteed to be only set once. However, some
are assigned outside. This change adds comprehensive tests for those
structs and verifies that the constant fields are preserved and the
mutated fields have the correct value.
The check for the constant fields is added in a new TestBootImageConfig
test.
The check for the mutated fields is added into
TestSnapshotWithBootclasspathFragment_ImageName as that test checks an
art bootclasspath_fragment in the following configurations:
* source on its own
* prebuilt on its own
* source and prebuilt with source preferred
* source and prebuilt with prebuilt
It reveals a couple of interesting facts:
* All the *installs fields are set to the same value irrespective of
whether the source or prebuilt is preferred. The information is
constructed solely from information already within the
bootImageConfig/Variant and so can be moved within Once.
* The licenseMetadataFile is incorrect when prebuilt is preferred.
That is due to both the source and prebuilt modules setting it and
the source module always wins as the source module depends on the
prebuilt so always runs its GenerateAndroidBuildActions after it.
Those issues will be cleaned up in following changes.
Bug: 245956352
Test: m nothing
Change-Id: If917cfbcb3b1c842a8682d51cc1ee1fed1c51add
Sometimes it is necessary for some functionality to be disabled while
running in unit tests, e.g. functionality that requires external
information such as error prone tools and configuration. Sometimes it
is necessary for some functionality to be enabled while running in
unit tests, e.g. functionality that makes state available for
testing but which is not necessary at runtime.
Previously, that was done by checking to see if TestProductVariables
was nil. This change adds a method to abstract that.
Bug: 245956352
Test: m nothing
Change-Id: I7845b79328e7180623161a9bf897568089da4e4f
* changes:
Remove deviceInstalls from bootImageVariant
Remove profilePathOnHost from bootImageConfig
Document bootImageConfig and bootImageVariant structs
* changes:
Move fuzzer's CollectAllSharedDependencies into GenerateAndroidBuildActions
Support AllowMissingDependencies in prebuilt_apex modules
Support AllowMissingDependencies for apex dependencies
Add AllowMissingDependencies support for prebuilt_etc module with no src property
Make OutputFileForModule work for AllowMissingDependencies
Fix panics when target arch is riscv64
Previously, a java module with sdk_version: "system_server_current",
would only be able to access the system server or public API of a
java_sdk_library. This change allows it to access the system server,
module lib, system and public APIs in that order.
The apiScope structs define the characteristics of each of the
different API scopes used as required by the java_sdk_library. They are
organized into a hierarchy which is used for two different purposes.
The first purpose is to define an extension hierachy. If scope X
extends Y then X provides a superset of all API elements (classes,
fields, methods, etc) provided by Y. That is reflected in the fact that
the .txt file for X would be a delta on the .txt file for Y. So, system
extends public and so system_current.txt only contains additional API
elements to add to current.txt.
The second purpose is when a java_sdk_library/import is asked to
provide a specific API scope. e.g. a library that has:
sdk_version: "module_current"
will ask each of the SDK libraries it depends upon for a module-lib
API. However, not all of them will provide an API for that scope. In
that case it will find the closest suitable API scope.
Previously, it did that by traversing up the API extension until it
found an API scope that it did provide and return that. As
system_server_current extended the public API that meant that a library
which has:
sdk_version: "system_server_current"
would provide a system server API if available, and if not fall
straight back to public. That meant that the library could not access
system or module-lib APIs even though it is running in the system
server which should be able to access all APIs.
One way to fix this would have been to just have system server API
scope extend module-lib but that would have had a number of nasty
side effects:
* It would have created a significant overhead as every module that
provides a system server API would also have to provide a module-lib
and system API, along with their corresponding .txt files.
* Each existing java_sdk_library that provided a system server API
would need those .txt files created.
* Generating sdk snapshots for older releases would have been more
complicated.
* It would have confused developers.
All of that would be unnecessary because the system server API scope is
intended to be provided by libraries that are used solely by the system
server so there is no point in them providing anything other than a
system server API.
So, instead a separate access hierarchy was added which is the same as
the extension hierarchy for all existing scopes except for the
system server scope, which instead of just being able to access the
public API will be able to access the module-lib scope, which can in
turn access system and it can in turn access public.
That achieves what we want which is a library that is loaded into the
system server to be able to access all API scopes.
Bug: 204176972
Test: m nothing
Change-Id: I854df63fcaeba32afbc1eb0d1a501238022673d0
The use of this field to return information from buildBootImageVariant
up the call stack to one of the callers resulted in data races being
detected. This change simply passes the deviceInstalls up the call
stack.
Bug: 245956352
Test: m nothing
go test -race ./sdk/... -run TestSnapshotWithBootclasspathFragment_ImageName -test.count 100
# Run the previous command without this change and sometimes it
# shows the data race around deviceInstalls. When run with this
# change it reports no data races.
Change-Id: I3c73920dcb17a6c89a63c6a9c3a0bb049a98a690