Assume that "app-v1.apk" has assets/a.png. user install this app.
then we delete "a.png" file from assets and generate "app-v2.apk" file.
Is there any way to access the "assets/a.png" file when the user updates the app?
As far as I understand your question, what you are trying to say is
can we access assets of previous build that are not present in current build?
As far as my knowledge goes, The answer is NO. Play store manages updates so when you upload the new apk playstore updates app with current build, so the assets or changes in the old build are not accessible anymore.
Hope this answers your query.
I think it's not a good idea. You have to provide a complete app to take into account new users. Moreover, Play Store is able to update an app incrementally so you don't have to care about duplication for your users
Related
I work in a team and will be uploading to the Android play store soon.
Now I have pushed apps to the play store before on my own, but this is my first time doing it within a team of people. So I just have quick questions (of which I tried googling for, but I guess my googling skills failed me).
1 - I will be uploading this app. I will be creating the Keystore file on my local machine. But what if one of my team members wants to push an update? Can I just email him the file?
2 - I understand if we lose the file, we are pretty much done. But can we upload it to a private (but shared) dropbox folder or something?
3 - What if we create a new app? Can the team use the same file for all of the apps created within the team?
Thanks.
1 - I will be uploading this app. I will be creating the Keystore file
on my local machine. But what if one of my team members wants to push
an update? Can I just email him the file?
Yes, If you send them the file, they will be able to sign the app as well.
2 - I understand if we lose the file, we are pretty much done. But can we upload it to a >private (but shared) dropbox folder or something?
Right. Make sure you have multiple copies of the file, but also make sure that they are stored in very secure locations.
3 - What if we create a new app? Can the team use the same file for all of the apps created >within the team?
Yes, one keystore file can be used to sign multiple apps.
1- Yes, you can send your team members the keystore file anyway you want. Better to also send them the password used to create the keystore, so it can be used.
2- Ofcourse, just keep in mind to save where it will be safe. (ie. not stolen/lost).
3- The keystore can be used in all apps without any kind of problem.
I'm going to release new update of my app on Google play store. I use some resources stored on user's SD card (\sdcard\Android\package\data...). I make some important updates and want to replace these old files. Is there any way to delete all these files before updating? (Some flag "delete old version's files" on GPlay) Like uninstall and reinstall of the app. I can do it my way in app (try to delete old files if present). But this approach (via some installation routine) is smart, I think.
You should do it by yourself, because Google Play Store wouldn't do it for you.
I'm looking to packing a large sqlite database with an android app, about 200-300MB. From what I've read, my options are putting it in the assets folder, and coping it out at runtime, resulting in duplicate data, or downloading the database from the web at runtime. I don't want to create a webserver for this app, so I was thinking of creating a seperate app that just installs the database to get around the data duplication problem.
All of those are pretty crummy, and I was wondering if there is a better solution?
First, I don't think you are allowed to put a 200-300MB database in your assets folder and distribute it as a single apk, since the hard limit for an apk file size is (as per google's documentation) 50 MB and I doubt that your db will compress that far.. Google introduced the "APK expansion files" for packaging large files with your apk. You can read all about those here: http://developer.android.com/google/play/expansion-files.html
I think (but I have no experience with expansion files myself) that this will not fix the issue you mentioned about having to deal with duplicate data because of the requirement to copy out your database file, but at least this will help you in the sense that you won't have to host your database file on your own webserver. I quickly scanned the documentation on the link I gave above and it clearly states that you should NOT throw away the expansion files when you are done with them, so no help on that part.
Of course, for the "setting up your own webserver part": I wouldn't even bother setting up my own webserver. There are plenty of parties out there that provide you some file hosting service. Probably you will have to pay for the bandwidth, but hey.. if people download your db file a lot, that also means that your app is doing well ;-)
I test of apk expansion files. I created a test app with a 100 MB sqlite database, uploaded the apk and database to the play store. I then downloaded the app onto the phone, the database was downloaded at the same time. The database was automatically renamed and placed in the publicly accessible directory:
/storage/sdcard0/Android/obb/com.example.app/main.1.com.example.app.obb
The app was able to open the database without any problems, but required external read and write permissions. The new and original database are bit for bit, the same. This appears to be the best solution for my use case.
A few issues, the new android developer console does not support uploading expansion files, so the old one needs to be used. Google only allows 2 expansion files, so that may be an issue for some use cases. Google say that you must not rename or delete the file, and that your app must be able to download the file from Google itself if it wasn't automatically installed.
I am looking for information about the upgrade process in android. I mean I want to know if the application is reinstalled? Is the cache cleared? Is the external storage folders deleted (as these are deleted during uninstall)? etc.
AFAIK, no, nothing changes except for the apk. This includes res/ and assets/, but will not include anything stored to the device's /sdcard/data/ directory.
If there is a sql lite database, it should be associated with a version number. If the db has to change in an upgrade, it is the developer's responsibility to implement a database upgrade for existing database, within their new release.
Keep in mind if the developer wants to, they can delete external resources. But natively, no Android will leave folders in /sdcard/data/ or whereever they might be stored.
Also, yes, the cache is cleared. This is actually from uninstalling the older version before reinstalling the new one.
From what I gather here: http://groups.google.com/a/googleproductforums.com/forum/#!category-topic/android-market/technical-help/0y8wNUhZEWo
It only replaces the .apk file.
I do not have the final APK file yet but I want to start adding the screenshots and other information ahead of time. There is a "SAVE" button and I am assuming this should be possible but it's not allowing me to save without the APK AFAIK...
You will need to upload a draft APK (never has to see the actual market) in order to get started. The only thing that MUST be correct here is the package name your app will use, as this is needed to create the new record, and is read out of the APK file rather than allowing users to enter it manually. Nothing else about the application has to even resemble what your final will be.
With the draft in place you can start updating all the other meta data and using the Save button to save your work. When you upload the final APK file, you may then click Publish.
Unfortunately, you have to upload all the information at the same time. This makes sense though, if you put an app on the market that people could search, but didn't actually include the apk...well that would just be super confusing to anyone on the market.
You could save your draft with a draft APK and then make sure to update the APK with your final one before you publish.