genious7 / FanFictionReader

An android app that improves browsing Fan Fiction stories on a mobile device
GNU General Public License v3.0
56 stars 24 forks source link

"Unknown Error" when backing up files to memory #1

Open mttlck opened 8 years ago

mttlck commented 8 years ago

Hi,

when trying to use the backup feature I'm getting an "Unknown Error". The logcat output is not that helpful:

[ 10-29 16:50:25.481 24156:24156 V/getExternalFilesDir ]
/storage/sdcard1/Android/data/com.spicymango.fanfictionreader/files
[ 10-29 16:50:25.496   723: 1502 V/WindowManager ]
not Base app: Adding window Window{3798ae0f u0 com.spicymango.fanfictionreader/com.spicymango.fanfictionreader.Settings} at 9 of 15
[ 10-29 16:50:25.505 24156:24156 V/getExternalFilesDir ]
/storage/sdcard1/Android/data/com.spicymango.fanfictionreader/files
[ 10-29 16:50:25.511 24156:24156 V/getExternalFilesDir ]
/storage/sdcard1/Android/data/com.spicymango.fanfictionreader/files
[ 10-29 16:50:25.518 24156:24156 V/getEmulatedFilesDir ]
/storage/emulated/0/Android/data/com.spicymango.fanfictionreader/files
[ 10-29 16:50:25.526 24156:24156 V/getExternalFilesDir ]
/storage/sdcard1/Android/data/com.spicymango.fanfictionreader/files
[ 10-29 16:50:25.600   723:  740 W/InputMethodManagerService ]
Window already focused, ignoring focus gain of: com.android.internal.view.IInputMethodClient$Stub$Proxy@c3c1c2b attribute=null, token = android.os.BinderProxy@1b4b2519

I'm using Android 5.1.1, so maybe it's an access rights error?

pzmarzly commented 8 years ago

The same problem on Android 6.0.

iamzim101 commented 8 years ago

I just updated my Xcover 3 from 4.4 to 5.1 and now this bug is affecting me.

genious7 commented 8 years ago

I'm aware of the issue. This is caused because the storage model changed on android Lollipop (5.0 & 5.1) and Marshmallow (6.0) so that apps can't write directly into the sd card without explicit user permission, except in the "android/data/..." folder.

I'm trying to see what the best fix is. One option would be to save the backup on the internal memory instead of the SD card in these android versions and have a dialog tell the user to copy the file to the new phone. The disadvantage of this method is that the user has to manually copy the file. The advantage is that this is a very quick fix.

A second option would be to have the backup save on the app's sd card folder (sdcard/android/data/...) instead of the SD card root. This would work without any issues. The only downside is that android deletes this folder if the app is uninstalled; therefore, the backups would be lost if the app was uninstalled before the sd card was removed and placed on the other phone. As before, this is a quick fix.

A third option would be to just drop the backup file idea completely and back up via Google Drive or something like that. I'd need to look more into it; I'm not sure what advantages/disadvantages this would have.

A fourth option would be to try to use the Lollipop storage model to write to the SD card. The problem is that in Lollipop, the application cannot control where the backup is saved nor provide hints or recommended locations. Under the lollipop model, when the app wants to write a file to the sd card (except in the android/data/... folder), it tells Android that it wants to write to a folder. Android then opens a file browser (which the app cannot see or interact with in any way) and waits until the user selects a folder. Once the user selects a folder, the backup would be saved here. Restoring would involve a similar process, since the app can't tell where the backup would be. The only downside is that since my phone doesn't have an SD card slot (Nexus 4), I can't really try it (well, I could use an android emulator, but they are very slow - not looking forwards to it). Due to this, I'll probably won't do this in the near future. If anyone wants to try fixing it, this link may be relevant (for coders only).

pzmarzly commented 8 years ago

Most apps (e.g. Titanium Backup) saves backup in internal memory and user has to copy it by himself. I think that would be the best option.

Lollipop/Marshmallow official way to write to SD is terrible. It took me a while to find out how to give ES File Manager permission to use SD card - it needs 6 steps to do = it's unacceptable to use.

Cloud backup would be awesome and GDrive API introduced in API v23 (Android 6.0) is certainly interesting - https://developers.google.com/drive/v3/web/quickstart/android .

Pheoxy commented 8 years ago

What if you just left that up to the users decision? As many apps do ask where they want to backup to.

ie: Save to>Folder, Google cloud, Onedrive.

I have seen many apps do this as a viable backup option and the only complaints I see are typical user error or bugs.

You could even have it function like when you share links or media.

MasterZoen commented 8 years ago

@Pheoxy The new Android OS security does not allow an App to write freely to any storage. Apparently, someone was writing some trashy apps that would overwrite important files needed for the android device to run, so now Apps can only write to a folder generated at the install of the app based on the apps name, i.e.: "Android/data/com.adobe.reader" for the app Adobe Reader.

This has made a lot of people who use multiple SD cards on their tablets unhappy, but it's not going to change.

Pheoxy commented 8 years ago

Then why not just use that storage as your meant to and then require extra permissions for backup to use sdcard or data folder like as everyone seems to have the download folder to backup to?

MasterZoen commented 8 years ago

With what your suggesting, due to the way permissions works, an app creator can specify a blanket permission to write to storage which you would have to agree to in order to use the app, then write code in the app that overwrites core data files needed to run your android device. This would cause the device to malfunction.

Currently, if you tell FanFiction Reader to backup its files, it creates a file in the emulated root directory. If the backup file already exists there, it is overwritten. By forcing all apps to only write to specific places, then there is no chance of this occurring within another apps folder, if say 2 different apps wrote a file titled, "data.dat." FanFiction Reader, for instance, writes the backup file, "FanFiction_backup.bak," to the emulated root folder of either the device storage or an SD card. This is a place where no vital files are stored and thus can be written to freely. You can use the file manager app that comes on your device to move, copy, and rename files, as well as create custom folders, and move that backup file to the SD Card. You cannot, however, access the core system files or protected data files of apps without "Root Unlocking" the device. This prevents you from accidentally deleting or moving important files your device needs to run.

Currently, there is no way to ensure that an app could write to those custom folders and not to a vital system data folder or even another app's data folder using the FAT file system that is used on SD cards that allows multiple platforms of iOS, Android, Linux, and the various Windows OS to read and write.

I'm sure you've heard of someone who was foolish enough to recycle the "Windows" folder of their PC back in the days of Win95 or WinXP? By restricting what places an app can write to, and what locations are considered system access only, you are prevented from deleting/moving important files that an app needs to run. Remember, apps can be installed/moved to the SD card, which means that their important data files are on that SD card. If another app could freely write to any location you told it to on the SD card, then you could potentially overwrite another apps data. Similarly, someone could code an app to overwrite the important data file of another app that is competitive with theirs and render that app inoperable.