View Issue Details

IDProjectCategoryView StatusLast Update
0013030MMAGeneralpublic2016-02-15 04:08
Reporterrusty Assigned To 
PriorityurgentSeveritymajorReproducibilitysometimes
Status closedResolutionfixed 
Product Version1.1.3 
Target Version1.1.3Fixed in Version1.1.3 
Summary0013030: MediaMonkey can't access its application folder
DescriptionAt 0012922 we implemented an error dialog that would appear warning users that they needed to re-install MMA (to pre-empt crashes that were occurring prior to the implementation of the dialog).

When we originally implemented this, it had seemed that the bug occurred only when a clean install of MMA was done on a machine that previously had MMA installed. Unfortunately, user feedback is showing that the bug occurs in other scenarios--for some users it occurs each time there's an update to MMA. See:
http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=83180

We should fix this asap.
Steps To ReproduceFor either the alcatel idol 3 (Android 5.0.2), Asus Zenfon 2 laser (Android 5.0.2):
1 Uninstall MMA and delete all associated directories (/MediaMonkey, contents of /music, /playlists)
2 Reboot device
3 Install MMA and run
4 Grant access to the SD card when prompted
5 Close MMA
6 Uninstall MMA and delete the /MediaMonkey directories
7 Re-install and run MMA
--> the error occurs

Note:
- the bug occurs with either mma or mma beta
- the bug only occurs with certain devices. It cannot be replicated on these devices that also contain sd cards: Samsung Tab 8 Pro (Android 4.4.2), Samsung S3 (Android 4.4.2), Samsung Tab 12 Pro (Android 5.1)
- the bug appears unrelated to 0013025 (i.e. waiting for the app to terminate prior to re-installing the app has no effect).
- the bug does _not_ occur if at step 6 I simply re-install an updated version of MMA (without first uninstalling the previously installed version). This is in contrast to the reports from users.
TagsNo tags attached.
Fixed in build549

Relationships

related to 0012922 closedmarek MMA crashes on clean installs to Android 5 on some devices 
parent of 0013115 closedrusty First-time USB sync to various devices fails (xml file not seen over MTP) 

Activities

marek

2015-12-20 16:05

developer   ~0043733

Last edited: 2015-12-20 16:25

I have found probably related issue on StackOverflow:

http://stackoverflow.com/questions/13976276/java-io-filenotfoundexception-temp-png-open-failed-erofs-read-only-file-sys

Could you please verify whether the folder was opened ? It can be even related with connected USB cable (MMW can open this folder over MTP)

rusty

2015-12-20 18:58

administrator   ~0043735

I can no longer seem to replicate the bug. I must be doing something slightly different :-(

rusty

2015-12-21 03:57

administrator   ~0043738

I've tried again and again and for some reason, can no longer replicate this problem...

rusty

2015-12-22 13:48

administrator   ~0043755

Last edited: 2015-12-22 14:33

More test results:

Zenfone 2
1 Install, Connect USB, Uninstall/Re-install--FAIL. Reboot & Run--FAIL. Uninstall/Re-install--SUCCESS.
2 Install, Connect/Disconnect USB, Uninstall/Re-install--SUCCESS.
3 Install, Connect USB, Install update--SUCCESS.
4 Subsequently, however, reproducing the steps from 1 fails to replicate the bug
5 Replicating the steps from (Cindy-1) also fails to replicate the bug. i.e. Install, Uninstall 523 (leave /MediaMonkey) / Install 525 and run from install complete dialog--SUCCESS. Reboot & Run--SUCCESS. Uninstall/Re-install--SUCCESS.

Idol 3:
1 Install, Uninstall 523 (leave /MediaMonkey) / Install 525 and run from install complete dialog--FAIL. Reboot & Run--FAIL. Uninstall/Re-install--FAIL. Uninstall (leave /MediaMonkey), Reboot, Re-install--SUCCESS.

2 Uninstall MMA, Reboot, Install MMA, Run MMA, Exit MMA, Uninstall MMA, Install MMA, Run MMA -->FAIL

3 Same as 2 but using the store/beta build --> FAIL

4 Same as 2 but using the beta build from the file system -->FAIL

5 Same as 2 but with MMA Pro installed --> FAIL

6 Same as 2 but on first run, click 'skip' and don't grant access for SAF storage --> FAIL

7 Same as 2 but with MMA 1.1.2 --> SUCCESS

HOWEVER: in cases 2,3,4,5 it's possible to get into a state where SUCCESS consistently results if the initial Reboot is skipped--but I can't figure out what causes the change in state!!

Summary: the bug occurs when MMA is somehow installed in a certain state. Once it's in that state, the only way to get rid of the problem is to uninstall and reboot.

BUT, sometimes, the device/mma installation gets into a state where the bug stops occurring, and I have no idea why.

Lastly, the issue appears to have been introduced in MMA 1.1.3.

rusty

2015-12-23 05:16

administrator   ~0043757

Note: I tested build 1.1.3.455 and it also experiences the crash on the Idol 3. I haven't tested build 450 yet.

marek

2016-01-12 23:51

developer   ~0043843

Last edited: 2016-01-13 02:05

I have found out that it is really related to User ID of folder. After re-installation, it differs. Uninstallation and reinstallation is not necessary, reboot fixes it - but MMA showed the dialog even it was actually repaired by the reboot. This is fixed in build 533.

Still looking for a way how to workaround this Android bug.

I have found out that it can also cause many other exceptions - SAF failures and MediaStore failures

marek

2016-01-13 01:54

developer   ~0043844

Last edited: 2016-01-13 02:04

Tracked here:

https://code.google.com/p/android/issues/detail?id=198748

and here:

http://stackoverflow.com/questions/34757203/android-application-cannot-access-external-storages-after-reinstallation-due-to

marek

2016-01-19 12:21

developer   ~0043893

As discussed over IM:

It is certainly Android bug because application specific folder has to be always writable. Write permissions to /Android/data folders and to the rest of the storage are two different things and are on different layers.

Permissions to /Android/data folders are low level linux permissions, where each application is separate USER and has its separate USER folder created with some USER ID (UID).

All other folders on storage looks like writable on this layer. But they are blocked on higher application layer and are permitted using SAF (storage access framework) API. But you cannot get access to /Android/data folders using SAF because it is blocked on lower layer.

So application can only access folder with it's UID. But as I described, the bug is that the UID of this folder is somehow cached and sometimes it isn't correctly updated.

We used the application folder for some application data because I thought that it is always writable (and it should be!). But now (if this bug occurs), I will request access to whole SD card and write the application data to /MediaMonkey/ folder using SAF API.

marek

2016-01-19 12:22

developer   ~0043895

Fixed in build 533

rusty

2016-01-19 16:30

administrator   ~0043899

Test note: Marek explained that upon further investigation, the problem is that MMA has always used app-specific folders to store certain application data, and that in android 5+, when access is granted to individual folders OR to the entire SD card, access is granted _except to the application-specific folders_ (in certain specific cases).

---------detailed explanation---------------
It is certainly Android bug because application specific folder has to be always writable. Write permissions to /Android/data folders and to the rest of the storage are two different things and are on different layers.

Permissions to /Android/data folders are low level linux permissions, where each application is separate USER and has its separate USER folder created with some USER ID (UID).

All other folders on storage looks like writable on this layer. But they are blocked on higher application layer and are permitted using SAF (storage access framework) API. But you cannot get access to /Android/data folders using SAF because it is blocked on lower layer.

So application can only access folder with it's UID. But as I described, the bug is that the UID of this folder is somehow cached and sometimes it isn't correctly updated.

We used the application folder for some application data because I thought that it is always writable (and it should be!). But now (if this bug occurs), I will request access to whole SD card and write the application data to /MediaMonkey/ folder using SAF API.]
---------------------------------

This should be tested:
- Quickly on kitkat devices with SD cards for regressions (upgrade + clean install)
- Quickly on lollipop+ devices with SD cards that previously worked for regressions (upgrade + clean install)
- In detail on lollipop+ devices with SD cards that previously experienced the bug

marek

2016-02-13 11:38

developer   ~0044152

Fixed in build 549

Added fixes as repairing of invalid Uri and better exists() method for SAF files.

This caused duplicates of storageInfo.xml and crashes.

peke

2016-02-13 21:46

developer   ~0044154

Verified 549

rusty

2016-02-15 04:08

administrator   ~0044156

Tested USB and Wi-Fi sync on S5 mini / Android 4.4, Huaewei Y6 / Android 5.1, Fire 7 / CM 12.1 for regressions. None observed.