I want to run my own java process in android device, I am able to run it with dalvikvm (in .dex format). Because it is normal java process, it is not able to use some android library(android.security.keystore) APIs, even after adding required dependencies(.jar). Now I am thinking to launch my process using Zygote, because zygote is an incomplete version of an Android process–its memory space contains all the core libraries that are needed by any app. So, I wanna try whether it gives access to required libraries for my process. Is it possible to do so? And if yes, can you please provide me some info about how can I launch my own process using zygote.
In short, no, you can't do this if your app is going to be an installable 3rd party app. Zygote is meant for launching Android apps which use the framework.
If you are building a custom platform and bundling this Java process as part of the platform you could possible launch it manually. But, it's out of the norm and you'd have to setup your own classpath and load different framework libs manually. Additionally, the framework libs are generally constructed to be used in the context of an Android framework based process, so you will likely have many problems getting this to work.
Related
I would like to implement a java application (server application) that can download a new version (.jar file) from a given url, and then update itself at runtime.
What is the best way to do this and is it possible?
I guess that the application can download a new .jar file and start it. But how should I do the handover, e.g. know when the new application is started and then exit. Or is there a better way to do this?
The basic structure of a solution is as follows:
There is a main loop responsible for repeatedly loading the latest version of the app (if required) and launching it.
The application does its thing, but periodically checks the download URL. If it detects a new version it exits back to the launcher.
There are a number of ways you could implement this. For example:
The launcher could be a wrapper script or binary application that starts a new JVM to run the application from a JAR file that gets replaced.
The launcher could be a Java application that creates a classloader for the new JAR, loads an entrypoint class and calls some method on it. If you do it this way, you have to watch for classloader storage leaks, but that's not difficult. (You just need to make sure that no objects with classes loaded from the JAR are reachable after you relaunch.)
The advantages of the external wrapper approach are:
you only need one JAR,
you can replace the entire Java app,
any secondary threads created by the app, etc will go away without special shutdown logic, and
you can also deal with recovery from application crashes, etc.
The second approach requires two JARs, but has the following advantages:
the solution is pure Java and portable,
the changeover will be quicker, and
you can more easily retain state across the restart (modulo leakage issues).
The "best" way depends on your specific requirements.
It should also be noted that:
There are security risks with auto-updating. In general, if the server that provides the updates is compromised, or if the mechanisms for providing the updates are susceptible to attack, then auto-updating can lead to a compromise of the client(s).
Pushing a update to a client that cause damage to the client could have legal risks, and risks to your business' reputation.
If you can find a way to avoid reinventing the wheel, that would be good. See the other answers for suggestions.
I am currently developing a JAVA Linux Daemon and also had the need to implement an auto-update mechanism. I wanted to limit my application to one jar file, and came up with a simple solution:
Pack the updater application in the update itself.
Application: When the application detects a newer version it does the following:
Download update (Zipfile)
Extract Application and ApplicationUpdater (all in the zipfile)
Run updater
ApplicationUpdater: When the updater runs it does the following:
Stop the Application (in my case a daemon via init.d)
Copy the downloaded jar file to overwrite current Application
Start the Application
Cleanup.
Hope it helps someone.
I've recently created update4j which is fully compatible with Java 9's module system.
It will seamlessly start the new version without a restart.
This is a known problem and I recommend against reinventing a wheel - don't write your own hack, just use what other people have already done.
Two situations you need to consider:
App needs to be self-updatable and keep running even during update (server app, embedded apps). Go with OSGi: Bundles or Equinox p2.
App is a desktop app and has an installer. There are many installers with update option. Check installers list.
I've written a Java application that can load plugins at runtime and start using them immediately, inspired by a similar mechanism in jEdit. jEdit is open source so you have the option of looking to see how it works.
The solution uses a custom ClassLoader to load files from the jar. Once they're loaded you can invoke some method from the new jar that will act as its main method. Then the tricky part is making sure you get rid of all references to the old code so that it can be garbage collected. I'm not quite an expert on that part, I've made it work but it wasn't easy.
First way: use tomcat and it's deploy facilities.
Second way: to split application on two parts (functional and update) and let update part replace function part.
Third way: In your server appliction just download new version, then old version releases bound port, then old version runs new version (starts process), then old version sends a request on application port to the new version to delete old version, old version terminates and new version deletes old version. Like this:
This isn't necessarily the best way, but it might work for you.
You can write a bootstrap application (ala the World of Warcraft launcher, if you've played WoW). That bootstrap is responsible for checking for updates.
If an update is available, it will offer it to the user, handle the download, installation, etc.
If the application is up to date, it will allow the user to launch the application
Optionally, you can allow the user to launch the application, even if it isn't up to date
This way you don't have to worry about forcing an exit of your application.
If your application is web based, and if it is important that they have an up to date client, then you can also do version checks while the application runs. You can do them at intervals, while performing normal communication with the server (some or all calls), or both.
For a product I recently worked on, we did version checks upon launch (without a boot strapper app, but before the main window appeared), and during calls to the server. When the client was out of date, we relied on the user to quit manually, but forbid any action against the server.
Please note that I don't know if Java can invoke UI code before you bring up your main window. We were using C#/WPF.
If you build your application using Equinox plugins, you can use the P2 Provisioning System to get a ready-made solution to this problem. This will require the server to restart itself after an update.
I see a security problem when downloading a new jar (etc.), e.g., a man in the middle attack. You always have to sign your downloadable update.
On JAX2015, Adam Bien told about using JGit for updating the binaries.
Sadly I could not find any tutorials.
Source in German.
Adam Bien created the updater see here
I forked it here with some javaFX frontend. I am also working on an automatic signing.
Android Instant Apps documentation states in the restricted features section that it can not:
Run unverified software, run arbitrary native code, or load code dynamically other than the code provided by the Instant Apps runtime.
I don't fully understand the above statement but it sounds to me like it may not accept any third party software or any native libraries other than libraries given in SDK/NDK.
Could someone help to elaborate?
This statement:
Prepare your app > Restricted features
Run unverified software, run arbitrary native code, or load code
dynamically other than the code provided by the Instant Apps runtime.
Refers to APKs, libraries, or code that is sideloaded, not packaged within the original apk.
unverified software
In other words, only the signed apk and its contents are allowed.
arbitrary native code
Everything must run from your apk or be provided by the framework.
load code dynamically
Such as use of DexClassLoader to retrieve stuff that’s not already packaged with the apk.
You can use third-party libraries. What you can't do, for example, is download a binary from your server at runtime and run that.
An unofficial answer from an official Google representative was that with Instant Apps, unlike normal apps, there is no technical way to run downloaded code, or load classes dynamically. For normal apps, the restriction is written in Play Store Developer Policy, and is enforced only on Play Store via standard security monitoring procedures.
All of the solutions I found on stackoverflow suggest wrappers to register java application as windows service. My requirement is totally different. Please don't suggest wrappers for the purpose. The question is very simple I have java executable and I want to register it as windows service.
Phyiscal Path
Service Properties
Unfortunately we don't have backup of previous setup that installed it as windows service at the first place. Do I need some setup program or anything like that.
Not necessarily.
It is difficult to advise you on precisely what you need to do without more information on what you actually still have; e.g. an application installer, application JAR files, wrapper scripts, etc. Alternatively, if you told us what the application was, then maybe we could give you some hints on where to get installers, etc.
However, I can tell you definitely that registering java.exe or javaw.exe directly as a Windows Service will not work. These are not the executables for your Java application. Rather they executables for as Java Virtual Machine that will run your (real) Java application.
It is so easy task in case of Visual Studio. I want same support in Eclipse or anything else.
Well Java doesn't work like that. Java compiles to platform independent bytecode files, not to platform-specific native code. Sure, there are third party tools to generate exe's. However, using them is neither necessary, or desirable:
Why is creating an .exe from a java program not recommended?
(And asking for recommendations on what tools to use to do this is off-topic.)
Finally, if you take an arbitrary Java program and turn it into an ".exe" file, it won't necessarily be immediately registerable as a Windows service. This Q&A talks about turning an ".exe" into a Windows Service.
Create Windows service from executable
However, I can't tell you if the advice given there is appropriate for an ".exe" file created from an arbitrary Java app by some unspecified 3rd-part tool.
My recommendation:
If you are starting from scratch, use a Java Service Launcher / Wrapper.
If not, talk with whoever supplied and/or installed this application in the first place.
If you can't find any information about the application and where it came from, or if the vendor has gone out of business ... you need to urgently look for an alternative.
I have developed a JavaFX app and I am going to distribute it as a Native Package to avoid headaches with users having a Java version lower than 7 (and thus, without JavaFX) or having no Java at all.
However, I also want to be able to deliver updates of my application. One solution is for the app to call home (its already communicating with the backend via XMLRPC), fetch a JAR and self-update. I can see potential problems with the actual update process though (would need to build a separate updater program, but how do you update the updater?).
I know about and would love to use Java Web Start. However, I have no idea if this will work with the Native Package thing. If the user already has Java installed, it will disregard my bundled JRE. If he has no Java... well, he can't use Java Web Start, right?
How can I solve this problem in an elegant way that will not have a detrimental effect on user experience? (and preferably won't be very long to implement)
note: I am using e(fx)clipse as build tool.
If he has no Java... well, he can't use Java Web Start, right?
True, but as mentioned in the JWS tag Wiki:
Java Rich Internet Applications Deployment Advice. Describes the deployJava.js
script designed to ensure a suitable minimum version of Java is installed before
providing a link to a
JWS app.
or launching an
applet.
Note that JWS also offers fine grained versioning as detailed in Java Web Start - Runtime Versioning.
Saying that, JWS can allow you to support earlier systems by adding the JavaFX 2 API selectively to those earlier systems. That is achieved using a version based resources section in the launch file.
So, JWS combined with deployJava.js would actually be 'the alternative' to the Native Package that page discusses.
I currently have a Java application running on Google App Engine, but I want to add the features that the Python module's SearchableModel provides (for search features of course). Is it possible to run python code in the same project as Java code, just under a different version? If not, could they be two separate apps (current Java app and a new Python-based search app) running against a single datastore, but I don't think that is possible.
It is possible to run Python and Java applications on different versions.
From:
Last but not least: remember that you can have different version of your app (using the same datastore) some of which are implemented with the Python runtime, some with the Java runtime, and you can access versions that differ from the "default/active" one with explicit URLs.
Yes, you can write your app in Java and also have a separate version of your app running Python.
However, if the core of your app is already implemented in Java, you might want to look at the SearchableModel Python code, then consider implementing something to accomplish your goal in Java. The gist is that you could simply build your list of search-words and store them in a multivalued property (ie a list).
You should also check out the Building Scalable, Complex Apps on App Engine video. Depending on your use-case, moving the search-word list to an 'Index Relation Entity' might offer further improvements.