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.
Related
I am writing a macro scripting program in Java (JavaFX). I would like to add global keyboard listeners to interact with the program while it is not focused. I have heard of JNativeHook, and it looks useful. My question is, if I decide to use this library, will my code still be portable? Could I still distribute it to others without requiring them to install other things?
You can absolutely include native libraries in a portable app as long as your code can find the DLLs in question and you bundle them with your software. I personally use SIGAR in portable apps and it works fine as long as the relative path remains the same, depending on how you load your DLLs.
******EDIT******
That is of course if you remain within a Windows environment and you are indeed talking about DLL files. If you mean additional JAR files that do not require anything else than java code contained withing JAR files then yes your app will be fully portable, cross-platform too. That is what i love about Java, i once developed a large app on Windows and it ported to Ubuntu with no modifications whatsoever.
You can make your app portable if you don't need any special insulation for a different device uses different platform so in your case the library you asking for JNativeHook need some requirements mentioned here https://github.com/kwhat/jnativehook#software-and-hardware-requirements. You have to give instruction to your user to have these requirements based on the platform he/she works on.
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.
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.
what are the differences between Java library and android library and what advantages/disadvantages has each?
You can include standard Java .jar file libraries in an Android app. They are translated into Dalvik format at .apk build time.
There is an Android Library system which allows the use of shared resources such as layouts and localized strings. As that has more restrictions that regular Java libraries I'd only recommend this method if you actually need to share resources.
http://developer.android.com/guide/developing/projects/projects-eclipse.html
I imagine you meant the android API (or SDK, I can't say) and java API (or SDK). Basically, android is based on java. It is a subset of it, but also adds specific classes and methods to interact with the hardware and the android OS, implement UI, etc.
You can find info about the android architecture here: http://developer.android.com/guide/basics/what-is-android.html
Concerning advantages/disadvantages, well, if you're developing for the android operating system, then is a great advantage to use the android API. If you're developing for PCs, then part of the android API won't be supported, which is what I would call a disadvantage...
In sum, you need to choose whether to use the andoid API or not depending on what will you be coding: will the API be supported by the OS? Is there a JVM for it?
It is very important to know that serialization of classes shared between the two is supported. But they must be located in a package with the same name in both projects.
This is a single question, but with a couple of sub questions. I am planning a Desktop application using Java and I am using NetBeans as the IDE. Questions:
Why are there so many versions of Java? Java, Java SE, Java EE, Java Me
I want the application to store data locally, what is best Java DB or SQLite?
Do I need anything extra to create a setup file for my clients to install the application?
Is it there a Java solution similar to .Net OneClick to keep the clients updated to the latest version of the application?
I have plan to run the application in Windows, but if I have to ported to Mac or Linux how hard can it be?
There are different java libraries for different purposes. Java ME for instance, is designed for cell phones / mobile devices. You'll probably be fine with java SE, unless you need some of the features from EE.
Depending on how complex your data storage is going to be, you may not even need a "database." In java, any object which implements the "serializable" interface can be written directly to a file. So, if you're just trying to store things such as user settings, etc, you can create an object to store them, implement Serialiazable, and write it to disc.
Only if your application links to code libraries which you don't want packaged in the same directory. You can package it as a self-executing JAR from netbeans, it'll be similar in function to an .exe
(Shrug.)
If you are careful not to use operating system specific paths, a self-executing jar will work immediately on any operating system with the JVM installed. There may be a couple other quirks, but Java is built to be extremely portable.
Because you don't really need everything everywhere. For example you don't really need to use GPRS or SMS from you computer, or ORM from you phone. Each edition is targeted to a specific environment. This way you can have a lighter environment for mobiles, and a lot more components for enterprise applications (which you don't really need of a standard application).
I would advise you to use JavaDB (or Derby) but it really depends on you
Not really, you could offer a nice solution to install your application, but it's not necessary.
There is (I don't remember, but other answers will certainly help)
It's really easy, in particular for unix application, the executable creation will basically be a .sh file launched directly (you could of course have a real executable on UNIX, but it's really common and easyier to maintain to have .sh files) (you could also use .bat file on windows, but let's say that's just less common)
I re-read the question and might have not really answered the last point (I was still on .exe creation) so here is a second shot :
5.It's the main goal of java, to be ported everywhere. As long as your code doesn't use specificity of your system (or it's protected with ifs) your code will work everywhere. Of course you have to use the same java edition (edition, not version) and the same libraries or you could have problems.
Why so many Javas? Java, Java SE, Java EE, Java Me
So many environments. The first two are desktop, EE is server side, ME is phones.
..3. Do I need anything extra to create a setup file for my clients to install the application?
Use Java Web Start.
That also covers 4. & 5.
I have no opinion on which is the 'best' DB, but note that for small amounts of data, JWS provides mechanisms where even sand-boxed apps. can store and retrieve information, alternately the installer-desc element can be included in the launch file to install/set up the DB.