Closed YuvrajRaghuvanshiS closed 3 years ago
No need for Java. ab2tar
by IzzySoft seems to work. Also install qpdf
(which is available) for zlib-flate
.
ab2tar won't work with encrypted backups.
Does the backup need to be encrypted? What if we just use a empty password?
You could continue without providing password however on newer versions of android even if you don't provide password it'll be encrypted by default to prevent data theft.
@YuvrajRaghuvanshiS maybe you want to reopen this? I mean its not solved yet, but seems solvable.
Which one of these do you use?
TBH IDK. But that is to build abe.jar right?
i think so(?)
Do I understand you code correctly if I say, you take the abe.jar and work with the commands that come along with it?
you take the abe.jar and work with the commands that come along with it?
I don't follow.
Nevermind, think I figured it out. The sourceforge version is pretty old, and this dragomerlin guy converted Nikolay Elenkovs tool into a runnable jar file. Luckily, he provided a readme in his bundle, which states the whole process and, the most important part, what IDE he used. So, we can use this info to build our own version of Nikolay Elenkovs tool, but with the CURRENT version of the tool, which might fix our bugs. Edit: I'm going to ask @nelenkov if he can make an executable .jar of his most current version.
Should maybe add to title that this concerns the Termux edition
Alright.
https://github.com/nelenkov/android-backup-extractor/releases
@YuvrajRaghuvanshiS try replacing your current .jar with the new version from @nelenkov, maybe it solves the problem
I'm afraid it does not solve the issue.
/sdcard/WA_Test $ java -jar abe.jar unpack nopass.ab nopass.tar
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/nick/abe/Main has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)
/sdcard/WA_Test $ java -version
java version "1.8.0_152"
Java(TM) SE Runtime Environment (build 1.8.0_152-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.152-b16, mixed mode)
I'm testing older releases.
@roberts01 you were saying something about different java for termux? A new maintained version.
I think you need to use a newer Java, try 11 maybe
@roberts01 you were saying something about different java for termux? A new maintained version.
Oh yeah, from DevX or something. They maintain the Java from HaxUs
I don't think issue is with termux this time. @nelenkov is this supposed to be happening?
Yeah the JavaJDK is too old
'class file version 55.0' means Java 11, so you would need that to run it. Alternatively, try building with lower Java version.
found the problem (it's JDK8)
https://github.com/MasterDevX/Termux-Java/issues/44#issue-814532468
I asked @MasterDevX if he can upgrade his Java-Termux-Port to JDK 11 or higher.
Thank you for this.
No problem. Now that we got an (fairly) up to date .jar, I think it makes sense to get an up to date Termux-Java. Just for documentation, which JAVA JDK version do you use for the Desktop version? I'm asking because that should maybe be mentioned in the requirements part of the Readme. Also, you can update the abe.jar that's used for the desktop version with the new release from nelenkov as well I think.
Now that we got an (fairly) up to date .jar, I think it makes sense to get an up to date Termux-Java.
Yes.
Just for documentation, which JAVA JDK version do you use for the Desktop version?
I never really thought about it I just downloaded whatever latest abe.jar was available on sourceforce.net and got it working on first try.
Also, you can update the abe.jar that's used for the desktop version with the new release from nelenkov as well I think.
There is an unsaid rule : If it works don't touch it. I tried with latest version but that unfortunately has very high exception 😂 so I left it as is.
"I never really thought about it I just downloaded whatever latest abe.jar was available on sourceforce.net and got it working on first try."
Yeah but what JDK of Java do you have on your Desktop that works? I mean you must have Java on there for it to work
java version "1.8.0_271" Java(TM) SE Runtime Environment (build 1.8.0_271-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.271-b09, mixed mode)
isn't version 8 like super old?
It may be but it works just fine.
https://github.com/nelenkov/android-backup-extractor/releases
Nelenkov just released a version compatibility with 1.8, try that one.
It did see you there.
Working with https://github.com/nelenkov/android-backup-extractor/releases/tag/20210224105130-e30cc24 Only downside is require additional work on user side to make it work with passwords. However leaving password empty while creating backup gets the work done.
Can continue with Termux afterall.
Yay
You've got some work to do now LoL. I can't work on termux as of now because of university exams.
For Java 8 you will need the unlimited policy jar files too: https://www.oracle.com/java/technologies/javase-jce8-downloads.html
Also for this we can fork masterdevx's project and ship our java with these file by default.
But I don't know how to do that.... :-(
But the good part is, we reduce dependencies on outside sources, because our copy of their Termux-Java is then preserved in this project
But the good part is, we reduce dependencies on outside sources, because our copy of their Termux-Java is then preserved in this project
Kinda, we still need to modify them I'll check how.
But I don't know how to do that.... :-(
Now that is something you can't create an issue about. Can you?😂
Now that is something you can't create an issue about. Can you?😂
Is that a challenge? 😉 Well, guess I'll fork the termux Edition and the java-termux and try around
yes you can do that. A quick heads up https://www.oracle.com/java/technologies/javase-jce8-downloads.html this is required in java 8 and needed to put somewhere in system. You have to figure out to automate this.
maybe I'll just ask the MasterDevX guys
As this issue is now 'resolved', I thinl we can close this one and create a new issue focused on the fork with policy.
Also, could you add the credits part from the Termux readme to the main readme? I think it would just be fair towards @nelenkov and MasterDevX, especially after their help.
maybe I'll just ask the MasterDevX guys
sure. Be sure to mention me so I get notified.
Also, could you add the credits part from the Termux readme to the main readme? I think it would just be fair towards @nelenkov and MasterDevX, especially after their help.
you already did that.
you already did that.
No that's juat on the Termux page, I mean I think it shoulb be on the Master readme as well.
also fyi you still have 2 closed issues pinned...
OH AND DON'T FORGET TO PUT THE JDK NUMBER (8) IN DEPENDENCIES
also fyi you still have 2 closed issues pinned...
pinning is about quick access to most pain in ass problem.
java -jar abe.jar unpack whatsapp.ab whatsapp.tar <pass>
on termux results inException in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58) Caused by: java.lang.RuntimeException: java.util.zip.ZipException: invalid block type at org.nick.abe.AndroidBackup.extractAsTar(AndroidBackup.java:516) at org.nick.abe.Main.main(Main.java:142) ... 5 more Caused by: java.util.zip.ZipException: invalid block type at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164) at java.io.FilterInputStream.read(FilterInputStream.java:107) at org.nick.abe.AndroidBackup.extractAsTar(AndroidBackup.java:474) ... 6 more