search

asmjmp0 / appdbg

make it possible to run method of android-app with original Java Virtual Machine.
Apache License 2.0
230 stars 50 forks source link

the following may interest you (we're using art to run dex files, though I wonder how well your thing would compare) #4

Open Mis012 opened 1 week ago

Mis012 commented 1 week ago

https://gitlab.com/android_translation_layer/android_translation_layer

asmjmp0 commented 1 week ago

https://gitlab.com/android_translation_layer/android_translation_layer

In my project, I use dex2jar to convert dex files into jar files that can be executed by the Java Virtual Machine. The benefit of doing this is to eliminate compatibility issues with dex files, as jar files are platform-independent. Additionally, nowadays, the execution speed of Java programs may not necessarily be slower than native execution, and you can directly use various third-party Java libraries. By simply implementing JNI functions (regardless of the implementation method), the program can run on various operating systems. Therefore, as long as the results of dex2jar are correct, this implementation approach can be considered a good method.

Mis012 commented 1 week ago

I have experimented with running on standard JVM: https://gitlab.com/android_translation_layer/android_translation_layer/-/tree/unsupported-experiment-non-art-jvm

The issue with dex2jar is that it absolutely does not "just work", at least in my experience.

art is supposed to compile for Windows and MacOS, and with our patches it's basically equivalent to a jvm, except it can run dex files. Compatibility is certainly better than dex2jar, because art is what AOSP uses and presumably the app worked fine on AOSP. Using third party java libraries is still an option, they just need to be run through dx. We have at one point used ARSCLib for example, though we have moved away from that since it was incredibly slow and we instead added a C ABI to libandroidfw, which is also intended to compile for Linux/MacOS/Windows because it's used by aapt.

I just don't bother supporting Windows/MacOS in my code because ultimately any app that uses native parts will only run on Linux, and it doesn't seem worth it to include codepaths for Windows and MacOS when only apps which are fully written in java with no native parts will work. At that point, using a VM makes more sense, either with AOSP or with linux + my project. (On Windows, WSA and WSL exist and are able to run GUI apps afaik, and I doubt any windows user would care for a "cleaner" solution)

asmjmp0 commented 1 week ago

If the art virtual machine could be compiled independently, using the independently compiled art virtual machine as the runtime for dex files would be a good solution. As far as I know, the art virtual machine may include special classes and methods not found in the standard JVM, which could also lead to compatibility issues. Additionally, Android uses the dx tool to ensure that third-party libraries can run in the Android environment in order to leverage the Java ecosystem.

I also believe that dex files and jar files, as executable files, are Turing equivalent, especially since they are both compiled from the Java language. If there are certain areas where dex2jar fails to convert correctly, efforts can be made to fix it, or to explore implementing features of the art virtual machine.

However, at present, it seems that compiling the art virtual machine independently as a runtime solution may be more cost-effective and easier to implement.