ID types should not be encoded as a map. AAPT and AAPT2 emit
IDs as boolean types.
Some apps exist that for some reason have their ID types encoded
as empty maps. This is the case only for the auto generated IDs
from enum values in <attr> tags.
Allow IDs as maps and ignore their content when processing an APK
for optimizing.
Also fixes an issue with expected size of the ResTable_package struct.
Bug: 35861796
Test: tested against the APK in b/35861796
Change-Id: I29a19cd9777bb10bed6766cd42e35e50e098797b
This reverts commit 2dc804be11444565e3d1d151c2a693db3ade94c0.
It also removes the related calls from UiModeManager.
Fixes: 32721178
Test: make & flash
Change-Id: Id371bccec611155cc6910e46b3277c3d27fc1c79
An overlay was incorrectly leaking its own resources into the
framework resource package, which caused warnings for every app
that tried to access framework resources (all of them).
This change skips including any resources that are not overlaying
anything (not present in IDMAP).
Bug: 36256974
Test: make libandroidfw_tests
Change-Id: I8c710af6849bb848938825aacca02799ee96c003
In order to allow multiple packages with the same package name, but
different package ID, we need to keep searching packages until the
resource is found.
Bug: 30999713
Test: make libandroidfw_tests
Change-Id: If4540e12731ca18a18e9e550a9bf248606a586c5
ResTable_type's size changes due to it containing
ResTable_config. Make sure we check for the minimum size
required to read it.
Bug: 35861796
Test: Manual (don't have an integration test harness setup yet)
Change-Id: Ifb0cd1d732625f59835c8ed0449adb78129636de
Hand over ownership of overlays to OverlayManagerService.
Changes to a package's overlays are propagated using the activity life
cycle. Affected activities will be recreated as needed. This provides a
well-defined point to modify an application's assets while the
application is paused.
Consolidate how overlays targeting the system and overlays targeting
regular applications are handled. Previously, system overlays were
handled as a special case. Now, everything is handled identically. As a
side effect, the call to idmap --scan during Zygote boot has become
obsolete and is removed.
Information on what overlays to use is recorded in
ApplicationInfo.resourceDirs. The PackageManagerService is responsible
for the creation of ApplicationInfo objects. The OverlayManagerService
is responsible for informing the PackageManagerService in advance about
what resourceDirs to use.
When launching an application, the ApplicationInfo is already populated
with up-to-date information about overlays.
When enabling or disabling an overlay for a running application, the
OverlayManagerService first notifies the PackageManagerService about the
updated resourceDirs. It then tells the ActivityManagerService to push
the new ApplicationInfo object to the application's ActivityThread.
Finally the application requests its ResourcesManager to create new
ResourcesImpl objects based on the updated paths.
Change-Id: Ib8afa05ccab4e2db558f89ce4423983c086bb61a
Co-authored-by: Martin Wallgren <martin.wallgren@sonymobile.com>
Signed-off-by: Zoran Jovanovic <zoran.jovanovic@sonymobile.com>
Bug: 31052947
Test: run tests from 'OMS: tests for OverlayManagerService'
Hand over ownership of overlays to OverlayManagerService.
Changes to a package's overlays are propagated using the activity life
cycle. Affected activities will be recreated as needed. This provides a
well-defined point to modify an application's assets while the
application is paused.
Consolidate how overlays targeting the system and overlays targeting
regular applications are handled. Previously, system overlays were
handled as a special case. Now, everything is handled identically. As a
side effect, the call to idmap --scan during Zygote boot has become
obsolete and is removed.
Information on what overlays to use is recorded in
ApplicationInfo.resourceDirs. The PackageManagerService is responsible
for the creation of ApplicationInfo objects. The OverlayManagerService
is responsible for informing the PackageManagerService in advance about
what resourceDirs to use.
When launching an application, the ApplicationInfo is already populated
with up-to-date information about overlays.
When enabling or disabling an overlay for a running application, the
OverlayManagerService first notifies the PackageManagerService about the
updated resourceDirs. It then tells the ActivityManagerService to push
the new ApplicationInfo object to the application's ActivityThread.
Finally the application requests its ResourcesManager to create new
ResourcesImpl objects based on the updated paths.
Co-authored-by: Martin Wallgren <martin.wallgren@sonymobile.com>
Signed-off-by: Zoran Jovanovic <zoran.jovanovic@sonymobile.com>
Bug: 31052947
Test: run tests from 'OMS: tests for OverlayManagerService'
Change-Id: Idc96dae6fc075d5373aa055bbf50e919136d7353
Check whether specified offset belongs to mData.
Also added a default argument bufferSize to check the end offset.
Size of the ashmem descriptor can be modified between
ashmem_get_size_region call and mmap. createFromParcel method was updated
to check ashmem size again immediately after memory is mapped.
Test: manual - using the test app from the bug
Bug: 34128677
Change-Id: I3ecd1616a870ce20941ce9b20a1843d2b4295750
Benchmarks on bullhead-userdebug show that there is a negligent
performance impact when using sparse entries on a 30% loaded
sparse type of 1000 resources.
Benchmark Time CPU Iterations
-----------------------------------------------------------------------------------
BM_SparseEntryGetResourceSparseLarge 255 ns 254 ns 2751408
BM_SparseEntryGetResourceNotSparseLarge 254 ns 254 ns 2756534
Bug: 27381711
Test: make libandroidfw_tests aapt2_tests
Change-Id: I051ea22f2f6b2bc3696e446adc9e2a34be18009f
- Use FileMaps to open Assets (prevents closing of ApkAssets underlying
zip)
- Implement OpenDir and List methods
- Fix issue where DynamicRefTable wasn't properly constructed
Test: make libandroidfw_tests
Change-Id: Ib21a84e1114d028120744aa3bc1c6eb9d9399fa8
The XLIFF 'g' tag specifies content that should NOT be translated.
AAPT2's pseudolocalization process should respect it.
Bug:34064599
Test: make libandroidfw_tests
Change-Id: Ice437d7f0ff246730ee04896fd035e2d846148fb
Plug a memory leak in AssetManager::createIdmap.
Bug: 31052947
Test: use Valgrind and dummy native app
Change-Id: I83af3a40516ed2d50d5a7c8ee175ed960fde9933
The color mode lets an application request a wide color gamut for
a specific window. This will also be used in the future to request
HDR. The color mode is currently either default (sRGB) or an undefined
wide gamut color space chosen by the platform. These attributes could
later be used to choose a specific color space if we deem this important
or useful.
This change also renames the various "colorimetry" attributes and
constants to "color mode" for consistency. These symbols were
added in O and can be safely renamed.
Test: CtsColorModeTestCases
Bug: 32984164
Change-Id: I4d4691dd12dbe3f3aa6a5cf893cff39aa16c739e
libandroidfw needs to make use of StringPiece, so
move it to libandroidfw and update all code referencing
StringPiece in aapt2.
Test: make libandroidfw_tests libaapt2_tests
Change-Id: I68d7f0fc7c651b048d9d1f5e7971f10ef5349fa1
Also add back script information for Yiddish old code (ji) that was
removed in ICU.
Bug: 26756576
Test: none
Change-Id: Ia785f86bf0407aeed6134ef9d44e504494256da2
Due to legacy reasons, Android translations of European Spanish were
kept under 'es', while Latin American Spanish translations were kept
under 'es-US'. The combination of this, and the new locale
preference rules in Nougat, resulted in 'es' winning over 'es-US' for
all Latin American locales, since 'es' was a direct ancestor, while
'es-US' was just a fallback.
The changes in Nougat had assumed that app developers would put Latin
American Spanish translations under 'es-419', but that could create a
backward-compatibility problem under older Android versions that did
not support three-digit region codes properly.
This CL keeps the Nougat logic and its locale parent tree, but
special-cases es-US and es-MX to be treated as equivalents of es-419
in cases where they are present and es-419 is not.
Bug: 31545805
Bug: 34126460
Test: unit tests are included
Change-Id: Iab26f41294587ee044685a5a6560520c7cbb06f7
(cherry picked from commit a192a8ced65ceea8bfe44f0eac6a394cbf80d936)
This adds support for shared resource libraries in the new
ResTable/AssetManager implementation.
The dynamic package map encoded in resources.arsc is parsed
and stored with LoadedArsc, and combined to form a resolved table
in AssetManager2.
Benchmarks show that this implementation is an order of magnitude
faster on angler-userdebug (make libandroidfw_benchmarks).
Test: libandroidfw_tests
Change-Id: I57c80248728b63b162bf8269ac9495b53c3e7fa0
Due to legacy reasons, Android translations of European Spanish were
kept under 'es', while Latin American Spanish translations were kept
under 'es-US'. The combination of this, and the new locale
preference rules in Nougat, resulted in 'es' winning over 'es-US' for
all Latin American locales, since 'es' was a direct ancestor, while
'es-US' was just a fallback.
The changes in Nougat had assumed that app developers would put Latin
American Spanish translations under 'es-419', but that could create a
backward-compatibility problem under older Android versions that did
not support three-digit region codes properly.
This CL keeps the Nougat logic and its locale parent tree, but
special-cases es-US and es-MX to be treated as equivalents of es-419
in cases where they are present and es-419 is not.
Bug: 31545805
Bug: 34126460
Test: unit tests are included
Change-Id: Iab26f41294587ee044685a5a6560520c7cbb06f7
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
The out parameter `out_indices` is expected to be non-null
and so the extra null check adds a cost to performance
and opens the door to misusing the API by not supplying
`out_indices`.
Test: make libandroidfw_tests
Change-Id: Ie66fd837c5e24ec2838156e7b67f54c15cd27933
Changing any of the test APKs could change resource IDs.
The resource IDs are all made public and assigned an ID
to avoid this issue.
Test: make libandroidfw_tests
Change-Id: Idd17c25f4ac86a0ad5b2b8da6f968e5d9b2346c1
Tests would expect parts of the APK to be unzipped and
maintained. Instead, we now decompress the required files
from the test APKs on test setup. This simplifies
test maintenance substantially.
Test: make libandroidfw_tests && libandroidfw_tests --testdata=frameworks/base/libs/androidfw/tests/data
Change-Id: I3d2100af22df913e02401dedcf9842cdb32b2a3b
