View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0013030 | MMA | General | public | 2015-12-17 22:50 | 2016-02-15 04:08 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Product Version | 1.1.3 | ||||
| Target Version | 1.1.3 | Fixed in Version | 1.1.3 | ||
| Summary | 0013030: MediaMonkey can't access its application folder | ||||
| Description | At 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 Reproduce | For 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. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 549 | ||||
|
|
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) |
|
|
I can no longer seem to replicate the bug. I must be doing something slightly different :-( |
|
|
I've tried again and again and for some reason, can no longer replicate this problem... |
|
|
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. |
|
|
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. |
|
|
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 |
|
|
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 |
|
|
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. |
|
|
Fixed in build 533 |
|
|
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 |
|
|
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. |
|
|
Verified 549 |
|
|
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. |
