Im pretty sure the answer is no, but im using the new IntelliJ EAP version and have a project i worked on a while back which was just written against JDK 1.6 for an applet based application.
However now i could see how it could be useful in an android app that im interested in creating.
Do i now have to re-write all the code/tests again targeting the android sdk or can i just drop in my existing JAR file and only use android for the UI layer.
Its just android seems to make testing WAY harder than it needs to be, and i have alot of existing tests written and working, if it wasnt so hard to just write a quick unit test (standard Junit #Test style) i wouldnt mind porting, however i just dont get the whole instrumentation thing, as i dont need a UI at the moment...
Anyway so back to the point, can i use my existing JDK built code in an android app?
No!
Android uses the "Dalvik" VM from project harmony which uses a different set of bytecodes which are incompatable with the standard Java JVM bytecodes.
This was done both to optimise the VM for opreration on mobile platforms, and, probably more importantly to try and avoid Copyright and patent disputes with Sun and now Oracle.
More info here
However there is a tool called "dx" which can perform the conversion in the dev environment.
Okay, let me clear up your confusion.
Jars are converted to dex Dalvik bytecode during the compiling process thus you can use 3rd party jar libs.
However, in your case because its applet which has a different application lifecycle yes you might have to re-do it to get it to work in android.
As far as testing instrumentation is used on all java mobile development even JavaMe. It basically means that the Junit tests are run in the emulator or device but in android's case you are using android mock objects to test android specific things.
Related
I want to develop an App that makes use of some heavy C++ code.
From what I have understood, I have two choices.
Build the library outside Android Studio and then import it, or put the C++ source code directly in Android Studio to let it build.
If I choose to build the library Outside Android Studio, I can use (OW): Windows or (OL): Linux.
At the same time, I know I can run Android Studio on either (AW): Windows or (AL): Linux.
My question is, can there be any performance difference in the App product running on the phone, depending on a specific approach I would follow (OW+AW/OW+AL/OL+AW/OL+AL/AW/AL)?
To integrate a C++ library into your Android application, from the performance point of view there's absolutely no difference. The difference in all those your mentioned options is the build process of your C++ library (the files with .so extension, i.e. shared library) which will be later integrated into your final .apk executable file. The Android NDK is doing everything at one place, but aside from performance, you should also consider other factors like development and testing capabilities, based on your project and your (and your peers') active skills. Speaking of the performance, it mostly depends on the number of calls between Java and C++ parts - the less data goes back and forth the better for the performance.
I want to make an interface for a C++ complicated algorithm on a tablet environment, the idea of a server running the C++ code isn't applicable.
Can I embed my C++ algorithm in NDK application (for android, can I do the same for iOS?) and make the interface with Android SDK, and then use the NDK app (maybe as a function) in my SDK android app?? is this scenario possible and how hard it's?
I'd prefer the most a solution involving cordova and hybrid approaches.
If there is a simpler approach I'd appreciate any idea.
You probably want to port some code to Android. I do not know if you code has been ever built under Android.
Anyway, first of all you have to locate and manage to build the hello-jni example in the Android NDK. I have it in android-ndk-r9d/samples/hello-jni. After that, you may start to add functions to that project. Forwarding data between Java and C++ is... well... error-prone.
Android comes with two build systems, the old one is ant-based, the new one is gradle. In addition, some guys manage to use 3rd-party build systems for Android.
If your project has never been built under Android, you will have to port it. If it has Windows/Linux/Mac builds, start from a Linux or a Mac one (in the latter case please note that "darwin" contains "win", this may cause bugs in your build script.) You will likely have to borrow some standard functions from where you can find them. In addition, a while ago Android did not support std::string at all...
If your project has been built under Android, you will have to manage to build it yourself and then use the binaries. Alternatively, you might prefer to just use the existing binaries (this will require less effort) and just not care about bugs.
One more possible approach is to find the project that both uses your preferred build system and has an Android build, build that project for Android and remove the contents, thus obtaining an empty project that is built with your build system of choice. I did no do this and I suppose it will not be as easy as it sounds now. (But you will have a chance to become an expert in that build system.) UPD This section applies mostly to projects that come with a 3rd-party build system. Usually such exotic build systems have some specific features, and one needs these features to build successfully. The general rule is that beyond some level of complexity all working systems are modifications of other working systems (and are never created from scratch). (Example: programmers add functionality gradually and testing is done after each addition; they just cannot write all and then test all.) So in the case of a 3rd-party build system it may be reasonable to take some working project using that 3rd-party build system, get the build system working and replace the project source.
In general what you want is possible for both Android and iOS, but there is no general-case solution.
Disambiguation first: question is not about developing or compiling with openjdk code that would be run on dalvik in production. It is about using oracle runtime on android environment.
I'm using java for running small desktop utility application. I have no experience in Android and iOS development and I'm curious to which extent my classic java skills may be transferred to the mobile field.
I've googled couple of methods for running java application on iOS embedding runtime inside the application package. Android has its own partially incompatible and slow java virtual machine. It still is better than nothing, but I'm curious if it is possible to run application on genuine hotspot(openjdk) virtual machine. Android as well as iOS have the ability to run native code. May this ability be exploited to use third-party (non dalvik) jre on android?
I'm not interested on google play market so restrictions from it, if there are any, may not be taken into account.
Rooting is also possible since I'm going to write tools for myself. I would prefer methods that would be easy for installing. Like putting some package files and editing couple of options. And not build my own android distribution like CyanogenMod.
Without rooting the device, I don't think there is a way to do it.
Apparently, see http://openjdk.java.net/projects/mobile/android.html
The instructions are slightly out of date, I managed to do some hacking and get it to build though. Not sure if it runs yet
We want to migrate a huge complex native program to Android system ,running it as a background service accepting command sent from Java Program using JNI along with IPC. However, the Android NDK state following words:
Please note that the NDK does not enable you to develop native-only applications. Android's primary runtime remains the Dalvik virtual machine.
Does that mean we have no way to run an standalone native-only application on Android as a background service? The native code can only exist in the form of library that will be loaded to the virtual machine through JNI?
The NDK itself is only for creating libraries, though if you do some web searching you will find that there are at least two sets of wrapper scripts or instructions for (ab)using its toolchain to make standalone executables linked against android's bionic libc (something you would not get from a non-android arm toolchain).
The google folks do not encourage people to do this. Unfortunately, their vision of android only includes java applications, with optional native libraries in support - it does not include any "stable" means of installing or launching a native executable, in the sense that they warn the methods you might be able to use today may not continue to work in new versions. This is really too bad, as it means giving up a lot of the general-purpose-computer potential of the device.
Well, it can be done. But to be honest i've never tried it using the NDK, but i've managed to create native applications using the toolchains provided with the android source code.
Your phone (incase your talking about phones) should be rooted.
I just purchased an Archos 5 and I'm wondering if it is possible to put a .JAR file on it and use it as an application. I read somewhere that it is possible but saw somewhere else that it wasn't. If it is possible, is there anything I have to do differently? Or do I just run it like I would on my computer?
Android devices run Android applications, not ordinary Java applications, and the ARCHOS 5 is no exception. While Android applications are written in Java, an ordinary Java desktop application uses a different GUI framework than Android offers.
As said by CommonsWare, although Android apps are written in Java you can't actually run Java code(s) on Android devices sinces Android actually has the Dalvick Virtual Machine as compared to the Java Virtual Machine (which runs the Java Bytecode)
If you still plan to use the logic of your jar file and run it on your device, you may reference it in an android app and use the feature(s) from it.
But be awared, that this mostly depends on what your jar file actually does and how it is packed. You may need to, otherwise, repack it to suit if for using in it Android apps.
Bottom line is, however, you can't run the jar files directly on the device!