Android O Dev Preview Support #1453
Comments
|
and thus the first Android O report was made :) Yes, I know. |
|
Hope you will fix it soon bro ;) |
|
Also ApkTool cannot parse SettingsGoogle and SystemUI: |
|
Same here. |
|
Initial research shows that I won't be able to fix anything until official release. There is a new method of how text is stored (UTF8/UTF16) and the easiest way is to inspect commits to AOSP during release to patch the changes in. Configurations and qualifiers look the same at initial glance of the framework file provided, so its much more low level which requires AOSP code access or days upon days of black box work. |
|
Fixed few apktool exceptions(1, 2, 3). With this fixes apktool can install android O frameworks and decode android O apks(only known resources). Of course there will be a lot of warnings that unknown resources were skipped and such apks can't be compiled back(some resources will be missing), but i think that it's better than nothing. PS: Didn't create pull request cause i'm not sure that it's good idea pull this to master. |
|
Thanks! 1 scares me a bit, because I think the real fix for that is higher up the chain and that is simply catching the failure point. 2,3 look fine in my initial look but then again I don't think they will be a problem once 1 is properly fixed |
|
Hey Google release Android O DP 1 source: https://android.googlesource.com/platform/manifest/+/refs/heads/android-o-preview-1 |
|
aosp-mirror/platform_frameworks_base@76da37e - No longer need Need to dig more. Haven't found any changes to StringPool |
|
I saw last pull request.. So apktool now works with O? |
|
Negative, but progress. |
|
Btw I built and tested, nothing changed: |
|
The resource in question is Which reports the raw value as Apktool is failing on this due to an improper style decode. So not actually related to Android O at all. I'll get this solved soon. There aren't many tests written for this part of the codebase so I need to be careful patching this low level area. |
|
Umm, why is its value backwards? |
|
It was during the |
|
Okay, a WIP commit is up. I don't like the fix. Basically we have a UTF8 string, so our "length" count of it is 105, when in fact taking into consideration the true size of UTF8 chars we are looking at a size of 155 using Guava's ( I don't know how to manipulate a UTF8 string correctly, w/ sub strings etc. I need to do some research into the proper fix for this. There is my WIP and #1 of @Furniel above both do something similar to this. I might look into why Apktool thinks a style exists in this string, unless a hyperlink is the style. The message is
|
|
Next Problem. Never seen a letter used before for version. Apktool will fail trying to parse this as a number. |
|
You rock iBotPeaches! Not sure if this helps, but in past Developer Previews, letters have been used for min and target SDK versions and Apktool has never had a problem with it. Attached is the Monospace APK compiled against the Android N Developer Preview, which works fine in APKtool: Also in the zip is the Google Messages apk from the N preview, which is min 23, target n. It also works fine. |
Underwood still has the same trouble as the O apks I have. Easy to patch, strange that this is the first time I hit it. I downgraded to 2.2.1 which also had the problem. I probably should have clarified. The decode is working fine, its the rebuild that is currently broken with O dev preview, and I guess N preview. I'll have some patches out this weekend for this original issue and this new, but old Developer Preview bug. |
|
Okay, support for preview Next error. The first one is a fake problem. AOSP strictly states you cannot use Yet, it has one (in the official framework) Not sure why its doing that, when its own aapt binary would prevent it. That is Android for you, maybe system frameworks aren't bound by those rules. I guess since Apktool's job is to simply maintain the original apk, it should completely ignore reserved keywords. I'll need to patch all aapt binaries for this. Much like I did here for The next two problems are probably a bug in Apktool's decoder. The error is about mismatched tags and we can see from the string It indeed is missing the closing |
iBotPeaches
changed the title
|
Or maybe the missing tag is intentional? The ęń-řXÅ ļóçăĺè is for debugging anyway, maybe you shouldn't even try to parse tags that are in the value strings? |
|
Also, is there a reason why values/en-rXA is missing from O Preview framework sources? |
|
@Exalm I believe the debug strings are made on the build process stage with the aapt flag |
|
Ah, ok. |
|
I spent some time this morning looking at this. The failure in question has a style at index 1, ending at index 36 consisting of style This is 1 style, so no depth. So according to our rules, string Should start at the Then we hit our style attribute at index 1. So far so good, now this is where things mess up. Apktool currently knows the end tag is at index 36, but the string length is Now our position in the string is 36, so the string is complete without closing the tag. This is where things get interesting though. Like one of the original reports in this thread. This is an UTF8 encoded string, so the string length may be 36, but the byte count is 53 bytes. So perhaps the index is in relation to the byte index and not string index, this would mean that Which is valid, and looking at the English translation Is a perfect match. I need to revert this commit - f3536ef and introduce UTF8 safe string operations. Which means we need
Patching those two correctly should fix a lot more bugs than hacky if statements around these functions. |
|
Hey, iBotPeaches I have removed all XA / XB translations. |
|
@argraur The first line is the error I detailed in this response - #1453 (comment) In some situations, and I believe in this one, fixing that error will resolve the rest. You do bring up a good point though, rXB/rXA don't exist in the source application as they are generated at runtime via So to @Exalm, confirmation on that. I didn't remember the parameter, but thought I think thats only a band aid on the UTF8 String problem, but just another avenue to think about. I have some good progress on a new UTF8 String class that handles length calculation and sub strings, but it's still a bit buggy. I should have something soon. |
|
Okay, had a little time this morning. I've fixed the problem with AOSP using reserved keywords. Since apktool's job is to match the original application as much as possible, it shouldn't be responsible for enforcing keywords. If the original application uses them, it should as well. What that means on the host device among these different reserved keywords - I have no idea - iBotPeaches/platform_frameworks_base@c81b389 I need to build new platform binaries (unix 32/36, win, osx 32/64) still, but the patch for aapt is already committed. The problem above with psuedo locales is a bit more complicated than I thought. Originally I thought the start/end index was the byte position and not character position, but that makes no sense if you process it. Imagine a character that represents 2 bytes like Imagine two of those characters, that would mean 4 bytes or 2 characters. If the start index was 1 that makes absolutely 0 sense at the byte level because you are not splitting a character in half to insert the style. So it makes sense that the start/end index for styles are actually codepoint indexes. This makes sense, but still has the edge case with 2 issues.
I originally wanted to strip psuedo locales from decompiled application and restore them during build, but that still has the problem with 1 above. This needs a lot more research and perhaps rewriting of the style decoder so for now, bandaid fixes - 390ecae6c569228 |
|
Hmm @iBotPeaches, I think that we can forget about pseudo-locales for now and focus on other issues (with public.xml that I showed in my previous post) |
|
Like a record, more time this morning. Attached are a few commits that fix the reserved resource name and a proper fix for the psuedo locale problem. This led us to another error during rebuild. So I looked for the that first resource. Why is a style in the Doh. No idea, next thing to patch. For now, find/replace all style with array and I don't have an Android O supported device to actually test this yet, but it builds which is progress. |
|
Hey I have Nexus 5X, I can test that. PM me on Telegram |
- #1453 - temporarily cast unknown enum (0) to ResArray
|
With the commit above. This application can now be decoded and rebuilt with no work-around. I will confirm this functionality on both my Windows/Mac computers soon and if those pass with my recent We might have to re-explore when Android O really drops, but O Preview is working for this specific application. |
|
Add smali and baksmali v2.2.1 because that version introduce initial support for .vdex files. #1515 |
|
@iBotPeaches after framework-res.apk editing ( changing 2 bools from false to true ) device doesn't boot. |
|
I will need a device capable of running O to debug that further. The time it takes for me to get requested information and react upon it is simply too long when doing remote work over a problem. Decode only support will have to do for now. Closing this in favor for more specific new issues. |
|
What about emulator? |
Information
Stacktrace/Logcat
java -jar apktool_2.2.2.jar if framework-res.apk
The text was updated successfully, but these errors were encountered: