We Keep Coding

Android Play Asset Delivery: How to reuse old asset packs?

I have a question about the google play asset delivery system.
Is it possible to reuse asset packs in previous versions of an app without redownloading them on the user end?
Right now, I have one asset pack which is currently in use, and I would like to add a second asset pack with some new images. I made no changes to the first asset pack (and never plan to), but when I go to download the app on internal testing, I get an update download with the size of ~300mb (which is the size of the 1st asset pack + the new one).
I read on the documentation that updating an app would invalidate all previously installed asset packs (which I am guessing causes the play store to download the 1st asset pack again), so I was wondering if there was a way around this, because I would really like to not re-download 300mb of cards when I only made a 13mb addition.
The app had already been installed, and the asset pack had also been fully downloaded and installed, so I was wondering why the update redownloaded it instead of leaving it alone.
I thought that putting the new images in a new asset pack would prevent the 1st pack from being invalidated, but it doesn't seem like that is working.
Basically, the end result I'm looking for is to have a ~15mb update which adds the new images and updates the base code (which is around 2mb total). Is this possible?
Here is the build.gradle of the 1st asset pack in case it helps:
apply plugin: 'com.android.asset-pack'
assetPack{
packName = "cards1_0"
dynamicDelivery {
deliveryType = "on-demand"
}
}
Any help would be greatly appreciated, or if I'm completely wrong on this issue then I'd love to know.

I have spent several hours trying to figure out the same thing.
What the documentation for Google Play Asset Delivery does not specify is that once you upload your bundle, it takes time to generate all the different APKs that users can download.
One of the first APKs that is generated is the one that downloads everything and is available right after you publish your internal update.
My download size was over 300 MB at first and included everything. However once I waited about 15-20 minutes, the download size went down to under 15 MB (as expected) on all my test devices.
So the answer is - wait until Google servers are done processing your bundle and generating delta packages in the background. The time will almost guaranteed vary depending on server load and your original bundle size.

Huawei specific OS flavour creating weird files in my files folder

Basically, I need to save some files in my app. For that, I use the directory returned by getFilesDir() method (like here).
This works fine, but on some devices (I know at least two), files named hw_cached_resid.list or aware_learning_data appear in this folder. Why is this happening and how to avoid this?
UPDATE: Google search revealed nothing, but GutHub code search luckily found one reference of hw_cached_resid.list. Turns out, it's from some (decompiled!) Huawei firmware, more specifically - com.huawei.iaware app.
Huawei's documentation says the Huawei Mate 9 uses something called iAware System, a machine learning platform that learns your usage and preempt changes between apps as well as pre-loading frequently used apps.
(quote from here)

It looks like it's a bug with built-in software of Huawei phones (some temporary files don't get deleted).
Thus, the only way to fix it (without contacting Huawei) - just to check if those files exist and delete them.

Clearing Internal Storage Upon Uninstall

I need to be able to clear the internal storage directory of my application when the user uninstalls my app. How can I do this?
I am in the testing phase of building a security app which requires an ID to be set by an admin when the application is first installed to a user's phone. The ID file cannot be in external storage because I do not want any tampering.
In the event that an administrator gives a user the incorrect ID, they will not be able to fix this by uninstalling the app right now. I have tried uninstalling the app (and clearing cache, etc) to clear the ID data. Upon reinstalling the application, the files still exist, so the ID number cannot be changed.
I am saving the file to the main internal files directory for my application, if that helps.
IDFile = new File(context.getFilesDir(),"ID_Data.txt");

It's not possible to remove the internal storage, an app doesn't get a callback when uninstalled, so there's nothing it can do to wrap things up.
But it should work for external storage: Use getExternalFilesDir() and/or getExternalCacheDir() for your files on external storage ("sdcard"). Those directories are automatically removed when your app is uninstalled.
(source)
You can consider another approach - encrypt the files that the app stores with a key stored only in your code, so decryption will be possible only by the app, and when uninstalled - the remaining files will remain encrypted.
Idea #2
Delete data of older installation, if re-installed
Upon launch of your app, check if there's a preference "first_run", and if it's empty - create one with current time.
If there is already such a preference, you need to check if it's from this installation of from an old one: check the actual install time.
If your preference is smaller than the install time: delete all the old files.

In the manifest specify AutoBackup to "false"
android:allowBackup="false"
https://developer.android.com/guide/topics/data/autobackup.html

Android java app installation under the hood

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

How do I export a jar with an sqlite database inside?

I have a program that I want to distribute, without giving the source code or database used. It's an sqlite database, and doesn't need to be updated. I tried using eclipse fatjar and changing where to look for the jar, but when I run the program, it just creates a blank database file in the same directory as the jar. I just want one file that I can distribute.
From comments deemed relevant:
..include an XML after tested with a TXT file.
I would, but this database is 80,000 lines long, and has 4 columns. It's only going to get bigger too, with updates to the program, not during runtime.
Put it on a server and have a web interface.
I want to avoid using any internet connection really. If someone wants to decompile the jar, whatever I don't care. I just want it to work from double click, and no extra files laying around.

(deployment) ..usability and neatness is important for me
That makes me think that what is really needed for this is a cross-platform installer. The user gets one file and double clicks it, 'follows the prompts' (if any prompts are required) & it extracts the app. ready for use.
It might create multiple files, but this will be largely invisible to the end user. 'Out of site is out of mind'.
I want to avoid using any internet connection..
I recommend you rethink that. What size does the app. come to when Jar'd? A couple of megabytes? That is nothing in this day and age of internet traffic. That's a 2 minute YouTube.
The ratio of devices having internet connections to machines having (for example) CD/DVD drives to load software is also changing. It is coming to a time when more machines capable of running J2SE have internet connections than have drives. I have a desktop PC and a Netbook that can both run J2SE. Both have an internet connection, but only the desktop PC has CD/DVD drives.
If that is the case (getting to my point) look to Java Web Start to deploy the app. and DB. Very user friendly, with good desktop integration.
it's about 50mb, but the problem is not all end users will have access to internet at all times. Distributing the application can be done through the internet, but I don't want to rely on it for accessing the database or loading the application all together.
That is not necessary. JWS caches the application resources locally. It will check the server for updated Jars, but can be configured to allow launch from the cached copy even if there is no internet connection at that moment. The launch file element to configure that would look something like:
<update check="always" policy="prompt-run">

Don't know whether you can do this with a SQLite database, but Derby supports jar: paths: http://db.apache.org/derby/docs/dev/devguide/cdevdvlp17453.html
Alternatively, extract the database from the jar to the filesystem upon launch and point there.

I think you can do the following:
Package your database on the classpath.
When the app loads, copy the database to some temporary directory (like /tmp)
Instruct sqlite to read it from there (by setting the jdbc url)
Add a jvm hook to delete the file when the app gets closed.
That should work like a charm.
Hint:
Use getClass().getResourceAsStream(); to get the reference of the file on the classpath.