Regenerated sparse.apk with latest aapt2 and updated resource qualifier
to orientation from sdk version because config sdk version was fully
dropped in aapt2. Also added tests with runtime apk generated by Soong
build target to make these tests more comprehensive. Applied
parameterized test to avoid duplicate code.
Bug: b/249370927
Test: Added and verified affected atests pass
Change-Id: I94f6758d7862375fe4053f42fe89953d4afa48fd
This reverts commit 63e5d41be7.
Reason for revert: b/253420843
This CL causes memory regression as described in above bug. To speed
up the lookup from resource string to resource ID, the original CL
introduced std::unordered_map for the purpose, unfortunately, that
adds much memory footprint due to the number of key strings per
process. We will need to revisit the solution with a more memory
efficient approach.
Change-Id: I9c6754d361f091e963d4bebea0e698e72e221e51
Some apps keep adding the same resources to their theme key
objects on e.g. switching dark mode. Need to be prepared to
limit the size of the arrays, otherwise theme switching gets
slower with each toggle
+ a bit more efficient native handling
Bug: 242005877
Test: manual, 10k of theme switches with no noticable slowdown
Change-Id: Icf74770bd41ebeb0a31f527ae3616de00f23b0ae
Bug: 249320624
There number of calls to ResStringPool::indexOfString() is very high
due to many calls to Resources.getIdentifier() in JAVA code. This is
used to get the resource ID (a 32-bit integer) by its resource name
(a string).
One example pprof trace is at:
https://pprof.corp.google.com/?id=9b9b377bf52bdeb972c6ad154acf3902
This happens to the key string pool in a package, which is normally
encoded in UTF-8, unsorted. The call to indexOfString() ends up going
through the whole key string pool and do a per string comparison til
the string is found.
For some large applications, the key string pool could have > 10k+
strings, which results in an excessive calling to string8At() or
stringAt(). Although these calls are pretty quick, the excessive
callings are not necessary and inefficient.
There are a few ways to improve this:
1. sort the key strings so the current implementation ends up doing
a binary search. However, for some reason, there is no code in aapt
or aapt2 to support sorting and use the SORTED_FLAG.
2. or when needed, setup a std::map<StringPiece, size_t> to map the
key string to its ID, and use the map for all subsequent calls to
indexOfString()
Here we chose the 2nd way with a few justifications:
1. std::map<> has a stable O(logN) lookup performance, and a key
comparison doesn't involve comparing the whole key so it's both
fast and relative stable.
2. by using StringPiece, we are not allocating memory if the string
mapped doesn't need decoding, and StringPiece supports comparison.
This CL reduces the number of calls into string8At() or stringAt()
to the key string pool from 2m+ down to ~400k.
See example pprof trace at:
https://pprof.corp.google.com/?id=cb677fca932260b2dc7db64ee37c4b61
Change-Id: I77a0ef13daac6d8a5c63a681c52f8ab9712578ed
`buf` isn't freed here. Convert it to either a unique_ptr or stack
array, depending on size.
Caught by the static analyzer:
> frameworks/base/libs/androidfw/tests/CursorWindow_test.cpp:190:5:
warning: Potential leak of memory pointed to by 'buf'
[clang-analyzer-unix.Malloc]
> frameworks/base/libs/androidfw/tests/CursorWindow_test.cpp:268:5:
warning: Potential leak of memory pointed to by 'buf'
[clang-analyzer-unix.Malloc]
> frameworks/base/libs/androidfw/tests/CursorWindow_test.cpp:327:5:
warning: Potential leak of memory pointed to by 'buf'
[clang-analyzer-unix.Malloc]
Bug: 206470603
Test: TreeHugger
Change-Id: I6fee4a9c2eedce0385f794567b0083df24c63419
Bug: 246953799
Collect timing information for resource acquisition methods. The
timing has nanosecond resolution and is collected inside the native
runtime code. Timing values are accumulated in the runtime and are
periodically fetched and published by the java framework. This
strategy means that normal resource methods incur a small runtime
overhead. The longer time involved in publishing the values is
handled by an independent Java thread.
A public dumpTimers() method can be called from a dumpsys command, for
debug, but the dumpsys command is not hooked up in this commit.
No APIs are actually monitored in this commit, and the ResourceTimer
loop is not started.
Test: atest
* androidfw_lib
Change-Id: I5995d3c6518ca2fa4c8ab9d3eb610167758c695d
This also includes the change to use the configs to decide which (if
any) frros to use at runtime
Bug: 243066074
Test: Manual, updated and created automated tests
Change-Id: I3f1d23e2958ad170799880b9f5eb5bd8ceb1fa67
When collapsing our heap-and-stack boundaries, we round up to ensure
our padding math is still aligned on the remote side. This rounding
can leak a small amount of uninitialized memory, so this change
force-initializes any potential padding area.
Bug: 213170822
Test: atest libandroidfw_tests
Change-Id: Ife6fcd1b74aaabd932a77ea42e0d0ad3a6b9cae6
This is a defensive change. The current code is safe due to the
resize() which happens 30 lines above this one. However, if that
resize() were to change or disappear, then this code would be
dangerous, as the resize() could potentially cause a reallocation,
and move our memory buffer.
Since it's no additional cost to grab the pointer into the
array after the resize(), we do that.
Bug: 232940948
Test: TreeHugger
Change-Id: I29b6cbeb064c7654eb21d2e42e05a0587604c32b
For convenience, builds against musl libc currently use the
linux_glibc properties because they are almost always linux-specific
and not glibc-specific. In preparation for removing this hack,
tweak the linux_glibc properties by either moving them to host_linux,
which will apply to linux_glibc, linux_musl and linux_bionic, or
by setting appropriate musl or linux_musl properties. Properties
that must not be repeated while musl uses linux_musl and also still
uses the linux_glibc properties are moved to glibc properties, which
don't apply to musl. Whether these stay as glibc properties or get
moved back to linux_glibc later once the musl hack is removed is TBD.
Bug: 223257095
Test: m checkbuild
Test: m USE_HOST_MUSL=true host-native
Change-Id: I7058c8f1dadd7bbfd7e169bdf0a0441eb6d10ec5
Need to have the same kind of data size check as in other
types parsing
Bug: 203938029
Test: manual
Change-Id: I9f5d2851ff59da90163ead6c0416f0bba3868cc4
Merged-In: I9f5d2851ff59da90163ead6c0416f0bba3868cc4
(cherry picked from commit 8002034e6b)
(cherry picked from commit abdf5a518d)
Merged-In:I9f5d2851ff59da90163ead6c0416f0bba3868cc4
It isn't enough to only dump the theme id and name because there is
no whole theme inheritance map. Developers need the map to figure out
why the attribute value is so strange.
A theme is a kind of style. This patch creates an API to retrieve the
parent id for any style. And, it dumps the whole inheritance between
themes until it can't find the parent style.
Test: manual test described in b/209708201#comment5
Bug: 209708201
Change-Id: I9de0e6e9aaeff7cb9fc89dc9b8a04925e84f975c
The native code that underlies `Resources#getIdentifier()` did not take
sparse encoding into account when calculating offsets, resulting in
either garbage or SEGV_MAPERR whenever a resource is first encountered
in a sparsely encoded configuration.
Bug: 197976367
Test: atest libandroidfw_tests --host
Change-Id: Ib7550fe2e05005550f59129a06be5712b74bc9c8
(cherry picked from commit 984e897303)
Need to have the same kind of data size check as in other
types parsing
Bug: 203938029
Test: manual
Change-Id: I9f5d2851ff59da90163ead6c0416f0bba3868cc4
Merged-In: I9f5d2851ff59da90163ead6c0416f0bba3868cc4
(cherry picked from commit 8002034e6b)
Need to have the same kind of data size check as in other
types parsing
Bug: 203938029
Test: manual
Change-Id: I9f5d2851ff59da90163ead6c0416f0bba3868cc4
Merged-In: I9f5d2851ff59da90163ead6c0416f0bba3868cc4
(cherry picked from commit 8002034e6b)
