ERROR getting 'android:label' attribute: attribute is not a string value

[GoogleCodeExporter]

What steps will reproduce the problem?

Using apktool v1.4.3 to decode the Phone.apk and SystemUI.apk packages from 
Jelly Bean (Android v4.1.1).

1. Download the yakju (maguro) factory image from Google.
https://developers.google.com/android/nexus/images

2. Unpack the system.img from the factory image ZIP, convert it to a standard 
ext4 disk image file, extract Phone.apk, SystemUI.apk and framework-res.apk 
packages from it.

3. Install the framework-res.apk with apktool's "if" command.

4. Decode the packages with apktool.

What is the expected output? What do you see instead?

For Phone.apk I run:
apktool d Phone.apk Phone

I get the following output:

I: Loading resource table...
W: Skipping "android" package group
I: Loaded.
I: Loading resource table from file: /Users/muller/apktool/framework/1.apk
I: Loaded.
I: Decoding file-resources...
I: Decoding values*/* XMLs...
I: Done.
I: Copying assets and libs...
ERROR getting 'android:label' attribute: attribute is not a string value

For SystemUI.apk I run:
apktool d SystemUI.apk SystemUI

And I get:

Processing ./SystemUI.apk ...
I: Loading resource table...
I: Loaded.
I: Loading resource table from file: /Users/muller/apktool/framework/1.apk
I: Loaded.
I: Decoding file-resources...
I: Decoding values*/* XMLs...
I: Done.
I: Copying assets and libs...
W/ResourceType(19884): No known package when getting value for resource number 
0x01080448
ERROR getting 'android:icon' attribute: attribute is not a string value

What version of the product are you using? On what operating system?

v1.4.3, Mac OS X 10.6.8
And I use aapt v0.2.

Please provide any additional information below.

I've uploaded all the files mentioned above packed into a ZIP (Phone.apk, 
SystemUI.apk, aapt, apktool, apktool.jar, framework-res.apk) here:
http://ul.to/blohebhm

Original issue reported on code.google.com by zsolt.mu...@gmail.com on 14 Oct 2012 at 5:33

[GoogleCodeExporter]

Sorry ... I forgot: the expected output is not to see any errors in the output 
of apktool. At least I guess "ERROR" messages are somehow bad.

And since these are the original APKs from Google's Android releases, they 
should be OK/valid/proper, not? Or does Google ship "inproper" packages? :-o

Original comment by zsolt.mu...@gmail.com on 14 Oct 2012 at 5:36

[GoogleCodeExporter]

I've tested apktool v1.5.0 (by iBotPeaches) too and it's even worse a little 
bit. For Phone.apk I got the same error message. For SystemUI.apk I got four 
ResourceType warnings instead of the single warning that I got with apktool 
v1.4.3.

Original comment by zsolt.mu...@gmail.com on 14 Oct 2012 at 6:47

[GoogleCodeExporter]

I have duplicated. Will look into it. Thanks for the APKs.

Original comment by connor.tumbleson on 15 Nov 2012 at 12:43

• Changed state: Accepted

[GoogleCodeExporter]

Thanks. Let me know if you need any further input or testing.

Original comment by zsolt.mu...@gmail.com on 15 Nov 2012 at 12:55

[GoogleCodeExporter]

The good thing about reproducing this bug with official Android apps might be 
that the original sources for these apps is available too.

Eg. the Phone app is here:
https://android.googlesource.com/platform/packages/apps/Phone/

It might help to see where a given resource came from, etc.

Original comment by zsolt.mu...@gmail.com on 15 Nov 2012 at 12:58

[GoogleCodeExporter]

Problem is the line(s)

    <string name="throttle_time_frame_subtext">"%1$d % des Zyklus sind verstrichen. 
Der nächste Zeitraum beginnt in %2$d Tagen (%3$s)."</string>

Seems that second % isn't escaped which either is the problem during 
decompilation or something else. Will have to look at raw source instead of 
decompiled source to be sure.

Original comment by connor.tumbleson on 17 Nov 2012 at 6:18

[GoogleCodeExporter]

What do you mean by escaped? Is the first "%" escaped? :-o

Does a "%" have to be escaped at all? It's an XML, right? I admit that I don't 
know all the rules from memory ... but I thought that the only characters that 
absolutely have to be escaped in the text node of an XML element are "&" (since 
it usually starts character entities) and "<" (which usually starts tags).

It seems to me that the Wikipedia description confirms this as well:
https://en.wikipedia.org/wiki/XML#Escaping

Of course it's not the official specification, but hopefully/probably close 
enough and it's a lot more readable/usable. :-)

When I search for "%" in the article, only this pops up:
"The element tags are case-sensitive; the beginning and end tags must match 
exactly. Tag names cannot contain any of the characters 
!"#$%&'()*+,/;<=>?@[\]^`{|}~, nor a space character, and cannot start with -, 
., or a numeric digit."

So "%" seems to be a totally valid character in the context where apktool finds 
a problem.

Original comment by zsolt.mu...@gmail.com on 17 Nov 2012 at 7:49

[GoogleCodeExporter]

Its a valid character but it has special meaning in Android for formatting them 
w/ text.

See http://developer.android.com/guide/topics/resources/string-resource.html 
Formatting Strings. So it sees a % without a s (string) / d (decimal) or 
positional tag next to it, it panics. 

So the options are to inject formatted="false" or to allow Apktool to fix it at 
runtime by escaping it literally.

Original comment by connor.tumbleson on 17 Nov 2012 at 2:44

[GoogleCodeExporter]

Thanks for the explanation. A little later (while vacuum cleaning the house :-) 
) I realized by myself that something like this must have been it.

I guess the latter approach is the more appropriate, since the former would 
probably lead to different functionality (in case the apktool-decoded source is 
put together into an APK again).

Or you could just ignore such errors both during decoding and building of an 
APK.

The question is what is the goal of apktool's decoding and building processes? 
Is it to produce a source/APK that is as close to the original as possible, or 
is it to create the "best possible version" (most valid) of the source/APK from 
the given input?

Original comment by zsolt.mu...@gmail.com on 18 Nov 2012 at 8:37

[GoogleCodeExporter]

I believe we fixed this in wip-2.0. If there are errors, its probably just old 
aapt vs more agressive aapt.

Which Apktool decompiles/disassembles apk(s). It doesn't "convert apks to newer 
aapt standards".

Original comment by connor.tumbleson on 12 May 2013 at 3:37

• Changed state: Fixed

[GoogleCodeExporter]

Good news. :-) Can I test it somehow?

I tried by checking out wip-2.0 and compiling it, but got tons of errors.

Eg.
/Users/me/Android/android-apktool/brut.apktool/apktool-lib/src/main/java/brut/an
drolib/Androlib.java:549: illegal start of type
                Map<String, String> zip_properties = new HashMap<>();
                                                                 ^
/Users/me/Android/android-apktool/brut.apktool/apktool-lib/src/main/java/brut/an
drolib/Androlib.java:555: '{' expected
                try(FileSystem zipFS = FileSystems.newFileSystem(apkFileSystem, zip_properties)) {
                   ^
/Users/me/Android/android-apktool/brut.apktool/apktool-lib/src/main/java/brut/an
drolib/Androlib.java:555: ')' expected
                try(FileSystem zipFS = FileSystems.newFileSystem(apkFileSystem, zip_properties)) {
                              ^
/Users/me/Android/android-apktool/brut.apktool/apktool-lib/src/main/java/brut/an
drolib/Androlib.java:555: ';' expected
                try(FileSystem zipFS = FileSystems.newFileSystem(apkFileSystem, zip_properties)) {
                                                                                               ^

Probably it's in a transitional state at the moment.

Original comment by zsolt.mu...@gmail.com on 12 May 2013 at 7:25

[GoogleCodeExporter]

We haven't updated wiki(s) but JDK 1.7 is needed now. We use Java7 elements so 
we had to move up the version required.

Original comment by connor.tumbleson on 12 May 2013 at 8:28

[GoogleCodeExporter]

Thanks, with JDK 1.7 it compiled successfully.
On the other hand: I've now tested the problem with apktool v1.5.2 and got no 
warnings or errors. So it seems that this got fixed a long time ago.

Original comment by zsolt.mu...@gmail.com on 12 May 2013 at 10:50