So, I have found a bug in a specific sdk that causes it to fail on some Android phones after re-installing a new version of an app which uses the sdk (via adb install -r, and presumably when a user gets an update that has been pushed to the Android market). Is there any way to force an application's data to automatically be cleared upon update of the app? I realize there are different ways that data could be stored, but I just need to essentially simulate an invocation of the "Clear Data" button that'd you find when browsing to the application in the "Manage Applications" section of the Settings (i.e. I just want all data gone).
I am an Android noob and am doing minimal Java coding on this project, so I am basically looking for the simplest solution here. I suppose I could settle on storing a "currentVersion" to disk and then checking it upon launch every time to see if the real current version matches the version that was written to disk on the last launch. Is that the only real way to do this? If so, what's the simplest way to do so?
Thanks!
Is there any way to force an application's data to automatically be cleared upon update of the app?
No, at least for my definition of "automatic".
I suppose I could settle on storing a "currentVersion" to disk and then checking it upon launch every time to see if the real current version matches the version that was written to disk on the last launch. Is that the only real way to do this?
I'd name it lastKnownVersion, but otherwise this approach seems sound and probably is your only viable option.
If so, what's the simplest way to do so?
Ummm...do exactly what you said. Use Java I/O (storing the file somewhere inside of getFilesDir()), or SharedPreferences.
Bear in mind, though, that your users may get rather frustrated if you blow away their data on an app update. Personally, I'd rather we find a better solution to your original problem ("I have found a bug in a specific sdk that causes it to fail on some Android phones after re-installing a new version of an app which uses the sdk").
Related
I am hoping to implement some security for an Android app to prevent people from using the code unless it was installed on the correct device by the company. My first choice would be to make sure the app was installed through the Google Play Store, but this app will not be available there.
I have determined that one security measure that will work for my use case is checking some of the information in the Build class. I am concerned that there could be the possibility that some of the fields in the class may not stay the same, even if the same model of device is always used.
What portions of the Build class are subject to change for a specific model of device and what fields should never change?
In the end all of these system configs are just .xml files residing on the device somewhere around /data/system/sysconfig which you can modify in any way you want if you have write access (aka root) so I would recommend starting from making sure that the user running your app does not have root privileges. There are some FOSS libraries for it, you can start from there.
I'm trying to install Kik Messenger twice. I have two accounts and don't like to log out because I lose all of my conversation history. I'm currently using Titanium backup's profile feature, which is a very nice fix, but it's still a pain having to switch back and forth between profiles. I might be looking for "perfect" when perfect doesn't exist. I am completely new to modding apks and Android in general, all of my work on this so far has been "trial and error". Anyways, here's what I have:
I have the Google Play version of Kik installed on my phone. I have extracted that app and modified the package name successfully using apktool. However, when I try to install, I get an error saying something about duplicate provider authority. So I did some research and learned that I'm supposed to edit this part of the AndroidManifest. So I have played around with that a little bit and after I change the authorities, I am able to install the modded app. However, it crashes immediately.
Does anyone know how to fix this problem with the provider/authorities?
The issue you're hitting is that the app has registered certain classes to handle particular events. These need to be unique across all installed apps and point to existing classes in the app that will perform some activity with the supplied information.
You bypassed the safety check when installing by changing the defined handlers in the Manifest but that didn't really fix it as they still need to actually point to a valid, working class that can handle the requests/events.
You would need to decompile, rename the classes involved and all references made to them and recompile the whole app to really fix the problem. However, I'd assume that it would likely be against the license. If the code is open source then it wouldn't be too big a task to rename some classes & packages then build the app. If it's closed source then it is a harder task.
What you can do is either set up your device to use multiple accounts (the OS not the app) as each user has a separate data storage and preference location that should allow you to have two configurations. Or you can request that the developers include some sort of multiple account handling or easy account swap feature.
I have published an application to Google Play store. Now I have update ready, the application uses some serialized objects and the update has changed them a bit, therefore an uninstall before updating is needed.
How do I force users to uninstall the application first or do I have to work this out in code somehow?
I think you should work this out in code. Figure out a way of identifying the old data and converting/upgrading it to your new structures if needed/possible. Even keeping the old object defs around for reading and then converting these in memory to the new structure should work.
One option would be to write some kind of "schema version" pref that at least tells you what the data was written under (missing that pref means it is version 1). At least it will be easier next time.
BTW, the reason I recommend this over just deleting the files is the risk of just repeatedly deleting the files. You need some way of detecting that the files that are there are old (ignorable, deletable or for upgrade) or new and should be kept.
I've written a program that, when completed, I plan to add to the Android Marketplace. I have given many files as features for users to store information and reload later, and while debugging, I've noticed the files tend to get deleted when I update the code after a long while (like a few days spread apart--for some reason, it doesn't happen when I update the code often, like every hour when I'm adding new features and testing them out). Note that I use a real phone for testing and not the emulator. What I'm wondering is, will the files get deleted after each release of the app?
I really don't want users to lose their stored information on every update or bug fix I provide, so if that is the case, is there a way around this?
Nope the files doesn't get deleted automatically, but it depends upon where you are storing the files. If the user deletes the app the files associated with it will get deleted too. But in case of an upgrade, No! normally it won't.
In case you are using SQLite for storing data, there is a proper way to handle upgrade there.
I completely revamped an app. Tested it for a while on my device and emulator. The app worked fine. However when I updated the app through the Android market, my users experienced crashes.
Since there is no way to properly debug this procedure I asume the crash is caused by old data which is not being removed from the device (probably from the onsavedstate bundle?!).
Is there a way to do a "clean/total" reinstall without having the user to do it manually?
Best Regards
Johe
When the variable that's giving you trouble is overwritten with the proper type on the next OnPause, the class cast problem should be gone. You could reserve one variable to hold a version number and if the one you retrieve from OnResume is older you skip the other saved values and use the defaults.