See build/soong/README.md for more information.
Note: tests/ImfTest/Android.mk causes conflict as it hasn't been yet
ported to internal master. Do it later.
Note: the conversion in the following directories has to be done in the
internal master first because of the conflicts:
* tests/ActivityManagerPerfTests
* tests/AppLaunch
* tests/AppLaunchWear
* tests/BackgroundDexOptServiceIntegrationTests
* tests/Camera2Tests/CameraToo
* tests/Camera2Tests/SmartCamera/SimpleCamera
* tests/Compatibility
* tests/Internal
* tests/RcsTests
* tests/ServiceCrashTest
* tests/UsbTests
Bug: 122332340
Test: treehugger
Change-Id: Ie17590c6a96aee5caa80d38092a3de5c1b6efe8d
This change sets LOCAL_SDK_VERSION for all packages where
this is possible without breaking the build, and
LOCAL_PRIVATE_PLATFORM_APIS := true otherwise.
Setting one of these two will be made required soon, and this
is a change in preparation for that. Not setting LOCAL_SDK_VERSION
makes the app implicitly depend on the bootclasspath, which is
often not required. This change effectively makes depending on
private apis opt-in rather than opt-out.
Test: make relevant packages
Bug: 73535841
Change-Id: Ibcffec873a693d1c792ca210fb597d2bf37e9068
Merged-In: I4233b9091d9066c4fa69f3d24aaf367ea500f760
The dynamic ref table used to map build-time IDs to runtime IDs
is mainly used for shared resource libraries and has a few built-in
mappings (app 0x7f and framework 0x01).
Using a non-standard package ID like 0x80 causes a failure in package ID
lookup. The solution is to ship the dynamic_ref_table with an identity mapping
with any resource table that uses a non-standard package ID.
Adds some tests to ensure this works correctly.
Bug: 37498913
Test: make libandroidfw_tests
Test: make aapt2_tests
Change-Id: Ic3f67942384d34e7fdcbc94ded360e940e3ebc8a
This change allows the developer to add a base package for
which to build a feature split. The generated resource types
will begin after the base APK's defined types so as not
to collide or override resources.
Multiple features can be generated by first choosing an
arbitrary order for the features. Then for each feature,
the base APK and any preceding features are specified
with the --feature-of flags.
So with a base APK 'A' and features, 'B', and 'C',
'B' would be built with
aapt package [...] --feature-of A [...]
and 'C' would be built with
aapt package [...] --feature-of A --feature-of B [...]
Change-Id: I1be66e3f8df9a737b21c71f8a93685376c7e6780
