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.
When apktool creates a DexBuilder class, it creates it without specifying a minimum api level. This causes the DexBuilder class to assume api level 20 by default. This is not ideal since in some cases, the concrete minimum api level is required.
One such case is in smali's DexWriter class which implements a workaround for a bug in Dalvik that was fixed in Android 4.2 (https://code.google.com/p/android/issues/detail?id=35304) that causes apps that call the Method.getParameterAnnotations api to crash in some cases (see bug report for more details). The workaround that smali implements is only triggered if the minimum api level is below 17 (Android 4.2). But since apktool effectively sets the minimum api level to 20, this code is never triggered causing apktool to create apk files that crash on devices below Android 4.2.
This change passes the minimum api level to the smali library.
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
