failed extraction: java.lang.RuntimeException: java.lang.NumberFormatException: For input string

jonathan@sandra ~/tmp_backup_onyx $ java -debug -jar abe-all.jar unpack backup.ab backup.tar Exception in thread "main" java.lang.RuntimeException: java.lang.NumberFormatException: For input string: "/addon.d/004075500000000000000000000000001323115710500111445ustar rootroot/addon.d/50-cm.sh01007550000000000000000000000062111270740000012421xustar rootroot50 RHT.security.selinux=u:object_r:system_file:s0" at org.nick.abe.AndroidBackup.extractAsTar(AndroidBackup.java:233) at org.nick.abe.Main.main(Main.java:40) Caused by: java.lang.NumberFormatException: For input string: "/addon.d/004075500000000000000000000000001323115710500111445ustar rootroot/addon.d/50-cm.sh01007550000000000000000000000062111270740000012421xustar rootroot50 RHT.security.selinux=u:object_r:system_file:s0" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Integer.parseInt(Integer.java:569) at java.lang.Integer.parseInt(Integer.java:615) at org.nick.abe.AndroidBackup.extractAsTar(AndroidBackup.java:71) ... 1 more

Am getting something like this output when running the following command. Except my output states 'Caused by: java.lang.NumberFormatException: For input string: "`:

~/work/android-backup-extractor> ./abe unpack backup.ab backup.tar <my password>

The error message indicates parseInt() fails on the version string. The version string comes from the header of the backup.ab file. I'm not tuned into Java's casting rules, so just hard-coded "version = 4" (for my phone running Nougat).

Likewise, parseInt() fails on the given value of compressed (boolean). Hard-coding it to false did the trick. Why it's false I don't know. Perhaps it's referring to a 2nd level of compression?

I have no idea why parseInt() fails with the given values. What could have possibly changed to the backup file format or to the Java implementation of a core language feature? Seems weird. Maybe it has to do with line endings, dos/unix, etc?

Anyway, I'm looking at a valid, decompressed, decrypted backup archive off my phone. So life is good.

Same error, any helps?

look at the header (text lines) of your backup archive and see what's there. If there are space or a different number format/order, maybe your phone is using slightly different format from what the tools expects. Should be easy to adjust if the difference is small.

@nelenkov Thanks, that was a point. The "backup.ab" was failed created so I think the abe does not recognize the file. I tried to backup again and when it asked my mobile phone for encrypted password then now it works, otherwise it won't work for abe :)

Well, the error may be somewhat misleading,

$ ll
total 2336
drwxrwxr-x  3 wceli wceli    4096 feb 17 15:43 ./
drwxr-x--- 53 wceli wceli   32768 feb 17 15:35 ../
-rw-rw-r--  1 wceli wceli       4 feb  6 17:56 1
drwxrwxr-x  3 wceli wceli    4096 feb  4 17:25 a1/
-rw-rw-r--  1 wceli wceli 2327223 nov  9 01:31 abe.jar
-rw-r-----  1 wceli wceli       0 feb 16 18:29 backup2.ab
-rw-r-----  1 wceli wceli     549 feb 17 15:43 backup.ab
-rw-rw-r--  1 wceli wceli    1024 feb 17 15:43 backup.tar

It turns out the backup2.ab is the first one I made, which was 0 bytes.

That's a check to be made before trying to decrypt and extract the file, as this exception leads to no useful understanding

Please check PR #112 in order to add several other ones so as to prevent misleading errors messages or ones that aren't really helpful.

Thanks @71walceli. I've merged that PR, but since the travis build is no longer running, you need to build from master.