Apktool: Implicit qualifiers removed during decode

Created on 3 Apr 2018  路  7Comments  路  Source: iBotPeaches/Apktool

Information

  1. Apktool 2.3.1 and 2.3.2 snapshot
  2. Linux
  3. SystemUI.apk and framework-res.apk from note 8 Oreo firmware

The resource folder layout changes from the original apk, for instance in the original SystemUI.apk there is an animator-v21 folder but the disappears when decompiled and files move to a simple animator folder.
```

Steps to Reproduce

  1. `apktool d SystemUI.apk
  2. apktool b SystemUI -c
  3. Flash new apk, results in SystemUI crash

Frameworks

Bug

Most helpful comment

Are you positive the removal of version qualifiers is the cause of these crashes? Without the stacktrace of error, I don't know.

This probably cannot be resolved as this breaks way more applications when fixing. Nothing in the qualifiers say the "animator-v21" has an SDK version of 21. That value is actually completely null.

This means it was an implicit version added, which is the directory level, not qualifier. You can confirm this by running aapt d configurations SystemUI.apk. You won't see a single version qualifier. They are all implicit.

This means to properly determine implicit qualifiers, you have to look into the resources to determine if an attribute used is from a newer API. This requires hardcoded list of properties and the API version they were added at, which aapt1 and aapt2 do - https://github.com/aosp-mirror/platform_frameworks_base/blob/06169ed6b34b10fd49ab2633ac32e1eb095f22a1/tools/aapt2/SdkConstants.cpp#L73 not to mention the code able to read attributes at the resource level, which Apktool is far from being able to do. This even if added would slow down Apktool 100x, because we don't have a linked list C++ data struct, we'd need to crawl the XML with some pull-parser.

However, we disable that because of other bugs. Applications built before that version of aapt where implicit SDK version was done, will now be implicitly versioned. That breaks things.

We cannot win this battle.

  • We enable implicit SDK versioning, and applications break that don't have SDK versions that can't handle resources/etc moving under version qualifiers.
  • We disable implicit SDK versioning and this report suggests applications break, because the application was coded to locate resources with the version qualifier.

Unrelated to all this, this ticket is now a hard-block before weekend release. I introduced a regression when building an application. I record the resource directory name for assets and not the qualifier produced directory name, which as explained above might be drawable-v21 vs drawable. This will produce a hard failure.

I: Copying unknown files/dir...
java.io.FileNotFoundException: SystemUI/res/drawable-ldrtl-xxhdpi-v4/ic_sysbar_back_carmode.webp (No such file or directory)

All 7 comments

Issues already know. Same thing for S8/S8+ on Oreo.

Great, thanks mate

Also there are some problems when decompiling system apps of Samsung Oreo ( missing correct layout folder name ) . @djdarkknight96 already reported .

Are you positive the removal of version qualifiers is the cause of these crashes? Without the stacktrace of error, I don't know.

This probably cannot be resolved as this breaks way more applications when fixing. Nothing in the qualifiers say the "animator-v21" has an SDK version of 21. That value is actually completely null.

This means it was an implicit version added, which is the directory level, not qualifier. You can confirm this by running aapt d configurations SystemUI.apk. You won't see a single version qualifier. They are all implicit.

This means to properly determine implicit qualifiers, you have to look into the resources to determine if an attribute used is from a newer API. This requires hardcoded list of properties and the API version they were added at, which aapt1 and aapt2 do - https://github.com/aosp-mirror/platform_frameworks_base/blob/06169ed6b34b10fd49ab2633ac32e1eb095f22a1/tools/aapt2/SdkConstants.cpp#L73 not to mention the code able to read attributes at the resource level, which Apktool is far from being able to do. This even if added would slow down Apktool 100x, because we don't have a linked list C++ data struct, we'd need to crawl the XML with some pull-parser.

However, we disable that because of other bugs. Applications built before that version of aapt where implicit SDK version was done, will now be implicitly versioned. That breaks things.

We cannot win this battle.

  • We enable implicit SDK versioning, and applications break that don't have SDK versions that can't handle resources/etc moving under version qualifiers.
  • We disable implicit SDK versioning and this report suggests applications break, because the application was coded to locate resources with the version qualifier.

Unrelated to all this, this ticket is now a hard-block before weekend release. I introduced a regression when building an application. I record the resource directory name for assets and not the qualifier produced directory name, which as explained above might be drawable-v21 vs drawable. This will produce a hard failure.

I: Copying unknown files/dir...
java.io.FileNotFoundException: SystemUI/res/drawable-ldrtl-xxhdpi-v4/ic_sysbar_back_carmode.webp (No such file or directory)

In my case when modifying framework-res.apk from OP6, using either the original res/ (with version modifier) or the res/ (without version modifier) from apktool does not work (SystemUI crashed). What worked was combining both the old and new res/ (i.e. with and without version modifier).

Going to close this for roadmap - https://github.com/iBotPeaches/Apktool/blob/master/ROADMAP.md#implicit-qualifiers-cleanup

This is a much larger problem that requires more planning then this ticket.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

enovella picture enovella  路  3Comments

LeeDroid- picture LeeDroid-  路  3Comments

raulsiles picture raulsiles  路  4Comments

mildsunrise picture mildsunrise  路  3Comments

trandua picture trandua  路  3Comments