[BUG] Some Android 14 QPR2 APKs not supported #3428
Comments
|
The heap size error is unrelated. Apps are just getting bigger and Apktool does some things inefficiently, we bumped to 1g here 8477d99 The first error is real and odd. Confirmed. |
|
Ah I see, thanks. Updating the script fixed what I called the "second error", my bad. Will edit the original comment to only mention the real issue. |
|
Have some time this morning, not to really solve but to research. We crash on chunk 7, so lets dump aapt2 inspection of it. Best I can tell is this sample is reporting as the set of resources are offset16, but in fact are not. You can see this by expanding my search to the surrounding chunks. So as you can see the first chunk has flag 2 (offset16), as well as 2nd and 3rd. However, only the 1st and 3rd are actually packed. I've never seen this before - the chunk is lying on about its packing. |
|
I see Beta 1.1 came out - https://developer.android.com/about/versions/14/release-notes#beta1.1 Interesting to note the changelog item
This seems like malformed applications to me, but want to check the latest beta to confirm. |
I got curious too after seeing your message, and tried myself. Sadly, after trying to decompile various apps, including the same app provided in the original issue, the problem remains the same, and I got the exact same exception from apktool. |
|
Okay, I'll have to go slower and see if I misunderstood the spec for compact resources. |
Spent some time today. What I found is we are 2 bytes off prior to reading this Historically in Apktool, we've never relied on
|
Not really happy w/ this patch attached, because I'm convinced I'm missing some form of alignment/padding, but I've looked over this for a solid bit - https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/libs/androidfw/include/androidfw/ResourceTypes.h;l=1476;bpv=0 Don't see anything wrong. So I'll hold this draft PR until source is out for QPR2 for some final inspections. |
|
Mmh, the last time |
|
Yep, looking for changes to this even though there isn't really a possible location for anything to change. /**
* A collection of resource entries for a particular resource data
* type.
*
* If the flag FLAG_SPARSE is not set in `flags`, then this struct is
* followed by an array of uint32_t defining the resource
* values, corresponding to the array of type strings in the
* ResTable_package::typeStrings string block. Each of these hold an
* index from entriesStart; a value of NO_ENTRY means that entry is
* not defined.
*
* If the flag FLAG_SPARSE is set in `flags`, then this struct is followed
* by an array of ResTable_sparseTypeEntry defining only the entries that
* have values for this type. Each entry is sorted by their entry ID such
* that a binary search can be performed over the entries. The ID and offset
* are encoded in a uint32_t. See ResTabe_sparseTypeEntry.
*
* There may be multiple of these chunks for a particular resource type,
* supply different configuration variations for the resource values of
* that type.
*
* It would be nice to have an additional ordered index of entries, so
* we can do a binary search if trying to find a resource by string name.
*/
struct ResTable_type
{
struct ResChunk_header header;
enum {
NO_ENTRY = 0xFFFFFFFF
};
// The type identifier this chunk is holding. Type IDs start
// at 1 (corresponding to the value of the type bits in a
// resource identifier). 0 is invalid.
uint8_t id;
enum {
// If set, the entry is sparse, and encodes both the entry ID and offset into each entry,
// and a binary search is used to find the key. Only available on platforms >= O.
// Mark any types that use this with a v26 qualifier to prevent runtime issues on older
// platforms.
FLAG_SPARSE = 0x01,
// If set, the offsets to the entries are encoded in 16-bit, real_offset = offset * 4u
// An 16-bit offset of 0xffffu means a NO_ENTRY
FLAG_OFFSET16 = 0x02,
};
uint8_t flags;
// Must be 0.
uint16_t reserved;
// Number of uint32_t entry indices that follow.
uint32_t entryCount;
// Offset from header where ResTable_entry data starts.
uint32_t entriesStart;
// Configuration this collection of entries is designed for. This must always be last.
ResTable_config config;
};Since ResTable_config has to be last - its already supported for skipping unread bytes. So I think its just a natural missed feature that entriesStart is finally relevant. Normally you'd read data and land where entries were as a natural by-product of reading all, so the properties that labeled where data starts isn't relevant to Apktool. Though it appears now maybe that isn't the case, my guess being some alignment. |
|
I can confirm your PR does fix the issue. I built apktool based on your branch and used it to attempt to decompile various apks that previously failed. They were successfully decompiled. |
|
thanks. This was last issue prior to 2.9.1 so let me sleep on this if I go forward with skip patch or hold it. |
Uh oh!
There was an error while loading. Please reload this page.
It looks like Android 14 QPR2 (released yesterday) changed the way APKs are compiled. Apktool is unable to decode the
resources.arscfile.Information
apktool -version) - 2.9.0 / also tested with a manually built snapshot based on 4441648java --version) - java 17.0.8 2023-07-18 LTSStacktrace
First error:
Note
The value
0x00000002may be different depending on which APK is being decompiled. The APK causing this exact error is within the attached zip.Steps to Reproduce
apktool d example.apkFrameworks
The
framework-res.apkfile is attached in the zip file.APK
An
example.apkfile is attached in the zip file.Attachments:
qpr2_bug.zip
The text was updated successfully, but these errors were encountered: