| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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
|
|
Required due to minor refactor of libcore projects.
Bug: 208656169
Bug: 255273691
Test: TH
Change-Id: Ifd2ef6d3553ade5a059880398075c70635d428dd
|
|
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
|
|
Long live Java modules system.
Fixes: 254752344
Test: run build_kzip.bash
Change-Id: I9c807afd22d7b2abc2af1f6ac7a0c1e4c8a8b3e1
|
|
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
|
|
Test: m example_java_jni_fuzzer
Bug: 252846698
Change-Id: Ib583de335482350bfe293f9c3d021a595edd4f44
|
|
|
|
Revert submission 2211596
Reason for revert: No longer needed after aosp/2215568
Change-Id: Ia770525501d89baa25e22c2df4fb098d056743f6
|
|
|
|
|
|
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
|
|
|
|
Bug: 246398305
Test: SANITIZE_TARGET="fuzzer hwaddress" build/soong/soong_ui.bash --make-mode -j86 haiku-java-device dist DIST_DIR="/usr/local/google/home/mhahmad/Desktop/android2/OUT"
Test: SANITIZE_HOST="fuzzer address" build/soong/soong_ui.bash --make-mode -j86 haiku-java-host dist DIST_DIR="/usr/local/google/home/mhahmad/Desktop/android2/OUT"
Change-Id: I52c1a6292f5555490aabcb97a449b6c32d57c074
|
|
|
|
|
|
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
|
|
Needed to generate the system-server api database.
Bug: 193460475
Test: go test
Change-Id: I8c6bb3cc1d16ae128b7bcd2513fce4a83e852a5e
|
|
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
|
|
|
|
Bug: 240322840
Test: unit tests
Change-Id: I6b07cf57dc113e3805346e50ef9896471df9f53c
|
|
Bug: 245956352
Test: m nothing
Change-Id: I6402573b378eee77d802829ec5dfacf4c514d3b8
|
|
|
|
Bug: 245956352
Test: m nothing
Change-Id: I4c0bfd24febd308d8efa62da9603795a7e5ed222
|
|
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
|
|
module-lib APIs"
|
|
* 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
|
|
The use of this field to return information from bootImageProfileRule
up the call stack to one of the users resulted in data races being
detected. This change simply returns the profile path back 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 profilePathOnHost. With this change
# that data race is not reported. Although there is still another
# data race.
Change-Id: I03b09e514cc94f2a6c9d5117d3b2f130cc2e4f5b
|
|
Add warnings to the structs to explain how they are supposed to be used
and deprecate fields that are used incorrectly.
Bug: 245956352
Test: m nothing
Change-Id: I090698287b96fd37102b88beb5d7252977bddc54
|
|
This reverts commit be3a561aac8ddc329dd89429b56b82690fd9a65d.
Reason for revert: Reland switch to JDK 17
Bug: 233029164
Test: TH
Change-Id: Ifa69e3fd50b853153a9c23756269ff12e72d7e9f
|
|
Fix panics in api_level.go and apex.go when using riscv64 as the target
arch.
Bug: 250918230
Test: lunch aosp_riscv64-userdebug && m ALLOW_MISSING_DEPENDENCIES=true nothing
Change-Id: I85c7685f3d14fa2dc7ffbcdea7f490feca304ef7
|
|
Context
- Android-<target>.mk currently does not contain information about partition for its dependent unembedded jni libraries, but only lists the name of the unembedded jni libraries.
- If an android_app module depends on an unembedded jni library that is located in a different partition, make cannot find the library.
Implementation
- Create a string field partition in jniLib struct.
- Add variable "LOCAL_SOONG_JNI_LIBS_PARTITION_<target>", an array of mappings of the name of the jni library to its partition.
Bug: 154162945
Test: m
Change-Id: I6b8e1272ff59dc70e3dd6ce8c6c8e4686dad76df
|
|
The certificate module is handled the same in Soong between android apps
and apexes, so share the bp2build code as well.
There are a few changes in this CL:
- If override_apex.certificate is unset, the generated apex also unsets
it. This prevents the generated apex from using the base apex's
certificate, which is most likely incorrect (e.g. google variant using
the cert for the aosp variant). Instead, rely on the default
certificate handling in the macro.
- If the certificate prop is a string, then it gets generated into
certificate_name in order to disambiguate. This behavior is identical
to android_app.
Test: added various unit tests.
Bug: 249089160
Fixes: 249089160
Change-Id: I99e18964ff546429a985d0f64dc21e2c69d35d9d
|
|
|
|
Revert submission 2164342-use-jdk17
Reason for revert: DroidMonitor-triggered revert due to breakage b/250426490
Reverted Changes:
Ib1a24e7ea:Update path for libjli.so
I3375bd4e4:Use the toolchain from JDK 17
I9183e5511:Use the toolchain from JDK 17
Change-Id: I28fc32290dd337b7d44bb98bc52956ee84f01aaa
|
|
|
|
|
|
|
|
Introduced in aosp/1756510
Change-Id: Ib4d0c8fa3c8741bf3e80b8daa53a3d2ce36ce565
Test: presubmit
|