yashsingh1/xdaforums huggingface dataset:
[Android Software Development] zelendel:
There is your issue. It was stated awhile ago that apktool will not support the Oppo due to them using a bunch of non standard stuff.

Yeah, you'd need to build a new aapt with those new qualifiers. I'll do some cleanup work on my aapt repo, and try and remove all the current "slim" changes it has, so I can branch these into a new one and get one built. Since AOKP is larger than some of these smaller ROMs, I'd venture to say their method and execution should now be the default / go to for this change. Hopefully other ROMs (who use this), will follow that commit so they can all be on the same page. Otherwise we will have tons of APKs with random bytes of new data, which Apktool won't be able to handle.

I can't wait to start getting random bug reports about duplicate resources :/

OPPO did exactly this ^, except their qualifier had nothing to do with inversion. It was just called "oppo" and hooked into special OPPO folders. That is why I won't directly add support for OPPO ROMs into Apktool. There change just would cause problems on new AOSP versions.

MIUI on the other hand, only adds 3 resources into an existing qualifier. They also pad the number by like 20, so even if 10 years of AOSP versions passed, it still wouldn't conflict with their version (Unless AOSP happens to add the same names as MIUI).

What does this mean for you?

It'll no longer be part of the "official" Apktool I put out on Google Code, etc. You'll just have to find a special build, that I'll release here. Since aapt is bundled inside Apktool, you won't have to worry about maintaining a copy of "patched" aapt and apktool. Since they'll be bundled together.
[Android Software Development] texture:
Thank you for the explanation.
[Android Software Development] sikodemon:
Is there a version for Huawei devices?

Can anyone please tell me is there is a modified version of Apktool for Huawei's different frameworks? All I get (along with everyone else using a Huawei Y300 or G510) are these errors:

C:\Users\BUCKER\Desktop\Apktool JB 4.2.2_Signed_By Rizal Lovins Sundanesse>apkto

ol if framework-res.apk

W: Config flags size > 36. Exceeding bytes: 0x2400.

W: Invalid config flags detected: string-ERR0

W: Config flags size > 36. Exceeding bytes: 0x9C00.

W: Invalid config flags detected: string-ERR1

W: Config flags size > 36. Exceeding bytes: 0x2A02.

W: Invalid config flags detected: string-ERR2

W: Config flags size > 36. Exceeding bytes: 0x11009C00.

W: Invalid config flags detected: string-ERR3

W: Config flags size > 36. Exceeding bytes: 0x2D00DE00.

W: Invalid config flags detected: string-ERR4

W: Config flags size > 36. Exceeding bytes: 0x2D005401.

W: Invalid config flags detected: string-ERR5

W: Config flags size > 36. Exceeding bytes: 0x5C009C00.

W: Invalid config flags detected: string-ERR6

W: Config flags size > 36. Exceeding bytes: 0xC3012400.

W: Invalid config flags detected: string-ERR7

W: Config flags size > 36. Exceeding bytes: 0xE7039C00.

W: Invalid config flags detected: string-ERR8

W: Config flags size > 36. Exceeding bytes: 0x1A008801.

W: Invalid config flags detected: string-ja-ERR9

W: Config flags size > 36. Exceeding bytes: 0x8000000.

W: Invalid config flags detected: string-es-ERR10

W: Config flags size > 36. Exceeding bytes: 0x5600D402.

W: Invalid config flags detected: string-es-ERR11

W: Config flags size > 36. Exceeding bytes: 0x44017C01.

W: Invalid config flags detected: string-it-ERR12

W: Config flags size > 36. Exceeding bytes: 0xA008302.

W: Invalid config flags detected: string-ru-ERR13

W: Config flags size > 36. Exceeding bytes: 0x98007000.

W: Invalid config flags detected: string-ru-ERR14

W: Config flags size > 36. Exceeding bytes: 0x2000000.

W: Invalid config flags detected: string-en-rGB-ERR15

W: Config flags size > 36. Exceeding bytes: 0x2000000.

W: Invalid config flags detected: string-es-rVE-ERR16

W: Config flags size > 36. Exceeding bytes: 0x8000000.

W: Invalid config flags detected: string-es-rVE-ERR17

W: Config flags size > 36. Exceeding bytes: 0x9C00.

W: Invalid config flags detected: string-zh-rHK-ERR18

W: Config flags size > 36. Exceeding bytes: 0x11009C00.

W: Invalid config flags detected: string-zh-rHK-ERR19

W: Config flags size > 36. Exceeding bytes: 0x5C009C00.

W: Invalid config flags detected: string-zh-rHK-ERR20

W: Config flags size > 36. Exceeding bytes: 0xE7039C00.

W: Invalid config flags detected: string-zh-rHK-ERR21

W: Config flags size > 36. Exceeding bytes: 0x9C00.

etc.....
[Android Software Development] lafactorial:
I decompiled SystemUI.apk and edited strings.xml no problem but when it comes to recompiling here is the result :

D:\hakan>apktool b SystemUI
I: Checking whether sources has changed...
I: Smaling...
[0,0] No enum constant org.jf.dexlib.AnnotationVisibility.RUNT¦ME
Exception in thread "main" brut.androlib.AndrolibException: Could not smali file
: D:\hakan\SystemUI\smali\com\android\systemui\statusbar\AnimatedImageView.smali

at brut.androlib.src.DexFileBuilder.addSmaliFile(DexFileBuilder.java:45)

at brut.androlib.src.DexFileBuilder.addSmaliFile(DexFileBuilder.java:33)

at brut.androlib.src.SmaliBuilder.buildFile(SmaliBuilder.java:66)
at brut.androlib.src.SmaliBuilder.build(SmaliBuilder.java:50)
at brut.androlib.src.SmaliBuilder.build(SmaliBuilder.java:37)
at brut.androlib.Androlib.buildSourcesSmali(Androlib.java:257)
at brut.androlib.Androlib.buildSources(Androlib.java:214)
at brut.androlib.Androlib.build(Androlib.java:205)
at brut.androlib.Androlib.build(Androlib.java:176)
at brut.apktool.Main.cmdBuild(Main.java:228)
at brut.apktool.Main.main(Main.java:79)

D:\hakan>

When I delete AnimatedImageView.smali and after StatusBarIconView.smali I can recompile but why is that?Without these smalis I dont know the SystemUI.apk will work. Anyone got an idea about that???
[Android Software Development] sean.trinidade:
did you also install the framwork-res.apk?
[Android Software Development] iBotPeaches:
Don't mess with the source at all then. You can decompile with (-s / --no-src) which will retain the classes.dex intact without disassembling it to smali.

If you require the smali to do modifications, then you made a mistake editing. Smali naturally can go from disassembled -> assembled without problems. If there is a problem, it is usually intentionally malformed dex files.
[Android Software Development] iBotPeaches:
That APK isn't exceeding by a few bytes here and there. We are talking about a few hundred bytes. This APK looks very non-standard and probably cannot be handled. Can't confirm without an actual APK.
[Android Software Development] USMC retired:
Sense 5.0

resources, phone, and settings fail decompiling in sense 5.0, I'm actually using VTS and it has 1.5.2 is there a fix for this in the works? I have seen the post where you can handle resources using Java code, but I can't help but think some brilliant dev out there is working on this. :D

Ibot, you seem to have quite a few answers for people having compile or decompile issues, and you gotta be familiar with this, and advice? Any chance a new apktool coming out for sense 5.0?

Thanks
[Android Software Development] sikodemon:
I hate it when companies bring out good phones with bad software on them. Really spoils things when it comes to modding.

If it will help at all here are the "framework-res-hwext.apk", "framework-res.apk" and "SystemUI.apk" for the Y300.

Huawei Y300 ZIP

Hope it helps in some way. i know there are a lot of Huawei users scratching their head over this problem :(
[Android Software Development] plegdroid:
Afternoon Matey, have a read of posts 1279/1280 :)

ⓐⓝⓓⓡⓞⓒⓘⓓⓔ ⓘⓢ ⓝⓞⓣ ⓐ ⓢⓘⓝ
[Android Software Development] iBotPeaches:
Didn't even have to have to open my IDE to figure this problem out :), though its not good. So :(

Take a look here: http://developer.android.com/guide/topics/resources/providing-resources.html, that lists active AOSP qualifers. Then look at that image. There is opta92 and other crap folder names. That means this company modified Android all the way down to the AssetManager to change how it handles resources. Why? The only reason I can think of, is to prevent stuff like this.

The current resources do everything without hacking needing. (With the exception of runtime inversion, which SlimROM has already added). Apktool doesn't know what those resources are and thus will fail. I'm sorry, won't support it. Unless you find a source code dump for frameworks/base (that Huawei did), I'm not reverse engineering this apk over Huawei.

In other news, the newest version of OPPO phones don't have the same crap the older ones did :)

So instead of bashing OPPO now, we can bash Huawei.
[Android Software Development] sikodemon:
Wow. All I wanted to do was make the status bar transparent by editing drawables.xml in the values folder.

Oh well. boring black status bar it is.
[Android Software Development] sean.trinidade:
If that's all you want to do, you dont need to decompile the apk. Just

1) open it in 7zip

2) find the image relating to the status bar backround,

3) extract it and edit it in GIMP (just make it transparent)

4) place it back into the same folder you extracted it from (again, via 7zip)

5) Push the updated file back to your phone

6) Restart

In fact, you can use the above for ANY image that you want to swap out, on any SystemUI.apk file. It's only if you want to edit any of the xml's etc. that you need to decompile.
[Android Software Development] zelendel:
This is not always the case. More and more they are using color codes instead of images.
[Android Software Development] cowsquad:
How do you guys deal with public.XML errors?
[Android Software Development] zelendel:
By fixing the error. What errors are you seeing?
[Android Software Development] cowsquad:
A bunch like public.XML Id doesn't match status_bar. Pretty much every row in public.XML gets print out as an error.

I just modified status_bar.XML.

I am on latest v5 miui ROM using the modified aapt provided by ibotpeaches
[Android Software Development] zelendel:
Remove the line that is erroring out. I wont touch MIUI so I am not sure how it is set up. But when I redirected my XMLs (yes there are many that need to be changed) to an image, I had to remove the line from the publics xml.
[Android Software Development] cowsquad:
Alright man thank you. I'll try your suggestion
[Android Software Development] sikodemon:
Yes you're right.

I think you'll find since JellyBean most of the System-UI background colors (status bar included) are hex codes in an xml file, and most of them are found in the packaged resources.arsc file which unfortunately 7-zip doesn't even know what the hell it is. :silly:

Gingerbread roms seem p*ss-easy to mod now compared to JB and ICS.

I think google are slowly making it more and more difficult for modders to get their kicks :(
[Android Software Development] zelendel:
I am still able to mod them the way I want.

Is it easy? No but well worth it.
[Android Software Development] slebit:
This tool is awesome. Have been successfull with a couple of apks, and hopefully a couple more. :)
[Android Software Development] fisha21:
The current version of apktool has so far worked with all sense5 apks that I've tried (all of framework/ and pretty much most of app/). Phone and settings just worked, but resources requires a bit of a workaround.

There is a thread explaining how to decompile resources:

http://xdaforums.com/showthread.php?t=2229230

And a post over in the vts thread that explains how to do this within vts. If it's not clear how to do this, post over in the vts thread and I'll try and help you there.

http://xdaforums.com/showthread.php?p=42564442

(its also worth reading the couple of posts before the one I linked to)
[Android Software Development] mateorod:
I deploy apktool in mass quantities to users, so I want to express my gratitude that the project found such an able maintainer first of all.

I come to the thread because I am looking to learn how to cross compile aapt/apktool for Mac. I read that iBotPeaches has some bash scripts that he uses to quickly produce binaries for all OS, so it must be possible without too much effort.

I do not cross-compile ever, really and thought I would ask if anyone in the thread has some advice. I looked through the apktool build scripts some, but didn't see any flags I could easily set. I saw the OS support for Darwin, but I don't think that would do it ;).

Thanks for all the work on the project, peaches!
[Android Software Development] iBotPeaches:
Java in itself as you know works everywhere, (with the little hitches of newlines and path separator hiccups), so the real problem comes down to compiling aapt for its native operating system. Thankfully, changes to aapt are rare. They only happen a few times a year, (unless a mod team adds a new feature which requires a new aapt build).

As for my bash scripts. They are nothing special

rm -rf ~/Projects/Android/frameworks/base
repo sync -j8
cd ~/Projects/platform_frameworks_base
git stash
git fetch
git merge upstream/master
rm -rf ~/Projects/Android/frameworks/base
cd ~/Projects/platform_frameworks_base
mkdir -p ~/Projects/Android/frameworks/base
cp * ~/Projects/Android/frameworks/base
source build/envsetup.sh
lunch full-eng
echo "building linux aapt"
make -j4
lunch sdk-eng
echo "building windows aapt"
make PRODUCT-sdk-win_sdk -j4
VBoxManage startvm "Mac OSX"
[ run script on Mac]

The secret is maintaining your own aapt repo: https://github.com/iBotPeaches/platform_frameworks_base and keeping it up to date w/ the upstream master, so that when you repo sync it doesn't cause conflicts with your outdated one.

So basically, I repo sync the AOSP tree, it reverses my work on frameworks/base, so I then pull upstream changes into my local copy of frameworks/base and manually move it into the AOSP tree. (Yes, I could get this done by just editing the repo_manifest, but this method works everywhere and is less stressful.

It is becoming more difficult today, since Apktool 2.0 requires JRE 1.7, and AOSP will NOT build on JDK 1.7, so I have another script which messes with update-alternatives --config java, and helps set the correct java version during an Apktool build VS an AOSP aapt build.

Though the payoff is incredible :), An Apktool build that has its own aapt removes 80% of the questions that are posted here and removes the dependency on including AAPT in your path.
[Android Software Development] mateorod:
I have not looked too closely at your plans for 2.0, but I am certainly familiar with the questions I see you getting about aapt not being in the path. 80% is probably generous :) If you are adding aapt to apktool, I think that is a Great Idea.

So I see you are building the OSX aapt on a virtual image, that is perhaps something I can do. I have been seeing a bunch of errors with SlimRoms, even when I am using the 1.5.3 snapshot build (built maybe two weeks ago). Testing with the SlimRom compiled apktool packages (which only exist for Windows and Linux) has ended those errors. So I am going to try shipping the SlimRom apktool instead of the 1.53 snapshot for now (as I know you are busy frying the big fish).

But that still left me the OSX to sort out myself and I thought perhaps I would check here about cross-compiling. Looking at the SlimRom aapt code, they do have their own changes so my guess is that I will need to figure something out for my OSX users. I can decide to compile from a VM, or maybe even find an OSX owner to run a build for me. Thanks so much for the advice, I appreciate your work.
[Android Software Development] HTC_M7:
I need help. Keep getting this error with miuiv5.

http://pastebin.com/ZFuQuhUM

Please help. Thanks
[Android Software Development] cowsquad:
Have you installed framewor-res.apk and framework-miui-res.apk? What aapt are you using? Miui has its own aapt
[Android Software Development] HTC_M7:
Yep. I dont understand whats wrong.
[Android Software Development] v1r0x:
yeah, looks like something is wrong with aapt (at least this was the error I got on my old htc vision :D)

Hope you can fix it. Nice to see someone porting for the one :)

I would have started in about 4 weeks, after my semester.
[Android Software Development] HTC_M7:
Ahh cool man...not sure why no one has done anything bout it. Its all the same methods but need to get past this first.
[Android Software Development] v1r0x:
yeah, porting is not that hard (only if something is wrong with aapt or apktool ;)) but it needs a lot of time.
[Android Software Development] HTC_M7:
Yea unless you got a pat down method for each build. Then its a piece of cake. Make a quick script and it can do it for you. Thats what i did for v4 personal builds.
[Android Software Development] iBotPeaches:
On rebuild use this aapt.

http://miui.connortumbleson.com/other/aapt/

So add the --aapt /path/to/aapt/ as a parameter.
[Android Software Development] codexc:
i have an apktool java v2.0 !! from mr connor :P
[Android Software Development] iBotPeaches:
A wrote a long little post today on Google Plus about Apktool 2.

https://plus.google.com/112346535434889804882/posts/2xi3u39znGd

Basically, I want to drop the JRE 1.7 requirement (which would delay 2.0), but I think its for the best. Read the post if interested.
[Android Software Development] raziel23x:
Well most java 1.7 comes as default on windows 8
[Android Software Development] PerfectSlayer:
Answered on the plus post but I prefer the use of java 7. So don't bother with the drop of jre7 requirement ;)

Envoyé depuis mon HTC Desire en utilisant Tapatalk 4 Beta
[Android Software Development] raziel23x:
Java 1.7x comes standard and default on all windows 8 machines so the new to apktool window users who just got there computer will have to have a hassle of having to downgrade and then have to really search to find the now unsupported 1.6x since on the java website moved java 1.6x else where since they dropped support
[Android Software Development] iBotPeaches:
Java is backwards compatible. You can run 1.6 built apps (which I believe are class file 50 versioned), on a 1.7 JRE. The problem is our current Apktool 2.0 builds have a 51 class file version (which is 1.7). Those will throw that nasty "invalid minor/major version" error on a 1.6 JRE (since it has no support for the 51 class file). We could always compile in JDK7 using the targeted JRE of 6, but we need to remove java.nio (if we do that), which is unfortunately one of the big things we added heavily into the code.

Also, how many apktool devs are actually using Windows 8 :o
[Android Software Development] PerfectSlayer:
But why not only make java7 as requirement for apktool?

If all apps continue to run on java 6, the 7th version will never be used.. =/

Envoyé depuis mon HTC Desire en utilisant Tapatalk 4 Beta
[Android Software Development] kapil_dheer:
While decompiling an app, I got the following error

C:\New folder>apktool d tools.apk

I: Baksmaling...

This dex file has a link section, which is not supported. Ignoring.

Exception in thread "main" org.jf.dexlib.Util.ExceptionWithContext: Index: 21366

, Size: 5474

at org.jf.dexlib.Util.ExceptionWithContext.withContext(ExceptionWithCont

ext.java:54)

at org.jf.dexlib.IndexedSection.getItemByIndex(IndexedSection.java:77)

at org.jf.dexlib.Code.InstructionWithReference.lookupReferencedItem(Inst

ructionWithReference.java:79)

at org.jf.dexlib.Code.InstructionWithReference.(InstructionWithRef

erence.java:57)

at org.jf.dexlib.Code.Format.Instruction21c.(Instruction21c.java:6

3)

at org.jf.dexlib.Code.Format.Instruction21c.(Instruction21c.java:4

0)

at org.jf.dexlib.Code.Format.Instruction21c$Factory.makeInstruction(Inst

ruction21c.java:112)

at org.jf.dexlib.Code.InstructionIterator.IterateInstructions(Instructio

nIterator.java:82)

at org.jf.dexlib.CodeItem.readItem(CodeItem.java:154)

at org.jf.dexlib.Item.readFrom(Item.java:77)

at org.jf.dexlib.OffsettedSection.readItems(OffsettedSection.java:48)

at org.jf.dexlib.Section.readFrom(Section.java:143)

at org.jf.dexlib.DexFile.(DexFile.java:431)

at org.jf.dexlib.DexFile.(DexFile.java:267)

at brut.androlib.src.SmaliDecoder.decode(SmaliDecoder.java:49)

at brut.androlib.src.SmaliDecoder.decode(SmaliDecoder.java:34)

at brut.androlib.Androlib.decodeSourcesSmali(Androlib.java:74)

at brut.androlib.ApkDecoder.decode(ApkDecoder.java:89)

at brut.apktool.Main.cmdDecode(Main.java:146)

at brut.apktool.Main.main(Main.java:77)

Caused by: java.lang.IndexOutOfBoundsException: Index: 21366, Size: 5474

at java.util.ArrayList.RangeCheck(Unknown Source)

at java.util.ArrayList.get(Unknown Source)

at org.jf.dexlib.IndexedSection.getItemByIndex(IndexedSection.java:75)

... 18 more

Error occured while retrieving the field_id_item item at index 21366

Error occured at code address 16

code_item @0xc3a4c

What can be the reason for this......can anybody explain this.
[Android Software Development] iBotPeaches:
While that is true, People can use Java7 on any 1.6 applications. Once Java has an auto update from v6 to v7, I think we can start releasing v7 apps.

Known bug: https://code.google.com/p/android-apktool/issues/detail?id=421 Will be fixed when we merge smali2 into apktool2. (However smali2 is very different in the terms that Apktool uses it, so we might need more time to polish and fix it up).
[Android Software Development] PerfectSlayer:
It's already the case since December 12:

Source: http://www.oracle.com/technetwork/java/javase/documentation/autoupdate-1667051.html

So you can start releasing 1.7 version ;)
[Android Software Development] Ticklefish:
Can apktool cope with drawable-ldrtl folders? A recent attempted mod threw up this error and it's the first time I'd ever heard of the things..

W: Could not find sources

I: Building resources...

invalid resource directory name: C:\TickleMyAndroid\_working\framework-res.apk\res/drawable-ldrtl-hdpi

invalid resource directory name: C:\TickleMyAndroid\_working\framework-res.apk\res/drawable-ldrtl-xhdpi

Exception in thread "main" brut.androlib.AndrolibException: brut.androlib.AndrolibException: brut.common.BrutException: could not exec command: [aapt, p, --min-sdk-version, 17, --target-sdk-version, 17, -F, C:\Users\Alex\AppData\Local\Temp\APKTOOL8980600922465156043.tmp, -x, -0, arsc, -S, C:\TickleMyAndroid\_working\framework-res.apk\res, -M, C:\TickleMyAndroid\_working\framework-res.apk\AndroidManifest.xml]

at brut.androlib.Androlib.buildResourcesFull(Androlib.java:358)

at brut.androlib.Androlib.buildResources(Androlib.java:283)

at brut.androlib.Androlib.build(Androlib.java:206)

at brut.androlib.Androlib.build(Androlib.java:176)

at brut.apktool.Main.cmdBuild(Main.java:228)

at brut.apktool.Main.main(Main.java:79)

Caused by: brut.androlib.AndrolibException: brut.common.BrutException: could not exec command: [aapt, p, --min-sdk-version, 17, --target-sdk-version,

17, -F, C:\Users\Alex\AppData\Local\Temp\APKTOOL8980600922465156043.tmp, -x, -0, arsc, -S, C:\TickleMyAndroid\_working\framework-res.apk\res, -M, C:\TickleMyAndroid\_working\framework-res.apk\AndroidManifest.xml]

at brut.androlib.res.AndrolibResources.aaptPackage(AndrolibResources.java:357)

at brut.androlib.Androlib.buildResourcesFull(Androlib.java:336)

... 5 more

Caused by: brut.common.BrutException: could not exec command: [aapt, p, --min-sdk-version, 17, --target-sdk-version, 17, -F, C:\Users\Alex\AppData\Local\Temp\APKTOOL8980600922465156043.tmp, -x, -0, arsc, -S, C:\TickleMyAndroid\_working\framework-res.apk\res, -M, C:\TickleMyAndroid\_working\framework-res.apk\AndroidManifest.xml]

at brut.util.OS.exec(OS.java:89)

at brut.androlib.res.AndrolibResources.aaptPackage(AndrolibResources.java:355)

... 6 more
[Android Software Development] iBotPeaches:
It can. The problem is the mix of forward slashes and backslashes. Which makes the directory invalid. Still don't know if apktool / os / aapt is causing that. Haven't ever been able to reproduce.