While developing an Android app targeting all versions above 4.1, I observed that uninstalling my app and installing it again does not clear its data.
The app is designed to store the details that it asks in its first screen.
After uninstalling and installing again in OS version 4.4.4, the app prompts the user to fill in the data, which is normal. However in version 6.0 the same install/uninstall sequence bring backs the data originally input.
I tried to ensure by visiting /data/data/my package folder to see the database is gone after uninstalling and indeed that folder gets deleted during uninstall.
I tried to delete the app by visiting the settings page, through Titanium Backup and the results are same. The device is rooted Nexus 5 running v6.0.
What could be the reason for this strange behavior?
It's because Android 6 has automatic backup. You need to tune android:allowBackup and android:fullBackupContent in your manifest <application> tag if you don't want your data backed up or if you want to include or exclude some resources. It's not a bug.
More about AutoBackup on Android here.
greywolf82's answer is correct but I want to add some info to this.
When developing my Android app (using Xamarin), I noticed that whenever I'd re-launch the app from Visual Studio, my data would revert back to data from a few months ago. It didn't matter if I simply stopped and re-ran it from VS, or if I completely uninstalled the app and reinstalled it.
It's also worth noting that we never explicitly told the app to store a backup.
The backup also seemed to overwrite newer data when launching from Visual Studio, and we have reports of users using the release build of our app and also getting newer data overwritten by the backups.
Since I don't know exactly when backups and restores occur this feature seems to cause only problems.
We've modified our AndroidManifest by adding the following two lines:
android:allowBackup="false"
android:fullBackupOnly="false"
After adding them, our AndroidManifest contained the following xml:
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.XXXXXXX" android:versionName="8.0.0" android:installLocation="auto" android:versionCode="439">
<uses-sdk android:minSdkVersion="14" android:targetSdkVersion="24" />
<application
android:label="#string/appName"
android:icon="#drawable/icon_small"
android:installLocation="internalOnly"
android:largeHeap="true"
android:allowBackup="false"
android:fullBackupOnly="false"
/>
...
</manifest>
Once we explicitly set the value to false, all seems to work. I'd expect this to be an opt-in feature but...seems like it might be on by default for apps which don't specify the value either way.
You should check your device's Backup and Reset settings, and turn off Automatic restore (when reinstalling an application, backed up settings and data will be restored.)
Turning off auto-backup is different from the auto-restore. If you think it will be helpful to turn on auto-backup for your application do so. But if you think this will make end users who are not aware that the auto-restore feature of their device is turned on, feel free to turn it off.
In my case, I turned off the allowBackup feature, but since I already had a backup of the previous version on the Cloud, it still kept on restoring.
See image as reference for a Samsung device on Android 6.0. Other devices and versions may have a different screen. See image below.
Automatic Restore Setting under Backup and Reset
Just adding to this, we found that in Android 9 (on a HMD Nokia device) that the assets were held, even after deleting the app through the interface and through adb.
The answer of adding:
android:allowBackup="false"
android:fullBackupOnly="false"
Obviously, this is not a new answer - but an observation for people who were in the same position as us.
I recently needed to take advantage of these features, I was able to uncover documentation and upon extensive testing this is what I have been able to deduce:
Android:allowbackup - will backup local app data on the device it is located on.
Android:fullBackupContent - is used in conjunction with Google's backup restore api and CAN be controlled via an xml file to specify what exactly to backup, as well as a BackupManager class you may implement for further control over the process.
However the documentation states, and I have confirmed with testing, that a restore will only occur either when the device is restored and the restore app data process is triggered. OR it will also restore when the app is sideloaded through adb, which is what we do when we run the app for testing or debug on our devices through Android Studio. Note that if you set android:allowbackup but do not configure android:fullBackupContent with a Google api code then the apps data only gets stored locally, whereas if you configured it properly then if your app was backed up and you get a new device the apps data was stored on the cloud so it can be restored on a new device.
If you are targeting android 10 then you have to put android:hasFragileUserData="true" in application tag of AndroidManifest.xml
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android">
<application
android:name=".MyApplication"
android:icon="#mipmap/ic_launcher"
android:label="#string/app_name"
android:theme="#style/AppTheme"
android:allowBackup="true"
android:hasFragileUserData="true">
.....
</application>
</manifest>
android:hasFragileUserData is a new manifest setting (I’m guessing on ). “If true the user is prompted to keep the app’s data on uninstall”. This seems ripe for abuse, but I can see where it might be useful for some apps.
See https://commonsware.com/blog/2019/06/06/random-musings-q-beta-4.html
Adding android:allowBackup="false" under application tag in Manifest file solved my issue.
Here goes the android documentation for Back up user data with Auto Backup
I also added:
tools:replace="android:allowBackup"
to override same option in a used component
This answer summarizes multiple other existing answers, and includes recent details as of Android 12 being introduced, and includes instructions for clearing existing app backup data generated from a device.
For more information, see
https://developer.android.com/guide/topics/data/autobackup#EnablingAutoBackup
https://developer.android.com/about/versions/12/behavior-changes-12#backup-restore
https://developer.android.com/guide/topics/manifest/application-element
http://android-doc.github.io/preview/backup/index.html (for clearing existing app backup data stored in Google Drive from a device: Settings > Backup > toggle Google One backup off then back on again, then try uninstall/reinstall again)
As a side note, some of the other answers suggest android:fullBackupContent="false" but that doesn't seem correct anymore since that is currently meant to specify an xml file of a specific format, not a true/false.
These attributes to <application> allow for disabling or configuring specifics for Android auto-backup functionality.
<application
tools:replace="android:label, android:icon, android:allowBackup, '...any other attribute you want to override with a value you set in this file for in case dependencies set them to other values...'"
'...your other attributes set here like android:label and android:icon...'
android:allowBackup="false" '...default is true, and setting this false prevents data backups of any kind (except device to device transfers if your app targets Android 11 (API 30) or higher)...'
android:fullBackupContent="#xml/backup_rules_android_11_and_below" '...optional, for Android 11 and below, referring to a file res/xml/backup_rules_android_11_and_below.xml you need to create...'
android:dataExtractionRules="#xml/backup_rules_android_12_and_above" '...optional, for Android 12 and above (fullBackupContent still needed along with this, assuming you support Android 11 and below), referring to a file res/xml/backup_rules_android_12_and_above.xml you need to create, with a slightly different required xml format...'
android:fullBackupOnly="false" '...optional, and default is false, but if set to true this field description says it enables auto backup on Android 6 (API 23) devices or higher (I am not sure how this matters compared to the more broadly reaching allowBackup)...'
android:hasFragileUserData="false" '...optional, and default is false, but if set to true this field description says it gives the user an option when they uninstall the app whether or not to backup their app data...'
>
'...contents of application element...'
</application>
The <application> changes only affect creation (or lack of creation) of future app backups; any existing app backup data will still exist and be used until overwritten or cleared (see above for instructions to clear that data for a device).
Just change android:allowBackup="true" to android:allowBackup="false" in manifiest.xml. It will be worked.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
<application
android:allowBackup="false"
android:icon="#mipmap/app_icon"
android:label="#string/app_name"
android:supportsRtl="true"
android:theme="#style/AppTheme">
</manifest>
Related
I don't know when this occurred, but my app was always listed by MyAppName under the Android Phone Settings for Location Permissions - the settings section that specifies what apps are allowed to use location services (ie: always, only when in use, never, etc).
I discovered yesterday that in this section my app is no longer listed as MyAppName and is now listed as webIntentFilter - I was able to validate this on several Android phones, including my own. My app icon is correct, just the name is wrong.
In my config.xml:
<widget id="com.myAppName" ... >
<name>myAppName</name>
So, obviously some android:label: 'webIntentFilter' is overriding my config.xml app name.
I haven't a clue as to where this is originating from. I searched my entire project folder for files with the string webIntentFilter in them and got 17 hits across 12 files. But I don't know which one is causing the problem. I looked at all of them and none of them seem to be related to Location Services so I can't determine which is the culprit.
How can I fix this?
I found it....but I still have no idea how it happened, or how many revs of my app its been like this.
In projectFolder\platforms\android\app\src\main\AndroidManifest.xml was the main <application> section xml tag had the following:
<application
android:allowBackup="false"
android:fullBackupContent="false"
android:fullBackupOnly="false"
android:hardwareAccelerated="true"
android:icon="#mipmap/ic_launcher"
android:label="webIntentFilter" <----------------------------- here
android: name="androidx.multidex.MultiDexApplication"
.....
>
Changing it to: android:label="myAppName" fixed it.
I ran into one confusing issue today about the security tip on developer.android.com such as
allowbackup
debuggable
according to
this merging logic, I think it will come to application manifest and then library manifest. if now host app overwrite the flags i set in library, does that mean i no longer have protection to my library?
for example,
<manifest //this is library manifest
xmlns:android="http://schemas.android.com/apk/res/android"
package="com.MYLIBRARY_MANIFEST"
xmlns:tools="http://schemas.android.com/tools">
<application android:allowBackup="false"
android:label="#string/app_name">
</application>
</manifest>
<manifest //this is application manifest
xmlns:android="http://schemas.android.com/apk/res/android"
package="com.MYAPPLICATION_MANIFEST"
xmlns:tools="http://schemas.android.com/tools">
<application android:allowBackup="true" //overwrite it as true
android:label="#string/app_name">
</application>
</manifest>
Is there a away to protect the library itself by forcing the library not allowbackup or not debuggable?
does that mean i no longer have protection to my library?
Libraries do not really have "protection" in the first place with respect to manifest entries. Users do.
The developer of the app that uses your library can choose what to do for android:allowBackup, android:debuggable, etc. In the specific case of android:debuggable, that is usually set via Gradle: debug builds set it true; release builds set it false.
Is there a away to protect the library itself by forcing the library not allowbackup or not debuggable?
Libraries do not really have "protection" in the first place with respect to manifest entries. Users do.
You cannot prevent developers from setting whatever value they want for those attributes.
You are welcome to examine the ApplicationInfo object for the app (call getApplicationInfo() on any Context) to see what those flags are set to. You are then welcome to take whatever steps you want based upon that information.
However, bear in mind that the step you appear to want to take — prevent the app from running if the developer does not submit to your demands — simply means that your library will not be used. Telling developers that they cannot do debug builds, for example, is not going to be very popular.
You have Host project and Library. I will explain in debuggable example.
Actually host app always will be play a most important role.
If you doesn't include debuggable flag into manifest file in your library, Android get this flag in Host App (if exist).
So when you setup debuggable = false flag in Library and debuggable=true in Host App, this means that you debuggable flag doesn't affect library, but Host app - affected.
If I wanted to research how and where permissions [requested in the Mainfest.xml] were used in an Android app for the purposes of removing them is there an easy way of doing this? Does lint or findbugs offer some sort of support for tracking permissions used/abused in a project?
I came from the future to save your lives.
Here (in the future), LINT does check for missing permissions as you can see on LINT checks.
So, go to your AndroidManifest.xml and remove all tags <uses-permission> using Android permissions (meaning, don't delete permissions that belong to your app, such as UA_DATA and C2D_MESSAGE).
Then run LINT analysis. Click on Analyze then Inspect Code...
Look under Android -> Constant and Resource Type Mismatches
You should see all missing permissions.
Then you can just right-click them and select Apply fix "Add Permission". If you select this option, Android Studio will include one permission for every error. So you'll end up with multiple copies of the same permission on your Manifest file, just delete the duplicates. You can do it manually too.
Here is the description of the LINT rule:
ID ResourceType
Description
This inspection looks at Android API calls that have been annotated with various support annotations (such as RequiresPermission or UiThread) and flags any calls that are not using the API correctly as specified by the annotations. Examples of errors flagged by this inspection:
Passing the wrong type of resource integer (such as R.string) to an API that expects a different type (such as R.dimen).
Forgetting to invoke the overridden method (via super) in methods that require it
Calling a method that requires a permission without having declared that permission in the manifest
Passing a resource color reference to a method which expects an RGB integer value.
...and many more. For more information, see the documentation at http://developer.android.com/tools/debugging/annotations.html
I'm using Android Studio 2.1.2.
In your app manifest file you should have a tab "Merged Manifest" there you can see your final manifest and the permissions you request you can click on a permission to see where it came from. (who added it - ex': sdk or what code it came from)
There is also a simple way to remove a permission by adding to manifest:
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"
tools:node="remove" />
Also remember to add the tools at the top:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
package="...">
The way I would do it for an app for which I didn't write the code would be to remove the permissions one by one and test the app end-to-end each time. When it fails, narrow it down. If not, that permission may not be used.
You will have to try removing them one by one and checking i fthe app still works OK. This is not checked by lint in any way (it should be).
When they come back (they are currently down), you can upload your apk to this website (if that's ok with you) and let them statically analyse the permissions you are using: http://www.android-permissions.org/
Best way is to understand what the may actually do. If it is ever going to use the camera then you know you need the camera permission.
Or you could just learn what your app does and then go through the permissions and see which ones are extra. What does your app do, what phone features does it use. There should be some documentation somewhere on what it should do and what methods are in there
Is it possible to set values in AndroidManifest.xml by code?
For example I want to set android:largeHeap="true", but it is possible only in 3.x platforms; but my application must run on 2.2 and above.
Then I want to set android:largeHeap="true" on 3.x platforms and do nothing on 2.x platforms by code.
Any ideas??
It is NOT possible to change Manifest at runtime..
from developer.android.com :
The manifest presents essential information about the application to
the Android system, information the system must have before it can run
any of the application's code.
plus:
These declarations let the Android system know what the components are
and under what conditions they can be launched.
so everything is specified before running and then your App runs, under permissions and conditions Android system gave to it.
cheers
I am learning this via Sams Teach Yourself Android in 24 hours.
This is really strange, I run the app in the emulator and I get my splash screen (just some crappy text really) then I press the home button, and click on my app's icon and it gives me "Application is not installed on your phone"
I went into the emulators settings->applications and it's there!
I cleaned the project, uninstalled it from the emulator and re-ran it. Same damn problem.
(project is simple:
6activities, each has a unique text, as it starts it shows the splash activity
I have not even connected the other activities... just this)
You can download the entire source if you want at http://elxotica.com/TriviaQuiz.rar
Ok, got it working after going to the authors website, downloading the support code and going over it and comparing it line by line.
Basically in my manifest file I had
<activity android:name=".QuizSplashActivity"
android:label="#string/app_name">
and again below I had
<activity android:name="QuizSplashActivity"></activity>
which I thought was needed, but it looks like that should not be declared twice.
I fixed the problem but am not 100% sure of the cause :((
My problem was solved with this error when I moved the INTERNET permission statement in the manifest file out of the activity definition and into the application definition - that is, up in the hierarchy, right under the SDK version declaration:
<uses-sdk android:minSdkVersion="14" />
<uses-permission android:name="android.permission.INTERNET"/>
<application android:icon="#drawable/icon" blah blah
I also had the permission defined twice. Compiling did not find the bug, however, running the app on the Android emulator did. "Application not installed" is not very helpful, tho. Rather like, "You fowled up [and if you don't know why, I'm not telling you].
I have no problem to run it on Android 2.2 Virtual Device. Maybe you can try create new AVD and run it there. I´ve had similar problem with new update and creating new AVD solved it...
Yeah, I had the same problem.
Just don't declare QuizSplashActivity twice.
Helped in my project, grettz
Yet another failure mode with the same symptom. I had same permission twice, first like this:
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"></uses-permission>
then like this:
<application android:icon="#drawable/icon" android:label="#string/app_name" android:permission="android.permission.WRITE_EXTERNAL_STORAGE">
The second one turns out not only not needed, but also cause the "Application not installed.." error.
So my application declaration looks like this now:
<application android:icon="#drawable/icon" android:label="#string/app_name">
And all is well in the world.
Same symptom, different cause. I'm not entirely certain what happened, but I will hazard a guess in case it helps anyone. What I know for sure: I deleted the icon, dragged it anew from Applications, problem solved.
At some point I changed which Activity was the entry-point (had android.intent.category.LAUNCHER & android.intent.action.MAIN)
I was trying to open the app using an icon on one of my "desktops", an icon which I had added before making the change in the manifest which changed which Activity was MAIN. So I'm guessing that the shortcut refers to the launcher activity and not the app (makes sense)...
My problem was missing assemblies in the package. But only on some phones.
I enabled "link all assemblies" option in the Xamarin studio and problem solved.
Android project options->Android build->Linker behavior->Link all assemblies.
[I'm using Xamarin studio with mono on Android.]