I have a suspicion that this might be due to my running a custom rom... but I figured I should at least come by and ask here.
I'm working on an app that uses some SharedPreferences. Everything in that aspect works fine, but after completely uninstalling and then installing again, I found that my SharedPreferences values were still being picked up. I ended up uninstalling and then pulling up an adb shell and found that indeed... under /dbdata/databases/mypackagename/shared_prefs/ there were still files there. I would assume that they should have been removed...
I'm using a Samsung Captivate running the Serendipity rom... Again, I can only imagine that that has something to do with it, but I'm not certain.
Edit - I just completely wiped clean and put on the Firefly Rom and tested this out, experiencing the same thing. Is this possibly a Froyo bug (both have been 2.2 Roms)?
Try this on a stock ROM, I've never heard of this problem before.
It is probably the custom ROM. When an application is removed or the Clear Data is clicked in the settings, it not only removes the the application, but also the data that is specific to it.
A custom ROM will not always do it, it would remove the application but store the files.
For the most part, the reason is accessibility, in the sense that when you say uninstall an app (i.e. Game) because of frustration, when you come back, you data is still available for use.
As developers this may get annoying but may users tend to like the ability to reinstalling an app and having the same information.
Related
After almost a week without launching Android Studio, I come tonight to continue an application I'm working on and when I open it I notice that the display characters of the IDE have completely changed as you can see on the image. I thought that the language had changed, so I have been on several forums to find out if it is possible to change the language but apparently it is not possible. Given the arrangement of characters I suspected that it did not correspond to a language but I wanted to be sure. I have also tried to launch other IDEs such as NetBeans to make sure that the problem is not coming from my machine and it is working properly. So I come to you to know if someone would have a solution for me, I do not want to be forced to reinstall the IDE at the risk of losing all the update and plugin I installed.
I'm having a problem where an app I'm developing is working on mobile devices (tested on 4 different devices), but crashing when I try to test it on my tablet. The tablet I'm using is a Tesco Hudl 2, which, although being a good quality low cost device, lacks adb drivers and so you can't debug apps through USB and get the Logcat data. The app was developed using Android Studio.
With other apps I have developed, I have just set up ACRA in the project so I can still get debug information from a crash. This time however, the app is crashing without any information from ACRA and so I'm not quite sure what is going wrong. I'm pretty sure I've set up ACRA correctly given that I've used it in several projects before and see nothing wrong this time. Can it be that whatever is going wrong is happening too early for ACRA to catch?
I have pulled out all the code from the activity so the only thing that happens in code is that ACRA gets initialized in the derived Application class (note that the crash exists without ACRA). The app also uses Google maps and a provider for search suggestions. If there is any code anyone wants to see just ask, but I'm unsure what exactly to post up since everything else was stripped out. So, does anyone have any idea on what I can do to solve this, or what tools I can use to catch whatever sort of errors happen so early in the apps lifecycle?
Thanks
Update with strange behaviour... Downloaded Crashlytics and it also did not catch the crash. I copied the project and removed every .java file except the Application, Activity and provider. The provider functions were empty (save for the return value of 0/false/null/whatever), the application class just initialized Crashlyitcs and the Activity class was empty. This then worked, I was even able to add in a lot of the code and get the google map to load.
Now if I do the same in my main project, except don't delete the .java files, the crash still happens. The classes in these files are not used so I have no idea how they can be causing the crash. Otherwise all the xml, gradle, resources are identical (except the package and app name). Very confusing...
Consider using one of the apps to view logcat on the device:
https://play.google.com/store/apps/details?id=com.nolanlawson.logcat
https://play.google.com/store/apps/details?id=org.jtb.alogcat
Also try using Crashlytics. Maybe it will catch your crash?
But yeah, it's possible to have a crash before any crash reporter (ACRA or Crashlytics) will have a chance to catch it.
And one more note, maybe there is a way to enabled ADB over WiFi.
Normally you would need to enable it via adb but maybe in case of this cheap and strange tablet, there is an option for that enabled in the ROM?
Ok! So it's 1am and I decided to have one final attempt to fix, which I think I did. In my manifest, I had things like
<activity
android:name=".MyActivity"
...
for example, and while this worked fine on the mobiles, for some reason the Hudl required the complete package name, i.e. com.mypackage.MyActivity. Not sure why this is the case but it appears to have fixed the problem.
I'm having a bizarre transparency issue with my app on Android Lollipop (and only Android Lollipop).
Steps:
Uninstall any previous versions of my app.
Install the app.
Notice weird transparency on some fragments in my app (full-screen dialog, a fragment we slide in, our pull-to-refresh code).
Build a new binary with no code changes and install on the phone as an update.
Fragments all look fine.
Steps 1-3 I understand -- maybe some material theme is being applied inconsistently, or there's an issue with the custom themes we use in our app.
But I don't understand why re-deploying to the phone fixes the problem.
I'm seeing this on an unmodified Nexus 5 that got the Lollipop update over the air. I see the same issue on the Lollipop emulator.
I've tried changing our targetSdk from 19 to 21 and it did not help. minSdk remains at 15.
Has anyone seen an issue like this and can hopefully point me in a direction to debug?
Edit: Clearing data causes the transparency to return. Force-stopping the app and restarting it fixes the transparency issue. So I think cybersam is on the right track with his answer below -- there's some kind of issue in bootstrapping. But the fragments in question use #android/color:black and #color/my_app_black (= #FF000000) as their background colors, so I don't think the issue is in my app-specific code.
There is not enough information to say for sure what is going on, but I can see one scenario that can cause this. It may be totally unrelated to your situation, but here it is, anyway:
(1) You normally depend on persistent data (e.g., stored in shared preferences, DBs, files, etc.) to determine how to display your background, and have a bug where you: (a) look for the persistent data, (b) see it's not there and use an inappropriate default value (e.g., null) instead, and (c) go on to display strange backgrounds due to the bad default value.
(2) However, you also have special code that detects the missing persistent data and initializes it with appropriate values. But that special code has a bug in that it does not update your in-memory state to match the stored values.
With the above situation, during a fresh install (and as long as the app is not killed by the system and then re-started), you would continue to use the bad data and see the bad backgrounds. During a re-installation (where you did not uninstall the app first), the system would kill your app and then re-install it without deleting its persistent data. Therefore, on a re-installation, bug (1) would not be hit and you would see the expected backgrounds.
Not really an answer, but adding a values-v21 and changing my black color to #010101 works fine. I have no idea what the issue is. Seems like an obscure theme misuse or an obscure platform bug.
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").
I recently started messing with Android Apps, but I have had nothing but problems trying to get them into the Virtual Device for testing. For some reason, they never seem to show up in the AVD. It has worked one time, but that's it out of hours spent just trying to test one or two very simple apps.
I've redone the AVD setup many, many times, trying different settings and what not to no avail. I've followed multiple guides and tutorials to the letter to get it working, but they just refuse to show up in the list. :(
Any insight would be appreciated, thank you.
I would start by testing apps that are known to work. Here are sixty or so of them.
In particular, I would start with this one. Do not change anything. Do not import it into Eclipse. Just install Apache Ant (if you haven't already), and run ant install in the project directory with your emulator running.
Either this shows up in your emulator, or it does not.
If it does not, try reinstalling the entire SDK.
If it does, then you know that your base environment is OK, and you can start slowly determining the differences to figure out where things are going wrong.
Helping you is difficult right now because your symptoms are a bit generic. It could be that you are using Eclipse and Eclipse is having a problem. It could be that your adb daemon is having a problem. It could be that you don't have any activities in your manifest, so the application is actually installing but there are no icons in the launcher. And so on.