* There are too many warnings from out/.../*.pb.h
and other generated header files.
Bug: 180862582
Bug: 231245501
Test: WITH_TIDY=1 make
Change-Id: Ibabc1040666b50c6dec4fd66ae999a3441324fbd
- Update apex_info (a topdown mutator) so that it sets updatable=true on
apps of updatable apexes
- Write a unit test that tests different combinations of
updatable/non-updatable apks-in-apexes
- Update an existing unit test that asserts a different error
Test: go test ./java
Test: m nothing (in internal)
Bug: 209409604
Change-Id: Ie8881b857afcec44addf27fc360c5b8abf726bd2
* This tidy check is too noisy,
with more than 5000 cases over many files.
Bug: 218759304
Test: make tidy_soong_subset
Change-Id: I8a4b2589ecafdfcd9c19e8a4d59ce1784d1be694
This reverts commit fbc5effdfd.
Bug: http://b/197965342
Bug: http://b/230930120
Test: m and also test internal targets
Change-Id: I49b2d80ef4191ebb08bb6e80507042ee628c7f09
Merged-In: I49b2d80ef4191ebb08bb6e80507042ee628c7f09
In make, the result of $(foreach $(x),$(y),$(foreach $(z),(w),a))
is a regular list, but in Starlark it's a list of lists. Flatten
the results of foreach expressions where each element is a list
so that they're regular lists of strings again.
Bug: 226974242
Test: go test
Change-Id: I3210d409aba0d807a5890e341ab1e0c0478f5930
These two databases are (nearly) identical but the latter is generated
in a much more efficient way.
The diffs are very minor and it's not clear to me which versions is more
correct than the other, though I'm fairly confident they don't matter.
https://paste.googleplex.com/5567994005553152
Bug: 187398174
Test: diff api-versions.xml
Change-Id: I0fa35d4067bc06936b4a31bda0bca7fd41f26aae
Metalava has two different flags surrounding api-levels:
- one for generating api-versions.xml to a file
- one for applying api-versions.xml from a file
Previously, soong always applied both of these arguments at the same
time, such that framework-doc-stubs both generated and applied
api-versions.xml.
Add support for using api-versions.xml from another module name as well.
Bug: 187398174
Test: droidstubs_test.go
Change-Id: I8288fe4788336d5d5c60d09d48b00ca111449fba
The framework-doc-stubs annotations.zip is no longer the correct
zip to use after b/187397779. It doesn't contain the module annotations.
Test: presubmit
Change-Id: I50e0bcc026c97886a31256e2387632c19d4b287f
Soong does not write AndroidMk output if the default outputfile is
invalid. The default output file for droidstubs modules is the srcjar,
but not all droidstubs modules have srcjars. Make it also write
AndroidMk entries for droidstubs that only have an api-versions.xml
output.
A similar exception already existed for the api txt files, so use the
same mechanism.
Bug: 187398174
Test: m nothing && grep Android-${TARGET_PRODUCT}.mk
Change-Id: I5cbcf42d877ca166d172b727c0aa2bdf6d9af744
With aosp/1640364, all variants of a cc_* module use min_sdk_version as
the version part of the clang triple. Therefore, checking
min_sdk_version of jni_libs should be sufficient to ensure that there is
no unintended access to symbols in newer Android versions
Test: go test ./java
Test: TH
Bug: 155209650
Bug: 209409604
Change-Id: I6c064f8a6ea12c8aa40165a9063380306a180c9b
Some build scripts need to know information about the contents of an
sdk, such as what APIs it provides (via java_sdk_library). Rather than
duplicate that information in the scripts or attempt to access that
information (where available) by looking at the contents of the
snapshot this change generates a JSON file that sits alongside the
snapshot itself.
The info file can be generated without generating the snapshot zip file
but whenever a snapshot zip file is generated the info is generated
too. The info file sits alongside the zip file in out/mainline-sdks.
Bug: 204763318
Test: m art-module-sdk
m dist
Change-Id: I289530bb21693dc6443826c24c17c9b5d85d2d8b
Too many warnings from this library.
Treat it the same as tidyExternalVendor projects.
Bug: 231626164
Test: make tidy-vendor-google_arc_subset
Change-Id: Ieaf748517390cb6dfac7e85500666dc9f49ffd52
Raw binaries are used in bare-metal environments such as early boot of
pVMs (protected virtual machines). Add a new target rule called
'raw_binary' which converts an executable to the raw binary format.
Test: m pvmfw
Change-Id: I701b703a0f12df891b714fe29e320914f167cd04
Add a linker_scripts property that is similar to version_script
but uses a -Wl,--script flag and can be passed multiple times.
Test: TestBinaryLinkerScripts
Change-Id: If405cfbcdaf8e99559414ba759734084fae0f7ec
Revert submission 2067907-apk-in-apex
Bug: 230873680
Reason for revert: Change broke aab generation b/230873680
Reverted Changes:
I9cef1418c:Append APEX version instead of build ID for APK-in...
Ic37eeba8b:Make apexer replace instances of version placehold...
Change-Id: Ib113d56901e815435f71bf878049cdabd210503c
Upgrading dagger uncovers an issue where java-only modules with
kotlin-containing dependencies may see org.jetbrains.annotations.NotNull
annotations. Include the kotlin-annotations in the output jar the
same way kotlin-stdlib is included.
Bug: 227669740
Test: TestKotlin
Change-Id: Ifc33a32b121c1b9a9d1911bdec332264b78b571c
This reverts commit 0b1c70efbc.
The reverted commit was based on the idea that uses-libraries that are
explicitly specified in build files should not be implicitly added to
the manifest, as that would mean that anything added to the build files
will flow to the manifest.
Although this logic is correct, it prevents propagation of
uses-libraries from dependencies, which is wrong: if a library has an
explicit uses-library property in Android.bp, this property is expected
to be propagated to the library's dependencies. Failing to do so would
mean that every user of that library has to add uses-library property to
their build files, which doesn't scale (see b/214255490 for example).
Bug: 214255490
Test: lunch aosp_cf_x86_64_phone-userdebug && m && launch_cvd \
&& adb wait-for-device && adb root \
&& adb logcat | grep -E 'ClassLoaderContext [a-z ]+ mismatch'
# empty output, no errors at boot
Change-Id: I6f420e76a89aa2f37be99f877711736640f2c361
