Starting with the version 28.0.3 of the Android SDK build tools,
the internal ids of the items of an array bag seems to have changed.
Because of those changes, array resources were no longer decoded correctly.
They were decoded as style resources.
Instead of using the id of the first item within a resource bag,
the name of the res type spec is now used to choose the correct
resource bag value to create.
Note: a list of "legal names" for resource types can be found in the source code of aapt2.
Some APKs' arsc has additional payload data (like TYPE 8 chunks and/or padding) in the TYPE chunk. After the ARSCDecoder read such kind of chunk, it acts erratically. Most of the time, it just stops parsing the ARSC, therefore, some resources are not decoded because they are not in the apktool's resources' spec table.
This replaces the custom LittleEndianDataInputStream with
guava's implementation. To do this, I had to fix ExtDataInput
to better handle the case where skipBytes doesn't skip all the
bytes (the tests failed without this, and succeed with it). This
appears to be the main difference between the two implementations.
Guava's implementation is preferred because it is already a
dependency and because its license is clearer (the previous
implementation had a vague "public domain" comment in the thread
which may not be legally sufficient).
Fixes#1166
* Drop LEDataInputStream (which had a restrictive license)
with LittleEndianDataInputStream, which is public domain.
A minor change has been made to the new class, removing
the interitance of InputStream.
This makes it's behaviour indentical to the previous implementation,
and unit tests pass.
Fixes#1166
Source: http://www.peterfranza.com/2008/09/26/little-endian-input-stream/
Reduces the time it takes to parse the Android framework by ~50%.
The synthesized name now has no leading zeroes, but this doesn't appear to matter since the numeric part of the name isn't used anywhere.
Prior to this change, APKs usually went Package -> TypeSpec -> Config (all) -> Entries.
Reading all configs under that TypeSpec. Now we have packages that go
Package -> TypeSpec -> Config (single) -> Entries.
So we have to read this correctly to make sure we can correctly decode sparse and packed
Resource tables.
- Moves Config --> Type
- Moves Type -> TypeSpec
- ResType -> ResTypeSpec
- ResConfig -> ResType
This is to match AOSP and ease the transitions/updates of new AOSP drops
- Frameworks between froyo and honeycomb have mnc001, etc
- A size check of ResConfig header for less than 32 (honeycomb) uses old decode method
- Greater than 32 bytes moves to new decode method of mnc# vs mnc###