A number of tests in the cts/tests/signature/api-check check for the
accessibility of classes from the android.test.base,
android.test.runner and android.test.mock libraries. Some tests expect
to find the classes other do not. Unfortunately, the tests use
libraries, specifically compatibility-device-util-axt, that depend on
the android.test... libraries which causes Soong to implicitly add
<uses-library> entries to the manifest so that they will be accessible
at runtime. That causes the tests that do not expect to find the
classes to fail.
Bug: 209607558
Test: m nothing
Change-Id: I54c194ab23d5a70df790ece3fe98f2b3d6a1c1f6
Currently error messages appear like:
&fs.PathError{Op:"open", Path:"..." Err:0x18}
which make them difficult to parse.
Test: CI
Change-Id: I18da18abc43230d0ea37d166179d07e585077f51
* Work around RBE preprocessor bug, which rejects double dash flags.
Bug: 217778010
Test: make tidy-soong_subset
Change-Id: Ic7c0a95ae7afefb49cc9d124fd3c9f38fe2e0f56
CI builds are doing m installclean between them;
which is not causing the system_dlkm to clean
it's build.prop and it is stuck to the first CI
build when feature landed causing ota signing
test to fail.
Local reproduction using:
m installclean && m -j96 && m dist
validate_target_files out/dist/*target_files-*.zip
Bug: 217507332
Test: Local verification, TH & Forrest
Signed-off-by: Ramji Jiyani <ramjiyani@google.com>
Change-Id: I97f2011a61252d3cb798af0fab99221b754328ca
Bug: 151177513
Bug: 210912771
Test: m all dist
Test: flash; About Phone -> Legal Information -> Third-party licenses
Change-Id: I9b9e3a67230dae6236ee5c5d6dc6edbc23c5a91d
This flag has never done anything for ld.lld, since it has this behavior
by default (and actually can't turn it off either). It's now being
removed as a valid flag from ld.lld, so it's time for Android to drop
the unnecessary flags. See https://reviews.llvm.org/D118942.
Test: builds
Change-Id: I22c344b7a55e275c1fbd5fef25f85e97a39de5c4
In case there are two vendor apexes(one with "use_vndk_as_stable:true",
and the other with "use_vndk_as_stable:false") a VNDK lib used by both
will have "APEX" variant and the former APEX will use "apex" variation.
For example,
apex1(use_vndk_as_stable) -> foo -> libvndk
apex2 -> bar -> libvndk
Since foo, bar and libvndk are mutated into two APEX variations("",
"apex10000"), foo will use the apex variation of libvndk.
To fix this, VNDK libs can use "unique" APEX variations. Then, in the
above example, foo will have "myapex1" variation and libvndk will have
two APEX variations("" and "apex2"). So foo will link to ""(non-APEX)
variation as fallback.
Bug: 216847402
Test: m nothing (soong tests)
Change-Id: I116932860ef79e22dc338a58b251e3ca693ab4f3
Even though a vendor APEX sets use_vndk_as_stable:true it was possible
to include a VNDK lib by directly depending on it with
native_shared_libs.
But it's contradictory to have a VNDK lib while declaring not to include
VNDK libs. It was missing since pruning dependencies on VNDK libs was
done only for transitive deps.
Added a check to reject this.
Bug: 216847402
Test: m nothing(running soong tests)
Change-Id: I8d79a434b1bfe8e563cf8968fa76830b0e582f66
Soong modules that are specific for the host platform (e.g.
java_library_host, cc_binary_host, java_genrule_host, etc.) should
not be built on the target platform (Android), so we add a
target_compatible_with attribute to skip this type of module on an
Android target build.
Bug: 215229742
Test: go test ./bp2build
Change-Id: Ifb76ef4e0dc4cb3adb6a64b5c375ce36f7973e48
To unblock mixed builds, uses a common mechanism to determine cc module
type across bp2build and mixed builds.
Test: mixed_droid.sh
Change-Id: I1f69ad0858cda549b7c95dbadd596e46df0f23b2
Currently, mk2rbc is structured around having a global
"receiver" object that accepts all starlarkNodes. As soon
as they are parsed they are added to the receiver.
Returning the parsed nodes to the calling function is more
flexible, as it allows the calling function to restructure
them as necessary. This is the first step to supporting
complicated statements involving $(eval), such as
`$(foreach v,$(MY_LIST),$(eval MY_LIST_2 += $(v)))`
Test: go test
Change-Id: Ia194123cf090d2b9559a25b975ccbc5749357cc0
Also, because java_plugin is only intended to be built for the host
platform to make additions to the javac compiler, a compatibility
requirement is added to java_plugin that ensure that it is not built
for android targets.
Bug: 215229742
Test: go test ./bp2build
Change-Id: I09902215a9f1e8b14d4de5a51328d08a7a0a4450
This commit enables conversions of java_library_static and adds the
static_deps Soong attribute to Bazel deps for all Java libraries.
Currently, Soong handles static dependencies for Java differently, and
Bp2build may need to address that later (see b/217236083).
Bug: 215229742
Test: go test ./bp2build
Change-Id: I4f86780c634dca0a2cfb9294084b14e139cc2375
If the build file contains the apex_test module, add the
testOnly attribute to the application element of the
corresponding AndroidManifest file and set its value to true.
If the testOnly attribute is already present and has value
false, then do nothing.
Tests added in manifest_fixer_test.py to check if the updated
AndroidManifest file has the testOnly attribute set to true or not.
Bug: 213310150
Test: atest --host manifest_fixer_test
Test: m nothing
Test: manually checked the AndroidManifest file generated
Change-Id: I36247dbe0261c342d451a4422c314fd8fe0c2369
mk2rbc was already searching the whole android tree
for Makefiles, so allowing variable-prefixed include
statements doesn't affect performance on the file searching
front. On the generated code front, there's already a cap
of 150 potentially-included makefiles that prevents the
performance from getting too bad, and it can be lowered
if necessary.
Bug: 213508006
Test: go test
Change-Id: I3a4e81acb3d97bee08ac3dbe63052a274acf5793
