Compilation error about android-apktool HOT 8 CLOSED

What is you OS language. (I mean windows 7) ?

Yeah, it's Windows 7 64 bit

same issue. EmailGoogle does not compile even wo changing anything

[deleted comment]

That old of an Apktool probably didn't have a new enough smali. Update to v1.5.0

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

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.

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