When I try to extract apk file through apktool api, related extract process never finishes. Same code works well for Java projects. But when I use it inside Android application through virtual device, extract process never finishes.
Here is the code that I use:
ApkDecoder decoder = new ApkDecoder();
decoder.setApkFile(apkFile);
decoder.setOutDir(outputPath);
decoder.decode();
As I said on IRC.
It won't work. There are 2 dependencies in Apktool that
won't work on Android. Yaml and some java 7 code.
Thats why it works fine on Java, but not in Android environment. Bug for java7 code, and the bug for Yaml.
Yaml is only used for parsing out the apktool.yml file, which is needed for recompile. Java 7 features were introduced for SmaliDebugging and NIO2 aids. If neither are needed, you could recompile the apktool binary without those two. (Of course then missing those features)
It may be useful for you: online version of the apktool is available here: www.javadecompilers.com/apktool
Hope, it would help you to decompile the application without installation of the numerous prerequisites.
Related
Hello!
The goal I have is pretty simple: I want to create an executable .jar file which should be able to bring up a form (made using swing) and write the put-in information into a well structurized plain text file. Due to portability/mobility reasons I will have to run this on an Android phone.
Since Android unfortunately doesn't have native Java support and I am unable to code a real Android application myself, I tried to use a Java emulator. Unfortunately, it appears that a working Java Emulator is hard to find to begin with. JBED instantly crashes on my Medion X701. Netmite's Website, which also seems to offer a .jar to .apk converter, appears to be down. JBlend seems to have installed properly, but I do not know how to work with the program now that it presents me nothing but an empty screen with the caption "0 Java ME Application(s)". On the web, I could not find a proper manual. PhoneME's official website was Java.net, which is no longer active. But during my research, I could find an older Version of PhoneME which seems to be running well.
As a test, I created a simple jar file that shows a maximized JFrame. Unfortunately, it isn't able to run my simple executable Jar file on my phone. The main reason for that should be the aforementioned error, which implies that the interpreter there is probably Java version 1.7, since PhoneME's last release was in 2015. There are more error messages referring to an "unknown source", which I believe originate from the first error. I tried to recompile my jar file using Eclipse, by setting the Compiler compliance level to 1.7 and choosing the jre 1.7 before exporting my project. Unfortunately, this didn't change the error messages I got on PhoneME!
As my last attempt, I created a Startup.class file which does the very same thing as my jar file.
import javax.swing.*;
public class Startup {
public static void main(String[] args) {
JFrame fishForm = new JFrame("Questionnaire");
fishForm.setExtendedState(JFrame.MAXIMIZED_BOTH);
fishForm.setVisible(true);
}
}
I compiled it using the command prompt in order to make sure that it is indeed using java 1.7 as the target. This .class file, which ran fine on my computer, leads me into a different error: "Main class name missing.", followed by multiple lines of usage explaination. The command line PhoneME presents doesn't seem to allow me to post command operations myself, as pressing Enter on the virtual keyboard does nothing.
My Questions
Is it even possible to run a Java application on Android which relies on the GUI libraries of Swing, or am I wasting my time?
Is there a different, up-to-date Java emulator for Android which I could use? Or is there a working jar2apk converter somewhere out there?
If not, then there's probably a reason why Java emulators ceased to exist. Is there a much simpler solution for my initial problem which I am missing?
I'll await your ideas eagerly!
I’m trying to convert a version 401 binary dictionary -- a directory called PersonalizationDictionary.en_US.dict -- to human readable .xml.
The command line utility dicttool_aosp in packages/inputmethods/LatinIME/tools/dicttool can do it like so:
dicttool_aosp makedict -s sourcedict.dict -x output.xml
I’m unable to compile the Android Lollipop version of dicttool, since dicttool has native C++ dependencies that don’t play nice with my Mac. Note this line in the NativeLib.mk file of dictool:
HACK: Temporarily disable host tool build on Mac until the build system is ready for C++11.
I am hoping someone with a compatible setup can compile this utility for me using “make dicttool_aosp” from the root of the AOSP source tree. I've spent the past few days looking for compiled versions of it, and while I’ve found many makedict.jar files online, they are too old to support my newer V401 binary dictionary. The main difference between the V401 and older versions is that a V401 is split up into multiple files with extensions like .bigrams, .freq, .header, whereas the older dicts are contained in a single file.
Thank you, please let me know if I can clarify anything!
I'm working with some java code wich loads an unmanaged dll, just as the following:
public void Foo(){
System.loadLibrary("absolute_path_to_my_dll.dll")
}
It works fine from eclipse or console.
Next step: I'm using IKVM tools to get a managed dll from my java app (ikvmc.exe). Everything works fine and my dll is built perfectly. In fact, I've imported that library in a Test Solution (and I've add all IKVM refereces needed -IKVM.Core.JDK, IKVM.Runtime.JNI, etc-).
Well, here is the problem: when I run C# code the java call to System.loadLibrary(...) fails and I get an "UnsatisfiedLinkError: Can't load absolute_path_to_my_dll.dll". Absolute path is ok and dll is there.
Any help? Thanks in advance.
Edit 1
I'll try to explain more in detail:
Java step
public void Foo(){
System.loadLibrary("absolute_path_to_my_dll.dll")
}
If path is not correct this call gives the "UnsatisfiedLinkError" mentioned above. This is not the case, everything works well. The dll file is a 32 bit one, so I compiled this java project with jre7 x86 (in 64 bit mode loadLibrary call falis, obviously, saying we can't load 32 bit dll in 64 bit AMD machine).
Ikvm step
Now I compile java code in a managed dll wich can be imported in a .net project. First of all I export my java project to a jar file, "myJar.jar". Then i apply ikvmc.exe to generate a managed dll, let's say "myNewDll.dll".
ikvm.exe -target:library -out:"myNewDll.dll" "myJar.jar"
This step works nicely and i get a new dll I can import in my VS project.
C# step
Now I create a new VS tester solution. I add "myNewDll.dll" as reference so I can use it in my C# code. Also, I add IKVM.Core.JDK reference (if not, project can't compile) and configure project in 32 bit mode. Problems start here:
Running this setup gives "IKVM.Runtime.JNI error". I've added that reference.
Running again gives "can't find ikvm-native". As I can't add ikvm-native-win32-x86.dll or ikvm-native-win32-x64.dll as reference I put both of them in output path (bin/Debug).
Next try it gives the "UnsatisfiedLinkError: Can't load xxx.dll".
How can it be possible if that dll is loaded flawlessly in java step?
Annother try
Just before start crying I tried annother way: I created a java main program that only called Foo(). Then I generated an executable file with ikvmc.exe tool and called it in windows console. It gave me the same error, UnsatisfiedLinkError so maybe it's ikvmc.exe problem but I can't understand why.
Any idea?
Edit 2
Good news. It seems I've solved the problem. First of all, I had to add -platform:x86 to ikvmc.exe call (step 2). The dll generated was succesfully imported in my C# project and it works fine if we run in execution mode (NOT debugging). If I try to debug in VS it gives me System.Runtime.InteropServices.SEHException.
Is there any kind of bug related to debugging native code (dll loaded in java code) under native code (that java code loaded in C# using ikvm)?
Is your dll a 32 bit and you run it on a 64 bit platform?
If yes then the problem is that IKVM is platform independent. This means on a 64 bit system it runs 64 bit process.
To solve this you need a 64 bit version of your dll or mark ikvm.exe as 32 bit process.
Adding an option of reference to IKVM.OpenJDK.Core.dll at ikvm's /bin directory will resolve the error.
Maybe the .jar file needs some native DLLs, which was same as Native library location parameter of JAR in Eclipse. If so, find the native DLLs and copy them to de /bin directory of IKVM, and make ikvmc to load them automatically.
That's all what I've found out. Try and see if it would bring some ideas.
Update: The problem was solved with the help of MathWorks. I've published the answer below.
I need to control a program (Zemax) from Matlab. Unfortunately, Zemax only supports DDE for such control, which Matlab does not support any more. It works, but stops working on 64 bit platform after a few (presumable 63) DDE calls.
I wonder if there are working solutions. I could probably program a DLL with correct DDE support and then use DDE in Matlab via this DLL. This is a major effort for me. A more suitable solution would be to use Java DDE methods. Following another post here, I've discovered the JDDE library. However I cannot make it work: Even if I am in the directory with the DLL and JAR files, executing
import pretty-tools.JDDE-2.0.3.*
works fine but calling
a = com.pretty_tools.dde.client.DDEClientConversation()
afterwards (as done here) results in
Undefined variable "com" or class "com.pretty_tools.dde.client.DDEClientConversation".
I have very limited writing privileges on my PC, so I have added the javaclasspath.txt file with the jar/dll location to the directory indicated by prefdir. The file looks like this:
C:\Users\xxxxxxxx\Documents\matlab toolbox\jdde\pretty-tools-JDDE-2.0.3.jar
Calling javaclasspath shows a long listing with the last lines being:
...
C:\Program Files\MATLAB\R2012b\java\jarext\webservices\ws_client_core\mw-service-client-core.jar
C:\Users\kkarapet\Documents\matlab toolbox\jdde\pretty-tools-JDDE-2.0.3.jar
DYNAMIC JAVA PATH
<empty>
So path seems to be set correctly. What am I doing wrong?
With the help of MathWorks support, I've found the answer. Here is how to make JDDE work with Matlab 2012b, without admin privileges:
Download and unpack JDDE files (DLLs and JAR) into some folder. Let's say it's $path-to-jdde$\.
In Matlab, type prefdir. Open the resulting directory and create two files there, javaclasspath.txt and javalibrarypath.txt.
In javaclasspath.txt, add $path-to-jdde$\pretty-tools-JDDE-2.0.3.jar.
In javalibrarypath.txt, add $path-to-jdde$\.
Restart Matlab.
Now call ddeConv = com.pretty_tools.dde.client.DDEClientConversation; and start using the created object as described in JavaDoc. E.g. to connect to Zemax, run Zemax and then in call ddeConv.connect('Zemax', 'abc').
Step 2 above can only be done starting Matlab version R2012b. With an older version, if you have the write rights on the Matlab installation directory, you should be able to replace step 2 by editing the files librarypath.txt and classpath.txt in $MATLABROOT$\toolbox\local. I could not verify it so if you confirm it please let me know in the comment below.
First time post, long time watcher. Can't wait for my classmates to read this (they use the site too)
I am using Eclipse Juno w/ Java SE 1.7
I am having an eclipse problem. It doesn't happen all the time, typically only during File IO. I'm using my debugger perspective in Eclipse to try and trouble shoot some problems (its really a simple program).
UPDATE: Apparently new users are not allowed to upload screen shots. If you could take the time to click on the link to witness my problem I would appreciate it.
Screen Shot Link (not java code):
imgur.com/5IxI3.png
As you can see I am getting an odd thread.class problem. I have even reinstalled java. Could it be something with my code as well then?
Thanks for anyone who offers input or helps in anyway. I do have about a week before this is do so I'm not just looking for free answers, just frustrated. Thanks!
If I understand your question correctly, you need to attach source because Thread is API class.
Download Java source (not binary exe file) from Oracle
Go to eclipse Yourproject --> Properties --> Java Build Path >
Libraries and expand JRE System Library --> jre version--> rt.jar.
Select Source attachment ---> Point to the down loaded source.
Read this tutorial for more info.