Develop Reference

Android - how to remove Expansion files?

I followed this guide for download expansion files. When I checked it, the download worked fine, but when I wanted to uninstall the application from the phone the files stayed there.
How can I cause the files to be deleted with the app?

Downloaded expansion file(s) will be stored in your shared-storage folder (usually this is your sd-card). There is no code that can be triggered when uninstalling your application. This unfortunately means that you cannot remove expansion files from code when uninstalling the application.
However I did find out that on my Nexus 4 but also on a Samsung Galaxy S the expansion file is automatically deleted from the shared-storage folder when uninstalling the application. I tested this using an application that is in the play store.
When the expansion file is not deleted automatically then the only way to get rid of your expansion files after an uninstall would be to manually delete the file(s) from your shared-storage folder. An end-user can be instructed to remove the expansion file manually by letting him/her attach the device to the computer and navigate to:
<shared-storage>/Android/obb
In this folder you should see one or more folders with package names. Pick the folder that will contain your expansion file and delete the package folder or the expansion file depending on what you wish to be deleted. Be aware that deleting the wrong package can affect different apps. So use manual deletion with caution!
Some reasons why an expansion can't be deleted by end-user:
End-user doesn't have drivers for the device so it can't see what's on the shared-storage
End-user uninstalled the application and the expansion file is already gone

Store your app files in the Applications private directory.
This can be obtained with getFilesDir()
When your application is uninstalled, all files in this directory get deleted.

Can an APK be repacked after a minor text edit?

I'm creating a software that will guide the user through a few steps, to publish an android application (APK file).
The way I am doing this, is that the APK file is already compiled, and all I need to do is replace an XML file in the package, and that will change the behaviour of the application. My big problem now, is that unpacking the apk file, and doing any tiny text edit, and then packing it again, breaks the signature and prevents the application from running on any device, giving a message that the signature is incorrect.
How can I solve this? I want to safely open the APK, write something in a text file, and close it again. Note that this operation will be done on the user's computer (after he purchases our application) so we're look for a command-line tool with no special requirements like JDK.
Any help?

Ok I reached the best "tested" solution - I'm posting it here to save other developers hours of googling. The only downside is that I will require the customer to install JDK on his machine, unfortunately. The reason is because I did not find any apk-signing tool that works purely on windows, without relying on JDK.
I have my android application created using Air, so this makes things easy for me - all of the air files are treated as resource assets. So have your APK archive file ready.
Once you have your modifications ready, put them inside a temporary folder named "assets". You will use the 7-zip command line tool (free: http://sourceforge.net/projects/sevenzip/) to update the contents of your apk. To have it working with your apk you will have to rename your apk's extension to zip - don't worry, you'll change it back later.
Now from a .bat file (or directly in the command prompt) from the location containing both your apk file (zip extensioned) and your assets folder, you'll call: 7za u APK-file.zip assets
Now your apk file is updated. Rename it back to .apk extension
Now you'll use the signAPK tool from here https://code.google.com/p/signapk/ and note that this is the only step requiring JDK installed. It also assumes that you have your key files ready (replace the dummy ones included in the package). Extract the file contents and call: java -jar signapk.jar key.x509.pem key.pk8 [android_app].apk [signed_android_app].apk
At the very end, you may find your signed apk file size drammatically increased. So you need to use the android's zipAlign tool: (darn, can't post the link since new users can only post a maximum of two hyperlinks)
you will be calling the command: zipAlign -c 4 [signed_android_app].apk
And voila! That's the route I'm taking.
If someone finds a way to do the signing process without relying on JDK (assuming the key files are ready) please share.

How can I solve this?
You don't. If you modify an APK file, by any means, it must be re-signed.

Android apk files must be signed. That signature proves that the contents of the apk have NOT BEEN MODIFIED from what was initially published. (Which is exactly what you are doing.) The signature at the same time, also proves who the author is.
So in a normal signed apk file:
You know who the author is. (Even if it's not something you as a human can understand.)
You know the contents were put there by the author, and not modified since.
This is a key security measure built into Android, is there for very good reason, and cannot be overcome. It prevents things like viruses from being embedded inside innocent apk files.

Where did the code in apk file go after installed from Market?

This is a very interesting thing. I have an APK file, com.company.app.apk. When installed to an emulator by using Eclipse, by using the following code to get the apk's file name:
String fileName = activity.getPackageManager().getApplicationInfo(
activity.getPackageName(), PackageManager.GET_META_DATA).publicSourceDir;
I get a pathname like this com.company.app-1.apk. The file size is the same as the apk file I built.
Now when I publish this app to Market, and install it to a real device (Android 2.3), the same code returned a pathname like this: com.company.app-2.zip. Note that the file extension has changed to .zip and, most importantly, the file size is significantly smaller than the original size.
Now if I transfer these two files to my PC and use WinZip to open them, I found one really interesting thing:
The one installed on emulator by Eclipse has exactly the same stuff as I expected. Namely: the code ('com' folder), the resource ('res' folder), the signature ('META-INF' folder), the assets ('assets' folder), and the manifest file (AndroidManifest.xml). However, the one installed on a real device by Market has only two parts: the resource, and the manifest file.
Question: I think when installed from Market, the .apk file is split into two (or more) files. One file is pointed to by ApplicationInfo.publicSourceDir, which contains only the resource. How can I get the pathname to the other file(s)?
ADDED: I have two versions of the same app, one is paid using Google's Vendor Licensing Service, the other is free. The above mentioned phenomenon happens only to the paid version. Why?
Correction: When I said the 'com' folder exists in the installed apk file in the first case, I should be more clear. The code per se, the *.java files, are not in the 'com' folder. As a matter of fact, the 'com' folder contains only a few garbage files that were inadvertently left there during the build process. If not for those garbage files, I don't think the 'com' folder would be there in the first place.

I think you are not right. The market works in the following way: you choose an application and push a button to install it. After that market sends the intent to gtalk service to install the application. This service downloads apk file that you've uploaded to the market and when finishes it installs this apk. Just during the installation can some changes happen. It seems to me that from the application during the installation classes.dex file is extracted and from this file optimized dex (.odex) is produced and put in the separate directory. That's why you see the difference in the files.

Ok, here is what I've found out, in case this helps someone out there:
When Market installs the free version of my app, the apk file is installed to /data/app/com.company.app.apk, the file content is exactly the same as I built it, same file size, same everything.
For the paid version that uses Market Vendor Licensing, the apk file itself is installed to /data/app-private/com.company.app.apk. This is the same file as I released. However, the resources are extracted and installed to another file /data/app/com.company.app.zip, note the file extension. This zip file contains only resources, so it's significantly smaller. But the .apk file in /data/app-private has everything, so the file size is the same as I built it.
ApplicationInfo.publicSourceDir always points to the file in /data/app, so it's /data/app/com.company.app.zip in the paid version's case, and /data/app/com.company.app.apk for the free version. For the paid version, I obtained the pathname from publicSourceDir, then replace.app with app-private, and replace .zip with .apk to get the original file.
If I install the apk directly to an emulator, then there is only one file and is always installed under /data/app.

Browse .apk structure on android phone and compute file digest

How the .apk installation process works on device? Is the .apk file just copied to some place and kind of installer application extracts the application information, register somehow the application to environment, extract also the icon and put it on the application launch screen? Or the .apk content is extracted and files are copied to various folders and the .apk file itself is deleted?
I am asking to understand if there is any possibility on device to browse the .apk file structure and its content and access in read-only mode directly the assets, res folders, AndroidManifest.xml, the dex file and also used libraries (.jar or .so)?
The reason I am asking is that I am looking for possibility to read into memory .dex, .jar or .so files like arbitrary binary files (e.g. by using the File class) for the purpose of computing a message digest from its content (i.e. using md5 or other hash method)...
BR
STeN

The APK is copied onto the device, usually into the /system/app directory. The APK is not extracted or unzipped until it is used, so if you want to probe the files you'll need to do the decompression and extraction yourself.

store file tree in .apk

How can I store a normal tree of files inside an Android .apk without all the weirdness of the Ressource or Asset concepts? It seems I have to do some akward thing to use Files from current path like any non-Android Java application do?

"use Files from current path" and "store... inside an Android .apk file" have nothing to do with each other.
Since, statistically speaking, you are likely familiar with Windows, let's draw some analogies.
"store... inside an Android .apk file" on Windows would be "store... inside a Windows .exe file". This is reasonably uncommon on Windows, at least the last I checked.
"use Files from current path" on Windows would refer to files that perhaps exist in the app's Program Files directory or the equivalent. On Android, this works fairly conventionally -- use getFilesDir() and Java file I/O.
What exists in Windows and does not exist in Android is the concept of packaging files to be installed at install time via an installer package, such as a .msi file.
Since you declined to tell us what the "normal tree of files" is and why you think it should be "inside an Android .apk", it is impossible to give you advice on how to avoid whatever "weirdness" you think exist in the "Ressource [sic] or Asset concepts". All I can tell you is that the equivalent on other OSes to bake files into the executable would likely be similarly "weird".

Okay, I haven't tested this, but a solution could be to add extra files to the APK before signing. You could automate this from the command line:
$ ant release
$ zip -r bin/MyApp-unsigned.apk <custom_folder>
$ jarsigner -verbose -keystore <keystore> -storepass <password> bin/MyApp-unsigned.apk <alias>
$ zipalign -v 4 bin/MyApp-unsigned.apk bin/MyApp-signed.apk
And then, in your activity, open the APK with ZipFile to access your custom folder:
ZipFile apk = new ZipFile(getApplicationInfo().sourceDir);
I'm not sure how the Android Market would react to this non-standard APK though.

With assets you can have a file tree in an APK, which can be accessed by using the AssetManager returned by getAssets().
The whole point of this mechanism is saving space. The files are not extracted to the file system when the app gets installed. When you read the content of an asset, it is uncompressed (unzipped) on the fly from the APK. It does make sense. Saving space is important on Android devices.
But nothing forbids you to extract the assets tree into the file system when your application is first launched, if you need that.

One approach that might work for you is to open the APK using ZipFile and ZipEntry, as this gives you access very similar to a conventional read-only directory structure.
Alternatively, you may be able to use getResourceAsStream to work with a traditional file structure - you might find this bug report useful if you go with this approach - it shows some perils of working with getResourceAsStream on android.
I should add that you shouldn't think of an APK as something gets extracted - files inside the APK are not on the filesystem, they're like resources inside a JAR file in a J2ME or J2SE environment (or the WAR/EAR for J2EE).
Hope this helps,
Phil Lello