Closed GoogleCodeExporter closed 9 years ago
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
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
I have duplicated. Will look into it. Thanks for the APKs.
Original comment by connor.tumbleson
on 15 Nov 2012 at 12:43
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
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
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
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
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
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
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
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
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
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
Original issue reported on code.google.com by
zsolt.mu...@gmail.com
on 14 Oct 2012 at 5:33