Closed GoogleCodeExporter closed 9 years ago
What is you OS language. (I mean windows 7) ?
Original comment by vazgec
on 30 Nov 2011 at 6:11
Yeah, it's Windows 7 64 bit
Original comment by jakerand...@gmail.com
on 30 Nov 2011 at 1:08
same issue. EmailGoogle does not compile even wo changing anything
Original comment by ralfnies...@gmail.com
on 9 Dec 2011 at 1:46
[deleted comment]
That old of an Apktool probably didn't have a new enough smali. Update to v1.5.0
Original comment by connor.tumbleson
on 17 Nov 2012 at 5:27
I think a newer version of smali/baksmali cannot fix this bug, which seems to
me the same as issue 187.
I run into the same problem by using apktool v1.4.1 embedded in xdaAutoTool -
I'm not sure if I really need that old version of apktool for compatibility
with Froyo, but since I used it to decode the app I'm playing with, I'd prefer
to use it for recompiling as well, and as a fallback option just in case of
problems with newer versions.
I think I've found the error in brut.androlib.mod.SmaliMod.assembleSmaliFile
static method, and I can read it in its source code from master branch, both
from this site browsing option and after checking out the whole project (master
branch - I'm using NetBeans 7.3.1 embedded git support with gradle plugin).
Anyway, my local copy misses some files - smaliFlexLexer.java for instance -
and I can't find them in browsing facility as well, so I can't test any
correction, and I'm not able to ensure the problem is still there for real,
given it rises from smaliFlexLexer interface (in the meaning of an API), which
I deem in lack of robustness from this perspective - I'll give a look to the
latest sources, and perhaps I'll file a request for enhancement to that project
as well, in case. Furthermore, I can't find sources for apktool 1.4.1, I'd wish
to correct and compile them as well, as I said above, but this is a different
issue (anyway, is there any chance to get them?)
But let's come to the problem:
in the aforementioned method, the following lines should cause the issue:
-------- code start ---------
LexerErrorInterface lexer;
InputStreamReader reader = new InputStreamReader(smaliStream, "UTF-8");
lexer = new smaliFlexLexer(reader);
tokens = new CommonTokenStream((TokenSource) lexer);
-------- code end ---------
Notice the difference with the analogous code in org.jf.smali.main.java, method
assembleSmaliFile, that should be (or do) the same in about all smali versions
used by apktool:
-------- code start ---------
lexer = new smaliFlexLexer(reader);
((smaliFlexLexer)lexer).setSourceFile(smaliFile); // <-- here!!!
tokens = new CommonTokenStream((TokenSource)lexer);
-------- code end ---------
In both cases, an InputStreamReader is built around a FileInputStream and
passed to lexer's constructor, but SmaliMod class misses to set the File object
being accessed by the mean of that reader, whereas "original" smali
implementation does it explicitely, since it's needed by smaliFlexLexer class.
It seems to me that smaliFlexLexer objects doesn't need infos about the file
beign assembled, it should work with any kind of inputs, but in a few special
cases some lucky people hits every once...
Let's have a closer look to the exception stack trace:
-------- code start ---------
Exception in thread "main" java.lang.NullPointerException
at org.jf.util.PathUtil.getRelativeFile(PathUtil.java:44)
at org.jf.smali.smaliFlexLexer.getSourceName(smaliFlexLexer.java:2569)
at org.antlr.runtime.CommonTokenStream.getSourceName(CommonTokenStream.j
ava:345)
at org.antlr.runtime.Parser.getSourceName(Parser.java:88)
at org.jf.smali.smaliParser.getErrorHeader(smaliParser.java:324)
at org.antlr.runtime.BaseRecognizer.displayRecognitionError(BaseRecogniz
er.java:192)
at org.antlr.runtime.BaseRecognizer.reportError(BaseRecognizer.java:186)
at org.antlr.runtime.BaseRecognizer.recoverFromMismatchedToken(BaseRecog
nizer.java:606)
at org.antlr.runtime.BaseRecognizer.match(BaseRecognizer.java:115
[...]
-------- code end ---------
At some point, a sort of "recoverable error" happens, and the program tries to
log it while recovering - other scenarios could trigger such behaviour. Thus,
some infos are retrieved on the source smali file for logging: in the end
smaliFlexLexer.getSourceName method is invoked, which in turn calls
org.jf.util.PathUtil.getRelativeFile, which is a static method:
-------- code start ---------
public static File getRelativeFile(File baseFile, File fileToRelativize) throws
IOException {
if (baseFile.isFile()) {
baseFile = baseFile.getParentFile();
}
return new File(getRelativeFileInternal(baseFile.getCanonicalFile(), fileToRelativize.getCanonicalFile()));
}
-------- code end ---------
Here's where the NullPointerException is generated, because it tries and call a
method on a null object.
Regards
Original comment by alex.sub...@gmail.com
on 5 Sep 2013 at 2:37
Lets just back up a bit and cover the basics.
v1.4.1 is outdated, not supported, at all.
v1.5.x branch of apktool will not receive any more updates or anything in the
1.x branch as well. So if you are looking at code in the "master" branch now,
its about 8 months old.
All work is on the 2.x branch (wip-2.0), which will be merged into master when
ready. I'd rather have you duplicate this problem on the current source,
instead of comparing old versions of smali/apktool together.
Smali 2.0 branch is called dexlib_resign, Apktool's 2.0 branch is called
wip-2.0.
Original comment by connor.tumbleson
on 5 Sep 2013 at 2:45
Uh, I don't know why I missed out wip-* stuff in source browser... also had
problems to check-out non-master branches at the beginning...
For what I can tell, this problem should be gone: SmaliMod.assembleSmaliFile
has got a different interface, is called by SmaliBuilder passing a File
reference instead of an InputStream and initializes a smaliFlexLexer instance
correctly. In turn, smaliFlexLexer (generated) file seems to be inproved with a
safer getSourceName method, returning an empty string if no file name is
available - I think there is still room for safety improvements, such as a
constructor with File and charset arguments, or a setSourceFile method that can
run only once, but perhaps this isn't the right place for that...
Regards
Original comment by alex.sub...@gmail.com
on 6 Sep 2013 at 5:15
Original issue reported on code.google.com by
jakerand...@gmail.com
on 29 Nov 2011 at 9:12