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###
Previously in 4882396163f978884256e008fc7fae9201f156b4, strings that
resembled a filepath (ie res/foo/file), would be assigned to a
ResFileValue, which when attempted to be casted to ResScalarValue would
error out.
Attempting to check the filesystem for such files, slowed apktool's
execution majorly. In order to prevent this, the ClassCastException
and other checks related to checking ResFileValue when type is string
was added.
This allows bogus strings such as (res/foo/file) to be added, but the
exception is caught and allows decoding to continues. Fixes#921.
Since all frameworks are decoded the same via readPackage(), reading
a framework that was a sharedLibrary would throw the sharedLibrary
flag for the apk. Since packageName isn't set until after the first
decode, we check the values to make sure we only set this variable on
the first apk decoded. Refs #936
layoutDirection was being read in error. layoutDirection is read
via bit shifting over screenLayout (byte 32, 33)
The then removed layoutDirection freed up 2 bytes. This gave us
12 bytes of unknown space from byte 36 to 48. This corresponded
to localeScript[4] and localeVariant[8]
Adding proper support for those bytes fixed BCP support
