When developing apps, I face often a problem of managing files in my own app private directory, under Android/data/com.package.name/... - to copy, create, edit, delete test files there. On Android 11 (possibly newer versions in the future) it is only possible on physical devices when connected with a USB cable. In emulators, it's utterly impossible to access that directory - adb shell or the mediocre "Device File Explorer" in Android studio, currently give me only "Permission denied" error, when trying to enter or list Android/data folder. Even on older versions of Android using adb shell or "Device File Explorer" is not convenient, and the device file explorer does not even list "hidden" files and folders (names starting with a dot), which I also need to manage.
What is the best solution to this problem? On older versions of Android I was using a WebDAV server app from Google Play, that lets me mount the entire storage of the emulator (or device) as a virtual directory or drive on my developer computer, but on Android 11 it cannot access my app's sandbox directory.
After using a 3rd party WebDAV server, I came to the conclusion that the only solution for Android 11+ is to embed a file server (WebDAV or similar) into my own app, at least in the DEBUG build.
I cloned a very old GitHub WebDAV Server for Android project: https://github.com/erspicu/Baxermux.server.http, however there was so much to change, fix, enhance, that I finally created a new Android app project, copied code fragments from Baxermux and continued from there. You may see the result on GitHub, a very light WebDAV server library, that can be included with gradle's debugImplementation statement for the purpose of managing files in the app sandbox (or the entire Android storage if needed, too, minus other apps' sandbox folders under Android 11+):
https://github.com/gregko/Mini-WebDAV-server-for-Android
Now I can access the folders using any WebDAV client. On my Windows development host I use the excellent WebDrive product - it mounts the directory exported by the Mini WebDAV server as a Windows drive, and I can use the native Windows File Explorer, or command prompt, can view and edit the files as if they were local to my computer.
I am having an app which is targeting android 27 API. I am testing this app from playstore on device Android Q which work managed device.
Steps i followed on device Android Q having build build 6-
Installed app and allowed all the permissions(additional permission also which are custom permissions).
Uninstalled app from device.
Installed again app from playstore and found that app is asking custom permission only instead no permission.
Is it the expected behavior? Anyone know how this is?
This is something called Auto Backup.
Files that are backed up
By default, Auto Backup includes files in most of the directories that
are assigned to your app by the system:
Shared preferences files.
Files saved to your app's internal storage, accessed by getFilesDir() or getDir(String, int).
Files in the
directory returned by getDatabasePath(String), which also includes
files created with the SQLiteOpenHelper class.
Files on external
storage in the directory returned by getExternalFilesDir(String).
Auto Backup excludes files in directories returned by getCacheDir(),
getCodeCacheDir(), or getNoBackupFilesDir(). The files saved in these
locations are only needed temporarily, or are intentionally excluded
from backup operations.
You can manage it by AndroidManifest.xml. See android:allowBackup
<manifest ... >
...
<application android:allowBackup="true" ... >
...
</application>
</manifest>
EDIT
android:fullBackupContent="false"
android:fullBackupOnly="false"
There are 2 more rules available to set.
EDIT 2
I just found more useful information at the android official website. see here
Note: Any permissions a user grants to your app are automatically
backed up and restored by the system on devices running Android 7.0
(API 24) or newer. However, if a user uninstalls your app, then the
system clears any granted permission and the user must grant them
again.
My best guess is there should be some difference(like 24hours) until the user settings/permissions will be deleted from the system device/cloud.
Hopes this will answer your query in some way.
Regarding whether this is an expected behavior in Android Q:
This issue does not reproduce on Android Q emulator. I guess it counts as a baseline.
More technical details:
Runtime permissions logic in Android is mostly located in PackageManagerService (mostly book keeping for each package) and ActivityManagerService (mostly request runtime permission logic)
When package gets deleted, the data cleanup method removePackageDataLIF
gets called. It is responsible for cleaning up everything including the app permissions. This logic hasn't changed Android Q.
The permissions info is stored in system data directory, not the application's so the app data backup doesn't affect it either.
But the question remains: How could this happen?
One of the possible explanations could be the flag PackageManager.DELETE_KEEP_DATA
You can easily delete package while keeping its data directory after uninstall:
$ adb shell cmd package uninstall -k your.app.id
(-k is for keep data)
Now to check whether the permissions are kept in place along with the data directory:
$ adb root && adb shell cat /data/system/users/0/runtime-permissions.xml | grep your.app.id -A 10
(this command requires a debuggable phone firmware build)
Looking at the source of removePackageDataLIF and trying it on my Pixel with debuggable firmware the application permission is kept intact if you kept its data.
Another explanation
PackageManagerService has an another interesting method setKeepUninstalledPackages Which basically forces android to keep all the data for specified apps even if they were uninstalled.
As you said the device is work managed. Usually management is done with DevicePolicyManager. One of the available policies is setKeepUninstalledPackages, which calls the mentioned above PackageManagerService method.
Please check your Device admin app code to verify.
I have developed an android app and put this as prebuilt APK in AOSP.
So the app will be installed in /system/app as a system app.
The app has update function itself by downloading and installing the newer version APK.
But it does not work because system app cannot be updated.
Is there any way to update self-made system app?
System app can be updated, in two ways:
Updated by the ota updating, this will change the app directly, and the app still exist on /system.
updated by using package install api, this need the new version apk have the same signature with the one on /system, and the new version will be installed on /data. That means, if the device is reset, the new version will lose.
Ota update is a normal way for system app updating.
Yes, you can install an updated version of your original system app into the /data partition, provided that:
1. Both app versions are signed with the same key;
2. The updated app’s versionCode is greater than or equal to the original app’s.
One way to do this update is to use the following adb command: adb install -r <your updated apk file>. Then you can test your updated version without having to rebuild your AOSP code.
Note that your updated version in the /data partition will be removed via a factory data reset. In this case your original system app will take effect again.
I have been doing debugging on Android using my Nexus 4, however I recently encountered this error here. After doing some research on this error, it seems to be an issue with the app not being deleted properly. The app I am debugging runs fine on my other Android devices as well as the emulators, this error is only occuring on my Nexus 4. I plugged my device into computer, and have tried deleting the data/data folders but I am still getting the same issue. I also checked settings-apps to check it was definitely uninstalled.
Does anyone have any idea how to resolve this issue? According to some users, I need root access to properly delete data/data, is this true? Or is there another way around this?
Sometimes you have to also uninstall the data folders. For me, I had a package in userspace of com.kikin.cts, and also a folder directory in /data/data/com.kikin.cts. Kept getting INSTALL_FAILED_UID_CHANGED, but after removing the data folder, the error went away.
For rooted devices:
Run the below command
adb rm -rf /data/data/<your.package.name>
For non-rooted device:
Change the ApplicationId of the app. Refer this link to change
ApplicationId.
Build and install the app. App will install successfully because it is treated as new app.
Now uninstall this app. Which will clear the data.
Now change the ApplicationId to the previous one.
Build and install. Magic.. It will install.
Restart your device, and clear your project.
Basically , uninstalling would have done this for you in case if doesn't then try restarting.
You probably introduced an SharedUserID which causes this.
In most cases INSTALL_FAILED_DEXOPT or INSTALL_FAILED_UID_CHANGED means that you have not enought space to install the app.
Remove some unused apps from your device or at least remove current version of your
app.
adb uninstall package-name
In very rare cases there may be problem with application data. You have two options depending on whether your device is rooted or not
Non-rooted
Factory reset Settings -> Backup and reset -> Factory data reset (at least for Samsung S5)
Rooted (or emulator)
adb shell "rm -rf /data/data/package-name"
I got another solution working for me. You can change the package name of application, so that device recognizes it as different application and installation completes successfully. Might be helpful for those who don't have root access and also don't want to reset device.
I do have root on my Nexus 5, but nothing worked, so I had to run a factory reset from the settings which worked.
For me the trick was done by unchecking "Verify apps over USB" in the "Developer options" section.
Thought I'd share this in case it helps someone... I wrote a new version of my app in eclipse and tried to run it on my phone despite having a slightly older version on the phone that I downloaded from Google Play store. Eclipse popped up a dialog asking if I was happy to uninstall the existing on-phone version and I agreed. The uninstall was defective and led to INSTALL_FAILED_UID_CHANGED.
I tried most of the things suggested here with no luck. There was no apparent trace of the APK on my phone, or any data files I could find to delete, but something was preventing me from loading the APK onto the phone from eclipse. I also could not download my previous beta-testing version from Google Play - the download proceeded to 100% but then failed with a message reporting "unknown error", and a number (probably -24).
I was hesitant to rename my package because I already have beta testers and in-app products set up with the old package name, but I changed the package name in eclipse temporarily and I was able to install that new version onto the phone and then download the older Google Play version as well. Both versions sat happily beside each other on the phone with the same app name and icon (but different package names behind the scenes). I could then manually uninstall either or both by dragging the app icon to the uninstall icon of the phone. The manual uninstall removed the conflict and repaired eclipse's defective uninstall, so I simply renamed my eclipse package to the original name and carried on as before.
This was much less painful than a factory reset or permanent package rename. It probably only works when the source of the error is a conflict between an eclipse version and a Google Play version, but it is worth a try if you are in a similar situation.
This worked for me:
adb shell rm -rf /system/app/<package.name>
From the ADB shell you can find solution in two ways. 1. keep the data and find the solution and 2. solution without persisting the data
solution for 1. is to run the commandadb chown -R UID:UID /data/data/your.package.name through command prompt from ADB path.
solution for 2. is to run the command adb rm -r /data/data/your.package.name from the same path.
I was experiencing this issue for the past couple days on my Galaxy Note 3 test device. I have been using Calabash-Andrdoid and kept getting an error INSTALL_FAILED_UID_CHANGED, whenever the install_app method tried to execute. I was struggling with this issue because I had two test devices experiencing this. I tried everything above, including emptying out my /data/data/ app and app.test folders. I even deleted the instrumentation back-end stuff that Xamarin installs since that's the platform I used to develop my app. I could not find anything else to manually delete off of the device. When I attempted to do my work on third device and found that everything ran successfully, I realized the issue was with the devices. In the end, the only thing that worked for me was to execute a factory reset of one of the devices. I hope this helps.
Thanks,
-Shah
Here's something not covered by the existing answers. This was happening to me on emulator. If I reset user data, I get INSTALL_FAILED_DEXOPT the first time, but INSTALL_FAILED_UID_CHANGED after that. I found that rm -r /data/data/com.foo.bar is enough to reset to the first state.
The actual culprit in my case is a java method name that caused dexopt to fail. Pay very close attention to what's in logcat. Here's what gave it away:
I/PackageManager( 1275): Running dexopt on: com.foo.bar
E/dalvikvm( 2857): Invalid name: '__jni_setLocation'
E/dalvikvm( 2857): Trouble with item 14787 # offset 0x43b68
E/dalvikvm( 2857): Cross-item verify of section type 0005 failed
E/dalvikvm( 2857): ERROR: Byte swap + verify failed
E/dalvikvm( 2857): Optimization failed
W/installd( 941): DexInv: --- END '/data/app/com.foo.bar-1.apk' --- status=0xff00, process failed
E/installd( 941): dexopt in='/data/app/com.foo.bar-1.apk' out='/data/dalvik-cache/data#app#com.foo.bar-1.apk#classes.dex' res=65280
W/PackageManager( 1275): Package couldn't be installed in /data/app/com.foo.bar-1.apk
I can't tell you why dexopt doesn't like some method names, but that was the problem.
Okay, so for my LG NEXUS 4 rooted here is the solution: (
make sure you have somewhere your working app apk signed or unsigned)
and
you uninstalled this file from your phone (if exists of course)
Let's say it is: app-debug-unaligned.apk
Now in console you write:
adb push app-debug-unaligned.apk /sdcard/
adb shell
su
rm -fr /data/local/tmp/app-debug-unaligned.apk
rm -fr /data/data/app-debug-unaligned.apk
Now exit from adb and call
adb shell su -c "pm install /sdcard/app-debug-unaligned.apk"
Working?
I deleted /data/data/my.package.name and /data/app/my.package.name.apk,
problem still persistent.
however I found a folder /data/user/0/my.package.name, delete it and problem solved.
Just uninstall the app itself (not the data folders) then reinstall it, and it should be fine. Android's complaining because you may have previously debugged the app from another computer.
A solution for non-rooted device. Go to the Application manager and uninstall the app called "Selendroid" and retry again. This solution works for me.
I fix this, maybe it will work anyone else.
I'm restart my phone, then remove a few more app.
And try again to install, it's work!
Maybe problem is about to storage. I don't know why, but it's work now. Good luck! (Sorry about bad English)
Use
adb shell
go to the shell.
Then run the command follow:
rm -rf /data/data/package name
please repleace package name with your own, such as com.map.map
For anyone running Junit style tests from their computer and getting this error- while the console it told me there was a problem with my application (packaged in the format 'com.myapp.stuff'), the real issue was my test code package, which if you're running on a device gets installed as a separate app with the package name like 'com.myapp.stuff.test'. Deleting the test code "application" using the Application manager and deleting my actual app solved the problem for me. I'm posting this answer here to save someone else a "Duh" moment.
Same problem on a Mediacom device, first a
$ adb install -r platforms/android/out/android-debug-unaligned.apk
3958 KB/s (22887489 bytes in 5.647s)
pkg: /data/local/tmp/android-debug-unaligned.apk
Failure [INSTALL_FAILED_DEXOPT]
then a very persistent:
$ adb install -r platforms/android/out/android-debug-unaligned.apk
4949 KB/s (22887489 bytes in 4.515s)
pkg: /data/local/tmp/android-debug-unaligned.apk
Failure [INSTALL_FAILED_UID_CHANGED]
Doing a factory reset didn't change the dynamic (I got both errors, in sequence).
installing the same app with a different id worked
installing a different app with the previous id doesn't
Rooting not an option, the solution for me was a cache wipe: now the offending app id works fine and I didn't had to factory reset (again).
Hope it helps
For me, there was a bit more to it. Simply removing /data/data/appfolder didn't help.
The additional reason was that my external libs weren't included in .apk file because the name of folder was lib instead of libs. This has caused [INSTALL_FAILED_DEXOPT] during apk installation followed by [INSTALL_FAILED_UID_CHANGED].
So changing libs folder name worked for me in this case.
I found a solution that works both on a non-rooted device and on an emulator.
While you can't directly delete the data folders on a non-rooted device you can utilize the pm command to do that:
Run adb shell
Run pm uninstall <app name> (i.e. com.example.myapp)
Run pm uninstall <test app name> (i.e. com.example.myapp.test) - you might receive an error if the test app wasn't installed before.
It seems that for some reason when uninstalling the apps from the Android UI this doesn't work (possibly it doesn't delete the data folders) however when uninstalling via the pm command it does work.
Tried it on a "Nexus 5" and on a "OnePlus One".
It is obviously because of improper uninstall (probably due to faulty cable connection).
SOLUTION
Download SDMaid from play-store, and delete Corpse files (junk files).
Re-run application. (But you need to have your device rooted)
I met the similar problem. The reson is that you didn't uninstall all component of the app.My solution is:
deleting /data/data/com.eg.android.AlipayGphone manually.
work well for me.
I hope it is helpful for u!
This happens when installing an update to an application, and the updated version cannot run with the same user ID as the previous version.
Why this happens
Android normally assigns user IDs on its own, and when an app is updated, it inherits the user ID of the previous version. There is one exception: Android allows multiple apps to run on the same user ID if they specify it in their manifest (by setting the android:sharedUserId attribute in the <manifest> element). If the new version requests a shared user ID but the previously installed one did not, the user ID will change and you will get an error. (Presumably also when trying to upgrade from a shared user ID to a version without.)
The error you get depends on the Android version: on Android 4.4.4 I have seen INSTALL_FAILED_UID_CHANGED, whereas Android 10 reports INSTALL_FAILED_SHARED_USER_INCOMPATIBLE.
You may also get this error if the app was uninstalled without removing its data (which can be done via adb shell and pm uninstall -k—if you know what you’re doing).
Two app data locations come into play here:
App-private storage. This data is not normally accessible to end users; if you have root access, you can find the data in the file system ad /data/data/packageID.
Private shared storage: this resides on your SD card at /Android/data/packageID.
How to recover
Recovering from this essentially means ensuring that there is no package (or leftover app data) with the same package name and an incompatible user ID. There are multiple ways to achieve this:
If you have root permission on your device, you can perform some surgery to preserve your app data across the update:
Back up existing app data, delete the existing version, reinstall the new one and restore the data. Here’s how:
Using oandbackup or similar, back up your app’s private data. (You don’t need to back up the APK but it doesn’t hurt.)
If your app has a private shared storage directory (/sdcard/Android/data/packageID), open a shell on the device, enter su to switch to root mode, and rename the directory (changing the package ID to a nonexistent one). This will also change file ownership for the directory from the app’s user to sdcard.
Uninstall the existing app.
Install the new version.
Restore the app’s private data (not the APK) using the same backup tool as above.
If you have moved a private shared storage directory away, move it back to its old location (same steps as above). This will chage the file owner to the (new) user ID of the app.
If you do not have root permissions on your device, your options are somewhat more limited.
Uninstall the existing app, then install the new version. You will lose the app’s private data. If your app has a private shared storage directory (/sdcard/Android/data/packageID), you can (probably) back it up before uninstalling and restore it after installing the new version. The more recent versions of Android support backing up private app data if the app allows it; you might be able to save your app data this way with a backup app, but I haven’t tried this.
If you have uninstalled the old version already but kept the data, reinstall the old version, then proceed as above (uninstall and install new version).
If you are just trying something out, you can give the new version a different package name. That will make Android (and app stores) treat it as a different app. The new version will not see the private data of the previous one, and if you deploy the app with the changed package name to an app store, it will appear as a different app rather than an upgrade to an existing one. This is definitely not recommended in production but may serve you in a lab setting.
If nothing else works, perform a factory reset. This is even more destructive and will delete all your apps, along with their data.
Rooting and factory reset were not an option for me, but I was able to find an older version of my APK and install that (I'm guessing it was the same one that failed to uninstall properly). After uninstalling that one again, I was able to install new versions.