Apktool
                                
                                
                                
                                    Apktool copied to clipboard
                            
                            
                            
                        [BUG]Unable to install Android 12 L Beta 2 framework-res.apk
Information
- Apktool Version (
apktool -version) - 2.4.1 or 2.6.0, I guess it doesn't matter... - Operating System (Mac, Linux, Windows) - Windows (using Power Shell)
 - APK From? (Playstore, ROM, Other) - redfin Android 12 L Beta 2 official firmware
 
Stacktrace/Logcat
Exception in thread "main" brut.androlib.AndrolibException: Invalid chunk type: expected=0x00000200, got=0x00000206 at brut.androlib.res.decoder.ARSCDecoder.checkChunkType(ARSCDecoder.java:542) at brut.androlib.res.decoder.ARSCDecoder.readTablePackage(ARSCDecoder.java:88) at brut.androlib.res.decoder.ARSCDecoder.readTableHeader(ARSCDecoder.java:82) at brut.androlib.res.decoder.ARSCDecoder.decode(ARSCDecoder.java:48) at brut.androlib.res.decoder.ARSCDecoder.decode(ARSCDecoder.java:40) at brut.androlib.res.AndrolibResources.installFramework(AndrolibResources.java:872) at brut.androlib.res.AndrolibResources.installFramework(AndrolibResources.java:854) at brut.androlib.Androlib.installFramework(Androlib.java:707) at brut.apktool.Main.cmdInstallFramework(Main.java:269) at brut.apktool.Main.main(Main.java:82)
Steps to Reproduce
- 'java -jar .\apktool_2.6.0.jar if .\framework-res.apk'
 
Questions to ask before submission
- Have you tried 
apktool d,apktool bwithout changing anything? N/A - If you are trying to install a modified apk, did you resign it? N/A
 - Are you using the latest apktool version? Yes.
 
If we try and install framework-res.apk from Android 12, we can't decompile framework-res.apk from Android 12 L Beta 2 as well.
We get the same "Invalid chunk type: expected=0x00000200, got=0x00000206" while trying to decompile.
Its possible this is related to https://github.com/iBotPeaches/Apktool/issues/2714, but I would like a sample application or link to where I can pull Android 12 L, I'm not seeing that nomenclature when I try and pull platforms from SDK Manager.
Nevermind - not needed. I updated to latest API 31 and I now replicate issue. Put up a broken PR in meantime - https://github.com/iBotPeaches/Apktool/pull/2743
The same issue is now occurring on March Android 12 build. Just thought on letting you know.
Thanks - I started looking at it this weekend as these applications are increasing in quantity.
Need to add support for <staging-public-group-final> which will really only be in AOSP apps as they build against future SDKs, but can easily reassign resources once API stabilizes.
- https://github.com/aosp-mirror/platform_frameworks_base/commit/2fedba9a32d9e92344eaf6e9faf5b43e1bc2ae70
 
          <public type="attr" name="finalized_res" id="0x01010001"/>
         <public type="attr" name="staged_s_res" id="0x01010002"/>
         <public type="attr" name="staged_s2_res" id="0x01010003"/>
         <public type="string" name="staged_s_string" id="0x01020000"/>
         <!-- S staged attributes (support staged resources in the same type id) -->
         <staging-public-group-final type="attr" first-id="0x01010050">
           <public name="staged_s_res" />
         </staging-public-group-final>
         <staging-public-group-final type="string" first-id="0x01fd0080">
           <public name="staged_s_string" />
         </staging-public-group-final>
         <!-- SV2 staged attributes (support staged resources in a separate type id) -->
         <staging-public-group-final type="attr" first-id="0x01ff0049">
           <public name="staged_s2_res" />
         </staging-public-group-final>
         <!-- T staged attributes (support staged resources in multiple separate type ids) -->
         <staging-public-group type="attr" first-id="0x01fe0063">
           <public name="staged_t_res" />
         </staging-public-group>
We also have 2 new types for overlay and policy.
- https://github.com/aosp-mirror/platform_frameworks_base/commit/75e20dda2b1ef3d2593b02f6a366a02656c1c89d
 
<overlayable>
   <!-- Any overlay on the product_services, vendor, or product partition can overlay the value of
  @string/overlayable3 -->
   <policy type="product_services|vendor|product">
       <item type="string" name="overlayable3" />
   </policy>
</overlayable>
So working on issue-2740 branch and just going to skip all data to get disassembling working again, then slowly add support for the types.
Taking this AndroidL / API32 a bit differently than other upgrades. We have many things to do
- Support the new ASRC changes (roughly done)
 - Adopt those ASRC changes into viable format to re-use/re-parse during compilation
 - Update aapt2 sources for new support
 
If we look at that list, the first one is done, but in pure skip mode. You can tell from this output
➜  2774 apktool d framework-res.apk -f
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true
I: Using Apktool 2.6.2-df3b9f-SNAPSHOT on framework-res.apk
I: Loading resource table...
I: Skipping staged alias stagedId (1fe0000) finalId: 1020055
I: Skipping staged alias stagedId (1fe0001) finalId: 1020056
I: Skipping staged alias stagedId (1fe0002) finalId: 1020057
I: Skipping staged alias stagedId (1ff0000) finalId: 101064c
W: Skipping package group: android
I: Decoding AndroidManifest.xml with resources...
I: Regular manifest package...
I: Decoding file-resources...
I: Decoding values */* XMLs...
I: Copying assets and libs...
I: Copying unknown files...
I: Copying original files...
➜  2774 
That we skip the data that was leading to the crash. The problem being is that information is used in aapt2 so it knows how to properly map assets during API development (ie releasing apps before API32 is finalized)
So I know that information has to be somewhere and right now we are just skipping it, effectively stopping the crash but sure as hell not making it work.
So I'm going to merge a PR shortly that refs this PR, but does not close it, then focus the aapt2 upgrade then loop back and find affected applications to see how we can boost test suite to properly account for staged aliases and overlays (if we find any)
I've merged updates to aapt2/aapt for these new properties. Still have:
- Adopt those ASRC changes into viable format to re-use/re-parse during compilation
 
Remaining
During the large refactors of 2.8.0/2.8.1 and some of the upcoming 2.8.2 changes - this has been fully resolved.
Closing.