references broken in AndroidManifest.xml due to public.xml #636

Closed
iBotPeaches opened this Issue Mar 18, 2015 · 35 comments

Comments

Projects
None yet
2 participants
@iBotPeaches
Owner

iBotPeaches commented Mar 18, 2015

Original issue 526 created by metsman83 on 2013-10-13T06:19:35.000Z:

What steps will reproduce the problem?
1.Decompile Google Keyboard APK
2.Recompile apk with or without changes.
3.

What is the expected output? What do you see instead?
Expected a recompiled usable apk, similar to when I run same commands to Android(Nexus) Keyboard. Instead I get tons of errors stateing cannot find res identifier.

What version of the product are you using? On what operating system?
1.5.2 and Windows 7 64bit

Please provide any additional information below.
This issue was touched on in topic # 252. It is a somewhat old post and not extremly clear. I have tried doing what was suggested several times and cant get the command to work or the apk to recompile. The steps I took are:
1)apktool d com.google.android.inputmethod.latin-1.apk
2)changed package name in manifest to:"com.android.inputmethod.latin" (removing "google")

FYI-Not sure if it matters but apktool.yml reads:
version: 1.5.2
apkFileName: com.google.android.inputmethod.latin-1.apk
isFrameworkApk: false
usesFramework:
ids:

  • 1
    sdkInfo:
    minSdkVersion: '14'
    targetSdkVersion: '17'
    packageInfo:
    cur_package: android
    orig_package: com.google.android.inputmethod.latin
    compressionType: false

3)I think this is where Im running into problems. I tried the following 3 commands:
apktool b com.google.android.inputmethod.latin --rename-manifest-package

apktool b com.google.android.inputmethod.latin --rename w/ original_package

apktool b com.google.android.inputmethod.latin --rename w/ com.google.android.inputmethod.latin

Nothing seems to work. All it does is rename the file. Im pretty new to this and apoligize for the potentially stupid questions. If someone could help that would be amazing! Not sure if this fix is being worked into 2.0, I really hope so!

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #1 originally posted by metsman83 on 2013-10-13T06:28:31.000Z:

I forgot to mention one thing. When I said nothing works after my step 3, I ment to say I still have the same results as before when I only changed the manifest and skipped the --rename step. That result is a compile signed apk that immediately gives me a parsing error. I assume this is due to me renaming the manifest. WOW! Dont know how you REAL Dev's do it but this is a true test of patience.

Owner

iBotPeaches commented Mar 18, 2015

Comment #1 originally posted by metsman83 on 2013-10-13T06:28:31.000Z:

I forgot to mention one thing. When I said nothing works after my step 3, I ment to say I still have the same results as before when I only changed the manifest and skipped the --rename step. That result is a compile signed apk that immediately gives me a parsing error. I assume this is due to me renaming the manifest. WOW! Dont know how you REAL Dev's do it but this is a true test of patience.

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #2 originally posted by connor.tumbleson on 2013-10-13T13:35:56.000Z:

I duplicated, but tempted to do nothing about it. Since the reason the automated manifest change is failing is because of the "android" package being the alternative.

I need to research this more.

fyi, there is no --rename manifest option at all. None of those 3 commands work at all. Its all automated.

Owner

iBotPeaches commented Mar 18, 2015

Comment #2 originally posted by connor.tumbleson on 2013-10-13T13:35:56.000Z:

I duplicated, but tempted to do nothing about it. Since the reason the automated manifest change is failing is because of the "android" package being the alternative.

I need to research this more.

fyi, there is no --rename manifest option at all. None of those 3 commands work at all. Its all automated.

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #3 originally posted by metsman83 on 2013-10-13T21:11:34.000Z:

Thanks for the resp once. Just wondering, what does the android package alternative mean and what causes this?

Owner

iBotPeaches commented Mar 18, 2015

Comment #3 originally posted by metsman83 on 2013-10-13T21:11:34.000Z:

Thanks for the resp once. Just wondering, what does the android package alternative mean and what causes this?

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #4 originally posted by metsman83 on 2013-11-05T21:34:49.000Z:

The new keyboard leaked from 4.4 is built the same way with android as the alternate package name.

Owner

iBotPeaches commented Mar 18, 2015

Comment #4 originally posted by metsman83 on 2013-11-05T21:34:49.000Z:

The new keyboard leaked from 4.4 is built the same way with android as the alternate package name.

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #5 originally posted by Brut.alll on 2013-11-15T12:24:26.000Z:

I'm kind of out of topic here, but if I understand this problem properly then it's pretty obvious apktool breaks XML files at decode time. It should automatically convert all xmlns declarations to original package name. Changing package name in AndroidManigfest.xml is a dirty hack, because resulting apk isn't the same as original one.

For now replace all: 'xmlns:latin="http://schemas.android.com/apk/res/com.android.inputmethod.latin"' with: 'xmlns:latin="http://schemas.android.com/apk/res/com.google.android.inputmethod.latin"'. If you're on linux you can do this by:

for f in grep 'xmlns:latin="http://schemas.android.com/apk/res/com.android.inputmethod.latin"' -r . -l; do mv $f $f.old; sed 's/xmlns:latin="http://schemas.android.com/apk/res/com.android.inputmethod.latin"/xmlns:latin="http://schemas.android.com/apk/res/com.google.android.inputmethod.latin"/' $f.old > $f; rm $f.old; done;

On Windows you can use Total Commander AFAIK.

I didn't test it by myself yet.

Owner

iBotPeaches commented Mar 18, 2015

Comment #5 originally posted by Brut.alll on 2013-11-15T12:24:26.000Z:

I'm kind of out of topic here, but if I understand this problem properly then it's pretty obvious apktool breaks XML files at decode time. It should automatically convert all xmlns declarations to original package name. Changing package name in AndroidManigfest.xml is a dirty hack, because resulting apk isn't the same as original one.

For now replace all: 'xmlns:latin="http://schemas.android.com/apk/res/com.android.inputmethod.latin"' with: 'xmlns:latin="http://schemas.android.com/apk/res/com.google.android.inputmethod.latin"'. If you're on linux you can do this by:

for f in grep 'xmlns:latin="http://schemas.android.com/apk/res/com.android.inputmethod.latin"' -r . -l; do mv $f $f.old; sed 's/xmlns:latin="http://schemas.android.com/apk/res/com.android.inputmethod.latin"/xmlns:latin="http://schemas.android.com/apk/res/com.google.android.inputmethod.latin"/' $f.old > $f; rm $f.old; done;

On Windows you can use Total Commander AFAIK.

I didn't test it by myself yet.

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #6 originally posted by connor.tumbleson on 2013-11-15T13:14:25.000Z:

Okay, so are you saying the change I did was wrong regarding --rename-manifest?

This is what I did.

  1. Checked if resource package is different than AndroidManifest.xml one
  2. If it is, rename the android:package to the one found in the resources.arsc, and store the original in apktool.yml
  3. On rebuild, use aapt's --rename-manifest-package if we have non-matching original & current package names in apktool.yml

This exact apk in issue # 252 used to resolve to this.

packageInfo:
cur_package: com.android.inputmethod.latin
orig_package: com.google.android.inputmethod.latin

Now, this version in bug # 526 resolves to

packageInfo:
cur_package: android
orig_package: com.google.android.inputmethod.latin

So when the package pulled from the resources.arsc is "android", none of the things I implemented from bug # 252 take part, because changing the package to "android" in the namespaces and other things break.

So my questions.

  1. Is our goal to match the namespace to the original package? During decompilation the namespace is

xmlns:latin="http://schemas.android.com/apk/res/com.android.inputmethod.latin"

while, the current package is: com.google.android.inputmethod.latin. This shows a difference, but is it enough to automatically rename them?

  1. Why did this apk used to work with my bug fix in # 252, I don't understand why the package would be "android" all of sudden.
Owner

iBotPeaches commented Mar 18, 2015

Comment #6 originally posted by connor.tumbleson on 2013-11-15T13:14:25.000Z:

Okay, so are you saying the change I did was wrong regarding --rename-manifest?

This is what I did.

  1. Checked if resource package is different than AndroidManifest.xml one
  2. If it is, rename the android:package to the one found in the resources.arsc, and store the original in apktool.yml
  3. On rebuild, use aapt's --rename-manifest-package if we have non-matching original & current package names in apktool.yml

This exact apk in issue # 252 used to resolve to this.

packageInfo:
cur_package: com.android.inputmethod.latin
orig_package: com.google.android.inputmethod.latin

Now, this version in bug # 526 resolves to

packageInfo:
cur_package: android
orig_package: com.google.android.inputmethod.latin

So when the package pulled from the resources.arsc is "android", none of the things I implemented from bug # 252 take part, because changing the package to "android" in the namespaces and other things break.

So my questions.

  1. Is our goal to match the namespace to the original package? During decompilation the namespace is

xmlns:latin="http://schemas.android.com/apk/res/com.android.inputmethod.latin"

while, the current package is: com.google.android.inputmethod.latin. This shows a difference, but is it enough to automatically rename them?

  1. Why did this apk used to work with my bug fix in # 252, I don't understand why the package would be "android" all of sudden.
@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #7 originally posted by Brut.alll on 2013-11-15T13:23:59.000Z:

Ok, give me some time, I have to look into it deeper, because I may be totally wrong. In the meantime metsman83 can check if above fix works for him.

Owner

iBotPeaches commented Mar 18, 2015

Comment #7 originally posted by Brut.alll on 2013-11-15T13:23:59.000Z:

Ok, give me some time, I have to look into it deeper, because I may be totally wrong. In the meantime metsman83 can check if above fix works for him.

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #8 originally posted by purple2k on 2013-11-28T14:47:05.000Z:

I'm facing the exact same issue.

I edited all the namespace properties in the XML files to be
"http://schemas.android.com/apk/res/com.google.android.inputmethod.latin"
instead of
"http://schemas.android.com/apk/res/com.android.inputmethod.latin"

This indeed makes the apk-tool compile it successfully - but the APK doesn't work when replacing the original (even if I change nothing, meaning- decompile, just edit namespaces to allow recompile, recompile).

Did anyone figure out a solution?

Owner

iBotPeaches commented Mar 18, 2015

Comment #8 originally posted by purple2k on 2013-11-28T14:47:05.000Z:

I'm facing the exact same issue.

I edited all the namespace properties in the XML files to be
"http://schemas.android.com/apk/res/com.google.android.inputmethod.latin"
instead of
"http://schemas.android.com/apk/res/com.android.inputmethod.latin"

This indeed makes the apk-tool compile it successfully - but the APK doesn't work when replacing the original (even if I change nothing, meaning- decompile, just edit namespaces to allow recompile, recompile).

Did anyone figure out a solution?

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #9 originally posted by metsman83 on 2013-11-28T21:04:11.000Z:

You beat me to it. I did the same thing, edited the same files and got the same results. I did a log cat on installation when the parse error occurred. I attached it below. It says binary error line # 140. Something about does not include authority attribute.

FYI: when I change the authority attributes in the manifest from
android:authorities="@string/authority"
To
android:authorities="com.Google.android.input method.latin"

I can compile AND actually install successfully. But the keyboard force closes non stop. That's the closest I've gotten to getting it to work.

I feel like we are getting close. Thanks to everyone for their efforts! Happy Thanksgiving!

Owner

iBotPeaches commented Mar 18, 2015

Comment #9 originally posted by metsman83 on 2013-11-28T21:04:11.000Z:

You beat me to it. I did the same thing, edited the same files and got the same results. I did a log cat on installation when the parse error occurred. I attached it below. It says binary error line # 140. Something about does not include authority attribute.

FYI: when I change the authority attributes in the manifest from
android:authorities="@string/authority"
To
android:authorities="com.Google.android.input method.latin"

I can compile AND actually install successfully. But the keyboard force closes non stop. That's the closest I've gotten to getting it to work.

I feel like we are getting close. Thanks to everyone for their efforts! Happy Thanksgiving!

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #10 originally posted by purple2k on 2013-12-11T11:47:52.000Z:

Is anyone working on this? It's awfully quiet in here and as far as I can tell, there is still no solution.

Owner

iBotPeaches commented Mar 18, 2015

Comment #10 originally posted by purple2k on 2013-12-11T11:47:52.000Z:

Is anyone working on this? It's awfully quiet in here and as far as I can tell, there is still no solution.

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #11 originally posted by connor.tumbleson on 2013-12-11T15:11:30.000Z:

To comment # 9, that is around where I'm at. I got around that, by using the stock manifest, thus not modifying it.

This should of prevented the attributes error, but it didn't. So some file, (not the AndroidManifest.xml) is being borked by Apktool. The difficult part, is I don't know what, and the only apks I can test with are these huge 100,000 total line Google apks.

I've been trying to create a very small apk that I can duplicate this problem with, then investigation will be easier.

Owner

iBotPeaches commented Mar 18, 2015

Comment #11 originally posted by connor.tumbleson on 2013-12-11T15:11:30.000Z:

To comment # 9, that is around where I'm at. I got around that, by using the stock manifest, thus not modifying it.

This should of prevented the attributes error, but it didn't. So some file, (not the AndroidManifest.xml) is being borked by Apktool. The difficult part, is I don't know what, and the only apks I can test with are these huge 100,000 total line Google apks.

I've been trying to create a very small apk that I can duplicate this problem with, then investigation will be easier.

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #12 originally posted by tsynik on 2013-12-17T14:28:06.000Z:

I have similar problem with latest latin.ime from google play (it is com.google.android.inputmethod.latin). I didn't changed any lines in manifest, only some graphics, and can't compile it back with latest apktool (2.0b8, built from GIT snapshot). Log in attach

Owner

iBotPeaches commented Mar 18, 2015

Comment #12 originally posted by tsynik on 2013-12-17T14:28:06.000Z:

I have similar problem with latest latin.ime from google play (it is com.google.android.inputmethod.latin). I didn't changed any lines in manifest, only some graphics, and can't compile it back with latest apktool (2.0b8, built from GIT snapshot). Log in attach

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #13 originally posted by tsynik on 2013-12-17T14:42:55.000Z:

After suggested changes from comment # 5 there is only few errors on compile:

command: apktool b -f _INPUT_APK/inputmethod.latin
I: Using Apktool 2.0.0-Beta8 on inputmethod.latin
I: Smaling...
I: Building resources...
/Volumes/HD/MF353ZP/KITCHEN/_INPUT_APK/inputmethod.latin/AndroidManifest.xml:15: error: No resource identifier found for attribute 'requiredForAllUsers' in package 'android'
Exception in thread "main" brut.androlib.AndrolibException: brut.androlib.AndrolibException: brut.common.BrutException: could not exec command: [/var/folders/k7/5t4zlt790lg9kl5j655ycnf80000gn/T/brut_util_Jar_8626231630961931680.tmp, p, --forced-package-id, 1, --min-sdk-version, 14, --target-sdk-version, 18, --version-code, 19133, --version-name, 2.0.19133.927933a, -F, /var/folders/k7/5t4zlt790lg9kl5j655ycnf80000gn/T/APKTOOL3455357942367288543.tmp, -0, arsc, -I, /Users/nikk/Library/apktool/framework/1.apk, -S, /Volumes/HD/MF353ZP/KITCHEN/_INPUT_APK/inputmethod.latin/res, -M, /Volumes/HD/MF353ZP/KITCHEN/_INPUT_APK/inputmethod.latin/AndroidManifest.xml]
at brut.androlib.Androlib.buildResourcesFull(Androlib.java:434)
at brut.androlib.Androlib.buildResources(Androlib.java:362)
at brut.androlib.Androlib.build(Androlib.java:285)
at brut.androlib.Androlib.build(Androlib.java:258)
at brut.apktool.Main.cmdBuild(Main.java:236)
at brut.apktool.Main.main(Main.java:88)
Caused by: brut.androlib.AndrolibException: brut.common.BrutException: could not exec command: [/var/folders/k7/5t4zlt790lg9kl5j655ycnf80000gn/T/brut_util_Jar_8626231630961931680.tmp, p, --forced-package-id, 1, --min-sdk-version, 14, --target-sdk-version, 18, --version-code, 19133, --version-name, 2.0.19133.927933a, -F, /var/folders/k7/5t4zlt790lg9kl5j655ycnf80000gn/T/APKTOOL3455357942367288543.tmp, -0, arsc, -I, /Users/nikk/Library/apktool/framework/1.apk, -S, /Volumes/HD/MF353ZP/KITCHEN/_INPUT_APK/inputmethod.latin/res, -M, /Volumes/HD/MF353ZP/KITCHEN/_INPUT_APK/inputmethod.latin/AndroidManifest.xml]
at brut.androlib.res.AndrolibResources.aaptPackage(AndrolibResources.java:469)
at brut.androlib.Androlib.buildResourcesFull(Androlib.java:415)
... 5 more
Caused by: brut.common.BrutException: could not exec command: [/var/folders/k7/5t4zlt790lg9kl5j655ycnf80000gn/T/brut_util_Jar_8626231630961931680.tmp, p, --forced-package-id, 1, --min-sdk-version, 14, --target-sdk-version, 18, --version-code, 19133, --version-name, 2.0.19133.927933a, -F, /var/folders/k7/5t4zlt790lg9kl5j655ycnf80000gn/T/APKTOOL3455357942367288543.tmp, -0, arsc, -I, /Users/nikk/Library/apktool/framework/1.apk, -S, /Volumes/HD/MF353ZP/KITCHEN/_INPUT_APK/inputmethod.latin/res, -M, /Volumes/HD/MF353ZP/KITCHEN/_INPUT_APK/inputmethod.latin/AndroidManifest.xml]
at brut.util.OS.exec(OS.java:89)
at brut.androlib.res.AndrolibResources.aaptPackage(AndrolibResources.java:463)
... 6 more

I think problem is Skipping "android" package group on decompile time:

[_] /Volumes/HD/MF353ZP/KITCHEN/_INPUT_APK/inputmethod.latin.apk
decompiling /Volumes/HD/MF353ZP/KITCHEN/_INPUT_APK/inputmethod.latin.apk...
decompiling INPUT_APK/inputmethod.latin...
I: Using Apktool 2.0.0-Beta8 on inputmethod.latin.apk
I: Loading resource table...
W: Skipping "android" package group
I: Loading resource table...
W: Skipping "android" package group
I: Decoding AndroidManifest.xml with resources...
I: Loading resource table from file: /Users/user/Library/apktool/framework/1.apk
I: Regular manifest package...
I: Decoding file-resources...
I: Decoding values */
XMLs...
I: Baksmaling...
I: Copying assets and libs...
I: Copying unknown files/dir...
I: Copying original files...

Owner

iBotPeaches commented Mar 18, 2015

Comment #13 originally posted by tsynik on 2013-12-17T14:42:55.000Z:

After suggested changes from comment # 5 there is only few errors on compile:

command: apktool b -f _INPUT_APK/inputmethod.latin
I: Using Apktool 2.0.0-Beta8 on inputmethod.latin
I: Smaling...
I: Building resources...
/Volumes/HD/MF353ZP/KITCHEN/_INPUT_APK/inputmethod.latin/AndroidManifest.xml:15: error: No resource identifier found for attribute 'requiredForAllUsers' in package 'android'
Exception in thread "main" brut.androlib.AndrolibException: brut.androlib.AndrolibException: brut.common.BrutException: could not exec command: [/var/folders/k7/5t4zlt790lg9kl5j655ycnf80000gn/T/brut_util_Jar_8626231630961931680.tmp, p, --forced-package-id, 1, --min-sdk-version, 14, --target-sdk-version, 18, --version-code, 19133, --version-name, 2.0.19133.927933a, -F, /var/folders/k7/5t4zlt790lg9kl5j655ycnf80000gn/T/APKTOOL3455357942367288543.tmp, -0, arsc, -I, /Users/nikk/Library/apktool/framework/1.apk, -S, /Volumes/HD/MF353ZP/KITCHEN/_INPUT_APK/inputmethod.latin/res, -M, /Volumes/HD/MF353ZP/KITCHEN/_INPUT_APK/inputmethod.latin/AndroidManifest.xml]
at brut.androlib.Androlib.buildResourcesFull(Androlib.java:434)
at brut.androlib.Androlib.buildResources(Androlib.java:362)
at brut.androlib.Androlib.build(Androlib.java:285)
at brut.androlib.Androlib.build(Androlib.java:258)
at brut.apktool.Main.cmdBuild(Main.java:236)
at brut.apktool.Main.main(Main.java:88)
Caused by: brut.androlib.AndrolibException: brut.common.BrutException: could not exec command: [/var/folders/k7/5t4zlt790lg9kl5j655ycnf80000gn/T/brut_util_Jar_8626231630961931680.tmp, p, --forced-package-id, 1, --min-sdk-version, 14, --target-sdk-version, 18, --version-code, 19133, --version-name, 2.0.19133.927933a, -F, /var/folders/k7/5t4zlt790lg9kl5j655ycnf80000gn/T/APKTOOL3455357942367288543.tmp, -0, arsc, -I, /Users/nikk/Library/apktool/framework/1.apk, -S, /Volumes/HD/MF353ZP/KITCHEN/_INPUT_APK/inputmethod.latin/res, -M, /Volumes/HD/MF353ZP/KITCHEN/_INPUT_APK/inputmethod.latin/AndroidManifest.xml]
at brut.androlib.res.AndrolibResources.aaptPackage(AndrolibResources.java:469)
at brut.androlib.Androlib.buildResourcesFull(Androlib.java:415)
... 5 more
Caused by: brut.common.BrutException: could not exec command: [/var/folders/k7/5t4zlt790lg9kl5j655ycnf80000gn/T/brut_util_Jar_8626231630961931680.tmp, p, --forced-package-id, 1, --min-sdk-version, 14, --target-sdk-version, 18, --version-code, 19133, --version-name, 2.0.19133.927933a, -F, /var/folders/k7/5t4zlt790lg9kl5j655ycnf80000gn/T/APKTOOL3455357942367288543.tmp, -0, arsc, -I, /Users/nikk/Library/apktool/framework/1.apk, -S, /Volumes/HD/MF353ZP/KITCHEN/_INPUT_APK/inputmethod.latin/res, -M, /Volumes/HD/MF353ZP/KITCHEN/_INPUT_APK/inputmethod.latin/AndroidManifest.xml]
at brut.util.OS.exec(OS.java:89)
at brut.androlib.res.AndrolibResources.aaptPackage(AndrolibResources.java:463)
... 6 more

I think problem is Skipping "android" package group on decompile time:

[_] /Volumes/HD/MF353ZP/KITCHEN/_INPUT_APK/inputmethod.latin.apk
decompiling /Volumes/HD/MF353ZP/KITCHEN/_INPUT_APK/inputmethod.latin.apk...
decompiling INPUT_APK/inputmethod.latin...
I: Using Apktool 2.0.0-Beta8 on inputmethod.latin.apk
I: Loading resource table...
W: Skipping "android" package group
I: Loading resource table...
W: Skipping "android" package group
I: Decoding AndroidManifest.xml with resources...
I: Loading resource table from file: /Users/user/Library/apktool/framework/1.apk
I: Regular manifest package...
I: Decoding file-resources...
I: Decoding values */
XMLs...
I: Baksmaling...
I: Copying assets and libs...
I: Copying unknown files/dir...
I: Copying original files...

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #14 originally posted by connor.tumbleson on 2013-12-19T01:32:28.000Z:

<empty>

Owner

iBotPeaches commented Mar 18, 2015

Comment #14 originally posted by connor.tumbleson on 2013-12-19T01:32:28.000Z:

<empty>

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #15 originally posted by connor.tumbleson on 2013-12-22T05:43:40.000Z:

Issue 573 has been merged into this issue.

Owner

iBotPeaches commented Mar 18, 2015

Comment #15 originally posted by connor.tumbleson on 2013-12-22T05:43:40.000Z:

Issue 573 has been merged into this issue.

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #16 originally posted by connor.tumbleson on 2014-01-04T04:01:43.000Z:

With more research. I've come down to this.

There are many places in the Manifest where @string references are used, anywhere from android:name -> android:authorities.

The problem I've found is that if they are in @string form like below
android:authorities="@string/authority"

The corresponding resources.arsc file produced has the attributes in reference to @string/authority in literal value instead of the the value of @string/authority.

This poses three weird problems.

  1. When you build an APK in IntelliJ or Eclipse. Your project doesn't "undo" your @string references. So the change must happen during compilation.
  2. However, during decode. We see the @string reference, so its being compiled as @string, not the value of that @string.
  3. If # 2 was true though, then we wouldn't have a problem. However, we do. Because manually replacing all values of @string in the manifest for :name / :label / etc, causes the apk to rebuild and load correctly.

So yes. Documenting my thoughts. I'm also starting to think that all these recent bugs is just one big bug. Maybe a combination of the public flags / namespace / @string references.

Owner

iBotPeaches commented Mar 18, 2015

Comment #16 originally posted by connor.tumbleson on 2014-01-04T04:01:43.000Z:

With more research. I've come down to this.

There are many places in the Manifest where @string references are used, anywhere from android:name -> android:authorities.

The problem I've found is that if they are in @string form like below
android:authorities="@string/authority"

The corresponding resources.arsc file produced has the attributes in reference to @string/authority in literal value instead of the the value of @string/authority.

This poses three weird problems.

  1. When you build an APK in IntelliJ or Eclipse. Your project doesn't "undo" your @string references. So the change must happen during compilation.
  2. However, during decode. We see the @string reference, so its being compiled as @string, not the value of that @string.
  3. If # 2 was true though, then we wouldn't have a problem. However, we do. Because manually replacing all values of @string in the manifest for :name / :label / etc, causes the apk to rebuild and load correctly.

So yes. Documenting my thoughts. I'm also starting to think that all these recent bugs is just one big bug. Maybe a combination of the public flags / namespace / @string references.

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #17 originally posted by metsman83 on 2014-01-05T02:50:51.000Z:

I am happy to report that I have a fully themed Google Keyboard. Successfully decompiled, edited xml's and res files, recompiled, signed and working with no problems! I doubt this would be considered an official fix. My amateur onion is, it's a really sweet work around. I stumbled on this a few days ago, through lots of trial and error and even more reading and research. There(to the best of my knowledge)are no methods anywhere on the web that produce a working Google Keyboard, until now. Thank you to everyone who helped on Issue 526. Big THANKS especially to connor.tumbleson(aka:iBotPeaches) AND, The Man Himself, Brut.all, for their help and suggestions which lead to the following:
*I used apktool version 1.5.2 and Android API_19 framework
1)Decompile Google Keyboard
2)Make whatever mods you want.
3)Using notepad++ open android manifest. You need to edit 2 lines:
Manifest Line # 2: package="com.google.android.inputmethod.latin"
CHANGE TO
package="com.android.inputmethod.latin"

Manifest Line # 85: android:authorities="@string/authority"
CHANGE TO
android:authorities="com.google.android.inputmethod.dictionarypack"
4)Save Android Manifest and compile the apk.
5)Using 7-Zip(or similar)open the built apk and pull out the Android Manifest, resources.arsc, classes.dex. Also, any drawable folder that you added png/theme to.
6)Take the files you just pulled and and put them into a fresh, unmodified Google Keyboard APK. Make sure they go back where they came from: Manif. Res.arsc and class.dex to the root of the apk. Drawable folders go in the res folder.
7)Sign Apk and Install
8)Come see 33 new reasons why I'm so happy this got done! Shaftamle Keyboards, Google It!
Also, if you need help with this work around you can PM me on XDA at Shaftamle so we can keep the apktool home to exactly that and not a Q and A.
Seriously, thank you everyone for all the help!!

Owner

iBotPeaches commented Mar 18, 2015

Comment #17 originally posted by metsman83 on 2014-01-05T02:50:51.000Z:

I am happy to report that I have a fully themed Google Keyboard. Successfully decompiled, edited xml's and res files, recompiled, signed and working with no problems! I doubt this would be considered an official fix. My amateur onion is, it's a really sweet work around. I stumbled on this a few days ago, through lots of trial and error and even more reading and research. There(to the best of my knowledge)are no methods anywhere on the web that produce a working Google Keyboard, until now. Thank you to everyone who helped on Issue 526. Big THANKS especially to connor.tumbleson(aka:iBotPeaches) AND, The Man Himself, Brut.all, for their help and suggestions which lead to the following:
*I used apktool version 1.5.2 and Android API_19 framework
1)Decompile Google Keyboard
2)Make whatever mods you want.
3)Using notepad++ open android manifest. You need to edit 2 lines:
Manifest Line # 2: package="com.google.android.inputmethod.latin"
CHANGE TO
package="com.android.inputmethod.latin"

Manifest Line # 85: android:authorities="@string/authority"
CHANGE TO
android:authorities="com.google.android.inputmethod.dictionarypack"
4)Save Android Manifest and compile the apk.
5)Using 7-Zip(or similar)open the built apk and pull out the Android Manifest, resources.arsc, classes.dex. Also, any drawable folder that you added png/theme to.
6)Take the files you just pulled and and put them into a fresh, unmodified Google Keyboard APK. Make sure they go back where they came from: Manif. Res.arsc and class.dex to the root of the apk. Drawable folders go in the res folder.
7)Sign Apk and Install
8)Come see 33 new reasons why I'm so happy this got done! Shaftamle Keyboards, Google It!
Also, if you need help with this work around you can PM me on XDA at Shaftamle so we can keep the apktool home to exactly that and not a Q and A.
Seriously, thank you everyone for all the help!!

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #18 originally posted by philip.diantonio on 2014-01-05T03:40:51.000Z:

any chance you could be a little more specific about this part:

  "*I used apktool version 1.5.2 and Android API_19 framework"

i am using APKTool 1.52 from iBotPeaches XDA thread (http://forum.xda-developers.com/showthread.php?t=1755243) but still cannot compile successfully when making only the two android manifest changes listed above.

first error from APKTool is:

"C:\Users\Phil\apktool\com.google.android.inputmethod.latin2p0p19133p927933a\AndroidManifest.xml:16: error: No resource identifier found for attribute 'requiredForAllUsers' in package 'android'"

Owner

iBotPeaches commented Mar 18, 2015

Comment #18 originally posted by philip.diantonio on 2014-01-05T03:40:51.000Z:

any chance you could be a little more specific about this part:

  "*I used apktool version 1.5.2 and Android API_19 framework"

i am using APKTool 1.52 from iBotPeaches XDA thread (http://forum.xda-developers.com/showthread.php?t=1755243) but still cannot compile successfully when making only the two android manifest changes listed above.

first error from APKTool is:

"C:\Users\Phil\apktool\com.google.android.inputmethod.latin2p0p19133p927933a\AndroidManifest.xml:16: error: No resource identifier found for attribute 'requiredForAllUsers' in package 'android'"

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #19 originally posted by philip.diantonio on 2014-01-05T04:26:17.000Z:

ok, so i deleted the "requiredForAllUsers" tag on line 16, successfully recompiled, completed steps 5-7 and installed. it works!

thanks for sharing this Shaftamle!

Owner

iBotPeaches commented Mar 18, 2015

Comment #19 originally posted by philip.diantonio on 2014-01-05T04:26:17.000Z:

ok, so i deleted the "requiredForAllUsers" tag on line 16, successfully recompiled, completed steps 5-7 and installed. it works!

thanks for sharing this Shaftamle!

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #20 originally posted by metsman83 on 2014-01-05T04:56:59.000Z:

Glad it worked. Did you get the apk from the play store? That looks like one somebody already modded from the name of it. Maybe why the original error.but if it works that's the important thing.
What I meant was I'm using 1.5.2 and the framework that I installed using the "if" command is api level 19 or Android 4.4 framework-res.

Owner

iBotPeaches commented Mar 18, 2015

Comment #20 originally posted by metsman83 on 2014-01-05T04:56:59.000Z:

Glad it worked. Did you get the apk from the play store? That looks like one somebody already modded from the name of it. Maybe why the original error.but if it works that's the important thing.
What I meant was I'm using 1.5.2 and the framework that I installed using the "if" command is api level 19 or Android 4.4 framework-res.

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #21 originally posted by philip.diantonio on 2014-01-05T05:01:18.000Z:

thanks for the clarification, i understand now.

i started from a fresh copy of the current Play store keyboard (version
2.0.19133.927933a), no one modded it but me.

Owner

iBotPeaches commented Mar 18, 2015

Comment #21 originally posted by philip.diantonio on 2014-01-05T05:01:18.000Z:

thanks for the clarification, i understand now.

i started from a fresh copy of the current Play store keyboard (version
2.0.19133.927933a), no one modded it but me.

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #22 originally posted by metsman83 on 2014-01-05T05:07:12.000Z:

Good good! My mistake, I read your error log wrong. Just hope this still works when they update it. Happy themeing!!

Owner

iBotPeaches commented Mar 18, 2015

Comment #22 originally posted by metsman83 on 2014-01-05T05:07:12.000Z:

Good good! My mistake, I read your error log wrong. Just hope this still works when they update it. Happy themeing!!

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #23 originally posted by Brut.alll on 2014-01-07T00:03:37.000Z:

Ok, there are 2 distinct issues here. After fixing both of them I was able to rebuild working Google Keyboard.

First is a bug in apktool related to manifest renaming. At least I think it's a bug. As I said earlier, Connor, current apktool never uses "--rename-manifest-package" option. There is some code for it, but I think it's never used. What we need to do to get apk identical to original one is to:

  1. Rename package name in AndroidManifest.xml to com.android.inputmethod.latin .
  2. Add "--rename-manifest-package com.google.android.inputmethod.latin" when building.

I think apktool should do this automatically, because our ultimate task is to rebuild apk files as close to original ones as possible. I would add fixes for it, but I'm not sure why it's done as it is currently, so I would rather leave it to you.

Second issue is weird and I think it may be a bug in Android. It occurs if all below conditions are met:

  1. You use references instead of literals in AndroidManifest.xml
  2. You do this in some specific places, e.g. authorities attr in .
  3. Referenced resource is public.

I have no idea what private/public status has to do with manifest file, but it can be easily reproduced and confirmed. Just create new android app, add content provider, reference authorities to @string/somestring and set it to public - voila.

To rebuild working Google Keyboard I have workarounded that problem by setting all resources to private. Fixing it properly will be a little harder. First I want to know why public flag has such impact on references in AndroidManifest.xml . Then we can think of some implementation.

Owner

iBotPeaches commented Mar 18, 2015

Comment #23 originally posted by Brut.alll on 2014-01-07T00:03:37.000Z:

Ok, there are 2 distinct issues here. After fixing both of them I was able to rebuild working Google Keyboard.

First is a bug in apktool related to manifest renaming. At least I think it's a bug. As I said earlier, Connor, current apktool never uses "--rename-manifest-package" option. There is some code for it, but I think it's never used. What we need to do to get apk identical to original one is to:

  1. Rename package name in AndroidManifest.xml to com.android.inputmethod.latin .
  2. Add "--rename-manifest-package com.google.android.inputmethod.latin" when building.

I think apktool should do this automatically, because our ultimate task is to rebuild apk files as close to original ones as possible. I would add fixes for it, but I'm not sure why it's done as it is currently, so I would rather leave it to you.

Second issue is weird and I think it may be a bug in Android. It occurs if all below conditions are met:

  1. You use references instead of literals in AndroidManifest.xml
  2. You do this in some specific places, e.g. authorities attr in .
  3. Referenced resource is public.

I have no idea what private/public status has to do with manifest file, but it can be easily reproduced and confirmed. Just create new android app, add content provider, reference authorities to @string/somestring and set it to public - voila.

To rebuild working Google Keyboard I have workarounded that problem by setting all resources to private. Fixing it properly will be a little harder. First I want to know why public flag has such impact on references in AndroidManifest.xml . Then we can think of some implementation.

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #24 originally posted by connor.tumbleson on 2014-01-07T17:09:19.000Z:

This commit fixes the --rename bug: e254cec

As we have two bugs going on in here, I'll keep this open.

Owner

iBotPeaches commented Mar 18, 2015

Comment #24 originally posted by connor.tumbleson on 2014-01-07T17:09:19.000Z:

This commit fixes the --rename bug: e254cec

As we have two bugs going on in here, I'll keep this open.

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #25 originally posted by connor.tumbleson on 2014-01-10T16:40:29.000Z:

<empty>

Owner

iBotPeaches commented Mar 18, 2015

Comment #25 originally posted by connor.tumbleson on 2014-01-10T16:40:29.000Z:

<empty>

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #26 originally posted by HungTranViet on 2014-01-16T11:20:06.000Z:

I've got exact same issue when I changed only package name on AndroidManifest.xml (error No resource identifier found for attribute...).

After replaced all: 'xmlns:app="http://schemas.android.com/apk/res/"' with: 'xmlns:app="http://schemas.android.com/apk/res/"', the apk-tool compiled it successfully - but the APK did not work on my mobile.

Here is my apk file.

sorry my bad English.

Owner

iBotPeaches commented Mar 18, 2015

Comment #26 originally posted by HungTranViet on 2014-01-16T11:20:06.000Z:

I've got exact same issue when I changed only package name on AndroidManifest.xml (error No resource identifier found for attribute...).

After replaced all: 'xmlns:app="http://schemas.android.com/apk/res/"' with: 'xmlns:app="http://schemas.android.com/apk/res/"', the apk-tool compiled it successfully - but the APK did not work on my mobile.

Here is my apk file.

sorry my bad English.

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #27 originally posted by HungTranViet on 2014-01-16T11:21:31.000Z:

sorry,
More info:
I used both apktool 1.5.2 & 2.0B7 on Win7 32bit

Owner

iBotPeaches commented Mar 18, 2015

Comment #27 originally posted by HungTranViet on 2014-01-16T11:21:31.000Z:

sorry,
More info:
I used both apktool 1.5.2 & 2.0B7 on Win7 32bit

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #28 originally posted by pjakubczyk on 2014-06-17T15:08:54.000Z:

Refering to # 23 comment. I actually ran into the same problem and I'm wondering how we can change the apktool code to make it run. Of course it's possible to create a method which will replace the value from strings.xml but then we're losing part of our original code.

Is there anything where I can help in the source code? I already got a repo from github but a hint would be great.

Owner

iBotPeaches commented Mar 18, 2015

Comment #28 originally posted by pjakubczyk on 2014-06-17T15:08:54.000Z:

Refering to # 23 comment. I actually ran into the same problem and I'm wondering how we can change the apktool code to make it run. Of course it's possible to create a method which will replace the value from strings.xml but then we're losing part of our original code.

Is there anything where I can help in the source code? I already got a repo from github but a hint would be great.

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #29 originally posted by jarmezrocks on 2014-06-28T16:26:50.000Z:

I know this discussion has a little bit of age on it now, but I am digging back into the archives of my mind to when I was porting a TW application to try work on non-touchwiz AOSP devices (I900) and recall the issues to do with public and private references. Typically for public references if the resource is not present in the apk the system utilises the resources (images for instance) from the referencing framework, and that maybe either 1) the Framwork-res.apk 2) the additional proprietary framework tw-framework.apk for instance, which we would then register with APKtool as 2.apk as we all know.
What I do recall doing (this is really testing my memory now?) is finding the referencing resources (be that .9.pngs or standard pngs) from the tw-framework.apk and bringing them into the apk (I think this was the FM radio app at the time) and changing their reference from public to private. Now the tricky bit that I can't recall now, but I think we either had to completely delete the public xmls and let apk tool build the apk OR delete the resources.asc before we pub the files back inside a copy of the original apk. So I guess this method was much similar to the the one already described here in a previous post. We need to pull the internals out of the freshly recompiled apk and drop them into a copy of the original apk and then use apktool to decompile the apk a second time.... then (and only then) would all the hex offsets align correctly to match the resources for some reason? I can't remember clearly now what was happening at the time but I recall investigating things and I think if we decompile the recompiled apk (without swapping everything into a copy of the original) and take a look at the public.xmls there were references all over the place for APKTOOL_DUMMY AND/OR some abstract reference to the secondary framework like tw~res2 or something like that?
These would be scattered all throughout the xmls, and at first people were trying to manually go in and re-reference each and every incorrect offset without success.
Dropping the files into the original and decompiling the apk and then rebuilding it in most cases allowed the apk to not just build successfully but also install cause all the "new resources" now had the correct references; the new references would then be private references (or internal) this would tell the apk find graphics or resource files locally instead of looking for them "globally" in say the framework-res or other tw-framework etc.
I think if I also recall there was (at some point in time - ICS 4.04 maybe?) a similar issue with AOSP SystemUI decompiling ok but unable to recompile? I think someone ended up finding that the SystemUI needed to use its self as the "secondary framework" or something like that? This was suspected to be a bug in Googles code that incorrectly referenced resources as public that were actually private? The app was looking for things in the framework or somewhere that didn't actually exist and so the statusbar would force close...? Again my memory is foggy as it was long ago and it didn't concern me at the time because I was not using the standard AOSP SystemUI anyway.
Anyway that is my input, I maybe able to dig up some printed PDFs I had saved from the old CyanogenMod website? Chances of finding these again are next to nil unless I had links and the waybackmachine actually scanned those pages?
Sorry I can't be of any more help

Owner

iBotPeaches commented Mar 18, 2015

Comment #29 originally posted by jarmezrocks on 2014-06-28T16:26:50.000Z:

I know this discussion has a little bit of age on it now, but I am digging back into the archives of my mind to when I was porting a TW application to try work on non-touchwiz AOSP devices (I900) and recall the issues to do with public and private references. Typically for public references if the resource is not present in the apk the system utilises the resources (images for instance) from the referencing framework, and that maybe either 1) the Framwork-res.apk 2) the additional proprietary framework tw-framework.apk for instance, which we would then register with APKtool as 2.apk as we all know.
What I do recall doing (this is really testing my memory now?) is finding the referencing resources (be that .9.pngs or standard pngs) from the tw-framework.apk and bringing them into the apk (I think this was the FM radio app at the time) and changing their reference from public to private. Now the tricky bit that I can't recall now, but I think we either had to completely delete the public xmls and let apk tool build the apk OR delete the resources.asc before we pub the files back inside a copy of the original apk. So I guess this method was much similar to the the one already described here in a previous post. We need to pull the internals out of the freshly recompiled apk and drop them into a copy of the original apk and then use apktool to decompile the apk a second time.... then (and only then) would all the hex offsets align correctly to match the resources for some reason? I can't remember clearly now what was happening at the time but I recall investigating things and I think if we decompile the recompiled apk (without swapping everything into a copy of the original) and take a look at the public.xmls there were references all over the place for APKTOOL_DUMMY AND/OR some abstract reference to the secondary framework like tw~res2 or something like that?
These would be scattered all throughout the xmls, and at first people were trying to manually go in and re-reference each and every incorrect offset without success.
Dropping the files into the original and decompiling the apk and then rebuilding it in most cases allowed the apk to not just build successfully but also install cause all the "new resources" now had the correct references; the new references would then be private references (or internal) this would tell the apk find graphics or resource files locally instead of looking for them "globally" in say the framework-res or other tw-framework etc.
I think if I also recall there was (at some point in time - ICS 4.04 maybe?) a similar issue with AOSP SystemUI decompiling ok but unable to recompile? I think someone ended up finding that the SystemUI needed to use its self as the "secondary framework" or something like that? This was suspected to be a bug in Googles code that incorrectly referenced resources as public that were actually private? The app was looking for things in the framework or somewhere that didn't actually exist and so the statusbar would force close...? Again my memory is foggy as it was long ago and it didn't concern me at the time because I was not using the standard AOSP SystemUI anyway.
Anyway that is my input, I maybe able to dig up some printed PDFs I had saved from the old CyanogenMod website? Chances of finding these again are next to nil unless I had links and the waybackmachine actually scanned those pages?
Sorry I can't be of any more help

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #30 originally posted by jarmezrocks on 2014-06-28T16:28:48.000Z:

I know this discussion has a little bit of age on it now, but I am digging back into the archives of my mind to when I was porting a TW application to try work on non-touchwiz AOSP devices (I900) and recall the issues to do with public and private references. Typically for public references if the resource is not present in the apk the system utilises the resources (images for instance) from the referencing framework, and that maybe either 1) the Framwork-res.apk 2) the additional proprietary framework tw-framework.apk for instance, which we would then register with APKtool as 2.apk as we all know.
What I do recall doing (this is really testing my memory now?) is finding the referencing resources (be that .9.pngs or standard pngs) from the tw-framework.apk and bringing them into the apk (I think this was the FM radio app at the time) and changing their reference from public to private. Now the tricky bit that I can't recall now, but I think we either had to completely delete the public xmls and let apk tool build the apk OR delete the resources.asc before we put the files back inside a copy of the original apk. So I guess this method was much similar to the the one already described here in a previous post. We need to pull the internals out of the freshly recompiled apk and drop them into a copy of the original apk and then use apktool to decompile the apk a second time.... then (and only then) would all the hex offsets align correctly to match the resources for some reason? I can't remember clearly now what was happening at the time but I recall investigating things and I think if we decompile the recompiled apk (without swapping everything into a copy of the original) and take a look at the public.xmls there were references all over the place for APKTOOL_DUMMY AND/OR some abstract reference to the secondary framework like tw~res2 or something like that?
These would be scattered all throughout the xmls, and at first people were trying to manually go in and re-reference each and every incorrect offset without success.
Dropping the files into the original and decompiling the apk and then rebuilding it in most cases allowed the apk to not just build successfully but also install cause all the "new resources" now had the correct references; the new references would then be private references (or internal) this would tell the apk find graphics or resource files locally instead of looking for them "globally" in say the framework-res or other tw-framework etc.
I think if I also recall there was (at some point in time - ICS 4.04 maybe?) a similar issue with AOSP SystemUI decompiling ok but unable to recompile? I think someone ended up finding that the SystemUI needed to use its self as the "secondary framework" or something like that? This was suspected to be a bug in Googles code that incorrectly referenced resources as public that were actually private? The app was looking for things in the framework or somewhere that didn't actually exist and so the statusbar would force close...? Again my memory is foggy as it was long ago and it didn't concern me at the time because I was not using the standard AOSP SystemUI anyway.
Anyway that is my input, I maybe able to dig up some printed PDFs I had saved from the old CyanogenMod website? Chances of finding these again are next to nil unless I had links and the waybackmachine actually scanned those pages?
Sorry I can't be of any more help

Owner

iBotPeaches commented Mar 18, 2015

Comment #30 originally posted by jarmezrocks on 2014-06-28T16:28:48.000Z:

I know this discussion has a little bit of age on it now, but I am digging back into the archives of my mind to when I was porting a TW application to try work on non-touchwiz AOSP devices (I900) and recall the issues to do with public and private references. Typically for public references if the resource is not present in the apk the system utilises the resources (images for instance) from the referencing framework, and that maybe either 1) the Framwork-res.apk 2) the additional proprietary framework tw-framework.apk for instance, which we would then register with APKtool as 2.apk as we all know.
What I do recall doing (this is really testing my memory now?) is finding the referencing resources (be that .9.pngs or standard pngs) from the tw-framework.apk and bringing them into the apk (I think this was the FM radio app at the time) and changing their reference from public to private. Now the tricky bit that I can't recall now, but I think we either had to completely delete the public xmls and let apk tool build the apk OR delete the resources.asc before we put the files back inside a copy of the original apk. So I guess this method was much similar to the the one already described here in a previous post. We need to pull the internals out of the freshly recompiled apk and drop them into a copy of the original apk and then use apktool to decompile the apk a second time.... then (and only then) would all the hex offsets align correctly to match the resources for some reason? I can't remember clearly now what was happening at the time but I recall investigating things and I think if we decompile the recompiled apk (without swapping everything into a copy of the original) and take a look at the public.xmls there were references all over the place for APKTOOL_DUMMY AND/OR some abstract reference to the secondary framework like tw~res2 or something like that?
These would be scattered all throughout the xmls, and at first people were trying to manually go in and re-reference each and every incorrect offset without success.
Dropping the files into the original and decompiling the apk and then rebuilding it in most cases allowed the apk to not just build successfully but also install cause all the "new resources" now had the correct references; the new references would then be private references (or internal) this would tell the apk find graphics or resource files locally instead of looking for them "globally" in say the framework-res or other tw-framework etc.
I think if I also recall there was (at some point in time - ICS 4.04 maybe?) a similar issue with AOSP SystemUI decompiling ok but unable to recompile? I think someone ended up finding that the SystemUI needed to use its self as the "secondary framework" or something like that? This was suspected to be a bug in Googles code that incorrectly referenced resources as public that were actually private? The app was looking for things in the framework or somewhere that didn't actually exist and so the statusbar would force close...? Again my memory is foggy as it was long ago and it didn't concern me at the time because I was not using the standard AOSP SystemUI anyway.
Anyway that is my input, I maybe able to dig up some printed PDFs I had saved from the old CyanogenMod website? Chances of finding these again are next to nil unless I had links and the waybackmachine actually scanned those pages?
Sorry I can't be of any more help

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #31 originally posted by connor.tumbleson on 2014-06-30T12:38:09.000Z:

Issue 468 has been merged into this issue.

Owner

iBotPeaches commented Mar 18, 2015

Comment #31 originally posted by connor.tumbleson on 2014-06-30T12:38:09.000Z:

Issue 468 has been merged into this issue.

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #32 originally posted by connor.tumbleson on 2014-10-02T19:17:35.000Z:

<empty>

Owner

iBotPeaches commented Mar 18, 2015

Comment #32 originally posted by connor.tumbleson on 2014-10-02T19:17:35.000Z:

<empty>

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Mar 18, 2015

Owner

Comment #33 originally posted by connor.tumbleson on 2015-03-03T15:57:27.000Z:

Issue 755 has been merged into this issue.

Owner

iBotPeaches commented Mar 18, 2015

Comment #33 originally posted by connor.tumbleson on 2015-03-03T15:57:27.000Z:

Issue 755 has been merged into this issue.

@iBotPeaches iBotPeaches added Bug and removed Milestone-v2.0 labels Mar 18, 2015

@iBotPeaches iBotPeaches added this to the v2.0.0 Gold milestone Mar 18, 2015

@iBotPeaches iBotPeaches self-assigned this Mar 18, 2015

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches Apr 2, 2015

Owner

Started working on this. Basically on rebuild we check the AndroidManifest.xml for any android:authorities attribute that has an @string reference. We then follow that reference for the literal value and replace it.

Two problems

  1. The string cannot be found.
  2. Sometimes mutliple @string references are in the attribute value. I found this

A list of one or more URI authorities that identify data offered by the content provider. Multiple authorities are listed by separating their names with a semicolon. To avoid conflicts, authority names should use a Java-style naming convention (such as com.example.provider.cartoonprovider). Typically, it's the name of the ContentProvider subclass that implements the provider

There is no default. At least one authority must be specified.

Owner

iBotPeaches commented Apr 2, 2015

Started working on this. Basically on rebuild we check the AndroidManifest.xml for any android:authorities attribute that has an @string reference. We then follow that reference for the literal value and replace it.

Two problems

  1. The string cannot be found.
  2. Sometimes mutliple @string references are in the attribute value. I found this

A list of one or more URI authorities that identify data offered by the content provider. Multiple authorities are listed by separating their names with a semicolon. To avoid conflicts, authority names should use a Java-style naming convention (such as com.example.provider.cartoonprovider). Typically, it's the name of the ContentProvider subclass that implements the provider

There is no default. At least one authority must be specified.

iBotPeaches added a commit that referenced this issue Apr 16, 2015

[WIP] Wires up rewriter of @string references in provider attrs
 - finds all <providers> in manifest
 - finds corresponding @string in res/values/strings.xml
 - does reference replacement w/ literal value
 - fixes #636

iBotPeaches added a commit that referenced this issue Apr 16, 2015

[WIP] Wires up rewriter of @string references in provider attrs
 - finds all <providers> in manifest
 - finds corresponding @string in res/values/strings.xml
 - does reference replacement w/ literal value
 - fixes #636

iBotPeaches added a commit that referenced this issue Apr 16, 2015

[WIP] Wires up rewriter of @string references in provider attrs
 - finds all <providers> in manifest
 - finds corresponding @string in res/values/strings.xml
 - does reference replacement w/ literal value
 - fixes #636

@iBotPeaches iBotPeaches closed this in #911 Apr 19, 2015

@orilentz

This comment has been minimized.

Show comment
Hide comment
@orilentz

orilentz Jul 20, 2016

Hey,
I think I've come across the same problem with the latest version (2.1.1) with the following app (CareZone): https://drive.google.com/file/d/0Bzicg_adEUDMVTgyNWYtbHppUEU/view?usp=sharing

I've had this problem with another app prior to 2.0 which fixed it, so I think it's something else. I've copied the value of the <provider android:authorities string from values/string.xml and then it worked fine.

Thanks.

orilentz commented Jul 20, 2016

Hey,
I think I've come across the same problem with the latest version (2.1.1) with the following app (CareZone): https://drive.google.com/file/d/0Bzicg_adEUDMVTgyNWYtbHppUEU/view?usp=sharing

I've had this problem with another app prior to 2.0 which fixed it, so I think it's something else. I've copied the value of the <provider android:authorities string from values/string.xml and then it worked fine.

Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment