I have been seeing some very strange issues where application files inside the external storage ( getExternalFilesDir() ) were not writeable. I started to track down the problem and for now I found one problematic device:

Samsung Galaxy Tab A (SM-P550) running Android 6.0.1 (SD card is not installed)

The following Samsung tablet will not clear your application folder after uninstalling the app! All the files will be kept. And what’s worse — the files are owned by the previous installation, so you are not able to remove or modify them.

This will break a lot of applications — because you practically won’t be able to use your application folder at all after a reinstall. You would have to create a fallback mechanism that will make a new folder with a different name and then abandon the old one.

How to reproduce

Use a Galaxy Tab A (6.0.1). Create an empty project in Android Studio and add a line of code that will create a file and test if the file is writeable for the current process.

Run the application, the file will be created just fine (and the file will be writeable). Now uninstall and use a file explorer and look into /Android/data/your.package.name — the file will be still there (even if it shouldn’t be). Install the application again — the log will tell you that the file isn’t writeable anymore.

Also you don’t need to have WRITE_EXTERNAL_STORAGE permission for this — this isn’t required for the directory returned by getExternalFilesDir() .

Possible workarounds

Restarting the device will “unlock” the files and the freshly installed application will be able to modify the files.

Requesting WRITE_EXTERNAL_STORAGE in runtime gives the application the permission to modify any files on the external storage, so with that permission you are able to access and modify those files (but that means that your application can access the whole storage).

Setting the target SDK version below 23 has no effect — the application folder is not deleted after uninstallation.

This is a preliminary report — I will try to go into more detail later, but for now I think it’s just an issue you should be aware of. It also seems that there already was a similar bug reported to Samsung in 2013.