I am trying to understand what exactly is going on when you install an application (APK) on an Android device. I guess that files are are extracted from the package and copied somewhere on the device.
Are there other steps going on? For example, is the package name of the application written somewhere in the OS like in somekind of registry?
Is the application version number written as well somewhere or the OS reads the xml manifest of the application to know its installed version?
This is related to another question where I suspect that some data was not erased correctly during the uninstallation of a debug app and I am trying to find what that might be.
There will be files/dirs created in various locations, not necessary in all possible locations for every app though, it depends on how the app is configured.
This list is not necessarily complete.
Files/dirs:
/data/data
/data/app
/data/app-asec
/data/app-lib
/data/dalvik-cache
/data/local/tmp
/mnt/asec
/mnt/obb
/mnt/sdcard/Android/obb
/mnt/sdcard/Android/data
Your app will also get an entry in these files:
/data/system/packages.list
/data/system/packages.xml
/data/system/appops.xml
Related
I've got an app that uses Kotlin/Java Files.newDirectoryStream
I got the error message
java.nio.file.AccessDeniedException: /storage/emulated/0/AnkiDroid/collection.media
This folder exists, it is indeed a directory according to File methods. I can access its content if I already know the name of the file I want to access. I.e. asking a webview to show /storage/emulated/0/AnkiDroid/collection.media/image.jpg works. Which also seems to indicate I still have quite some reading permissions here. The only thing that fail in my app is listing the content of the folder which fails.
I can see the folder content through samsung file browser and through adb shell's ls. However, I do not see any permission settings. Actually, I thought that android default file system did not have permissions the way linux has.
Actually, what is even more confusing is that I've two android devices, and this operation fails on one device and work correctly on the second one. I installed it on both device using android studio tool to compile and install from source, so theoretically they are in the same state. They have the same permissions. The folder in both case was created with the same app.
If it helps, the app source code is on https://github.com/ankidroid/Anki-Android/
I have a Java app that runs on a Windows mobile device. At startup the app talks to our server to see if any files need updating and downloads them if they do. If any of the files are dlls they need to be stored in a temp directory and the device is rebooted because they might be currently in use. When the app starts it reads an xml file that lists all of the temp files and where they need to go and copies them into place.
A new requirement has come up that involves also updating the JVM files as part of this process. Since the code that does the copying is run on the JVM there is no way to do it since the files will always be in use. So we are looking at writing something in native code to do this copying process.
Before we start, I was just wondering if anyone knew of an already existing application or technique that does this (someone suggested a registry entry that tells the device to copy files on startup for example). Basically the requirement is to read some sort of configuration file that details the location of the source file and the destination then performs the copy. Any ideas before I reinvent the wheel by writing an app myself?
If your target handsets are handheld barcode scanners (Symbol, Intermec, etc.) they already have a framework in place for this. I don't have all the details, but I know from previous projects that they have a "protected" memory location that allows application to essentially re-configure / copy themselves from hard boots and similar problems. It might be worth seeing if any of that would work on your existing targets.
The scanners use either Windows CE or Windows Mobile.
In the absence of another answer, I have written a simple app to do it and put it in the startup directory. Was pretty easy, just didn't want to reinvent the wheel.
You can also rename your running executable file by the running-application itself. After this you can copy the file into the directory and simply restart your application.
hi
what do i need to do in order to make my java app executable on a mobile (let's say Nokia Symbian for example) . Do all jar files run on mobiles???
is there a certain way of programmings am supposed to use ?? are there specific classes am supposed to use???
Do all jar files run on mobiles???
No
is there a certain way of programmings am supposed to use ??
Yes , you need to use j2me for specific MIDP CLDC platrofm . have a look here
are there specific classes am supposed to use???
You can use the classes available over the platform , alternatively you can also add the external library
Easy, seems like your about to have a stroke. Start reading some articles about getting started on J2ME, try these ones out:
Link 1
microjava.com
forum.nokia.com
You have to know, that depends on the your orientation of you application, not all applications runs in all cell phones, is like in computers, a Windows application won't work on Linux, unles you use a Virtualizer. My point is, start reading all the documentation you you cant, and take it slow.
Some OS's like Symbian Can run java package file i.e. .jar files.
And Android lacks that capability.
Phones with MDIP runs .jad files that is a Java app made using the J2ME API.
Android generate Dalvik Bytecode and run .apk packages on the phone.
I am currently working on desktop software based on java.It's quite a big code base (more than 40 jar files).
I wish to provide an automatic update functionality. The desktop software constantly checks one back end system to see if there are new versions of the jar files available.
The problem now is: How to replace the updated jar files?
If you deploy your application using Java Webstart (JNLP), you get this mechanism almost for free...
From http://mindprod.com/jgloss/javawebstart.html
The key benefit for Java Web Start is automatic update without having to download the entire program every time.
Easiest would be to check for updates on each startup, download the updates and then launch your application. I think this is the way that Java Web Start works (see aioobes answer).
More complex would be to use either the netbeans or eclipse framework for your application. Both are rather complex and you will have to rewrite your application to work with them. This solution supports live updates.
As far as I am aware there is no easy way to update a running application. It is possible to load new versions of a class with a different classloader, but not possible to unload old versions while they are still referenced.
You can make a little server and a launcher which downloads the newest version, replaces the old one, and starts the jar with:
Runtime.getRuntime().exec("java yourjar -jar");
And you terminate the launcher with:
System.exit(1)
You can also serialize down your state (keep it in memory) and then create a new ClassLoader instance pointing to the new .jar files. Then serialize up your state again using this new classloader. You have just changed the underlaying .jars within a executing product.
Please note that you do not need to change the classloader for everything only for the part that is actually using the .jar files. This can be tricky to conclude what parts that are. And you might get nasty linking errors if done wrongly. So..
.. to keep it simple, use WebStart or a preloader that updates the .jars and then starts the main app (basically what WebStart does for you).
A reason for rolling your own, is that you can use your own format for the .jars, encryption, other packing formats etc.
After reading some answers to many auto-update questions, I thought of a solution. This is how I would implement a secure auto-update for a Java/Kotlin jar application.
Assumption: the installer will contain two jars: a launcher and the main application. Any shortcuts created will point to the launcher, but still be the name of the application. The release will contain the main application and the installer.
The launcher is launched first:
First check if an update has already been downloaded as app_name_update.jar
if an update has been downloaded, rename app_name_update.jar to app_name.jar
Start app_name.jar
This part does not have to be in the launcher, but it's preferred as to not slow down the main application: at this point, the launcher should check for an update (e.g. GitHub releases API) and download it to {CWD}/unverified_app_name_update.jar.
Compare the hash of unverified_app_name_update.jar to an online location containing hashes for all published versions. hashes.txt would be an example found in the same github repository. If the software is open-source, GPG signed commits is a must and the launcher should check if the latest update is a verified commit! If its a proprietary application, keep the hashes.txt at a separate URL from the release where your company does not control the infrastructure (e.g. GitHub).
Main app launched:
No need to check for updates unless updates are mandatory, in which case check for update -> if update found, start loading animation "updating" while you can detect that the launcher is still running. Ensure that the launcher has no race condition while loops!
I found ready project to solve automatically updating.
You can update your app, in your cases you can update jars and resources of your desktop app. The idea of the this is next: wrap you app with starter which can control updating and running you app. In details you can find here.
So, I've develop a simple hello world midlet using the Samsung SDK 1.1.2 and I've Packaged the midlet. Now I have two files (a JAR/JAD) combination. How do I get these installed on my phone?
As you can tell from the question, I'm new to phone development. Trying to deploy to a Samsung handset on ATT.
I'm trying to test out the entire development cycle - the emulators work great for writing code but I really need to make sure the Midlet works as expected on the target phone.
Suggest you read up a little on OTA delivery of applications, for background.
You have a number of options for deployment, here's a few.
Connect your handset to a computer via bluetooth, cable, or wifi and copy the JAR file over.
I'm not sure if Samsung support this, but other handset manufacturers certainly provide 'manager' software you can download and install on a computer to do this. If your app relies on user data in the JAD this may not be an idea option, or you could include default data in the JAR.
Place your JAD and JAR file on a web server you have access to, from which they can be downloaded to your phone. You'll need to ensure that the MIME types for the JAD and JAR files are set correctly, they may not be by default. Exactly how you do this depends on your server - here's an example method. (Presumably you have a web/data access service from AT&T.) If all is well you can fetch the JAD file from the phone's browser and the handset will then prompt you to confirm you wish to proceed and download the full JAR and install. Mobile Network Operators have a variable attitude to supporting JAD and JAR access, for example you may find you have to run your server on port 80 or 8080 for it to work in some cases.
Join a service that will host an application for you. One I'm aware of is GetJar. I'm not sure of the details, but doing this will mean you don't have to run your own web server.
Apart from basic deployment you might consider signing your application - a process that basically allows you to assert your 'true' identity to a handset. The advantage of doing this is that signed applications can present fewer network access confirmation dialogs and the like to the handset owner. Also, when the application is being deployed, the user will see a message about unsignedness that might include the word 'untrusted' or similar, and that can be off-putting. (Having said that, some major applications out there have been unsigned.)
Hope that gets you started.
You can certainly copy the jar/jad over via usb or bluetooth, but the Samsung devices I've used will not install a file that's been manually copied over.
Unfortunately the other methods are significantly more work.