View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0014480 | MMA | Synchronization | public | 2017-10-22 15:59 | 2020-03-20 14:14 |
| Reporter | Ludek | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | 1.3.1 | ||||
| Target Version | 1.3.7 | Fixed in Version | 1.3.7 | ||
| Summary | 0014480: Android 7's Device Maintenance feature is causing device profile to be duplicated | ||||
| Description | Findings from YLL-339-14661 shown that Android 7's Device Maintenance feature seems to be interfering with MMA's files. Running the feature appears to change the Last Modified date on StorageInfo.xml and delete the other files in MediaMonkey > Files. I believe it even just deleted the MediaMonkey folder wholesale once, which was regenerated upon opening MMA. Based on the MMW logs the storage guid was really re-generated by MMA (from 9889d636514a523934.0.f83483c6-9313-4d13-99cd-fb260617e5a0 to 9889d636514a523934.0.340ffcdd-da2b-406e-8d84-8ef146913966) by evidence caused by deletion of the files. More details at YLL-339-14661 Based on the findings it seems that MMA should try to backup its storageInfo.xml (or at least the generated storage GUIDs) directly to its private folder to prevent from duplicate profiles creation. | ||||
| Additional Information | https://medium.com/@ssaurel/how-to-retrieve-an-unique-id-to-identify-android-devices-c40080e04fa4 (a bit out of date, but describes high-level considerations) | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 904 | ||||
|
|
Based on the findings it seems that MMA should try to backup its storageInfo.xml (or at least the generated storage GUIDs) directly to its private folder to prevent from duplicate profiles creation. Nevertheless after uninstalling of MMA there is probably no way how to prevent the maintenance feature to delete the MMA files and thus losing the GUIDs? So from my point of view the better fix could be to not generate the storageGUID randomly but based on permanent storage properties (serial number or something like that) ? I known that we currently use the device serial number (the first part of the guid , i.e. 9889d636514a523934), but it is common to all storages. Nevertheless I understand that the permanent storage identifier may not exist, this is also the reason why both MMW and WMP writes its own file with generated key directly to SD card (0012205:0041044) |
|
|
BTW currently MMW prefers reading the storageInfo.xml from the private MMA folder and if it doesn't exist there then it is taking the XML from the /MediaMonkey/files/ , so I guess that for now it would be enough for MMA to write the file to _both_ locations. |
|
|
BTW: just realized that for the permanent storage identifier we could use the storage prefix now? Is this permanent? I mean the values like <prefix>FDAA-0CE7:</prefix> ? If yes, then we just need to decide whether we will continue to keep SN as the device identifier (that requires permission and isn't available on all devices) or whether we are rather going to use the ANDROID_ID or UUID solution? More about here: https://medium.com/@ssaurel/how-to-retrieve-an-unique-id-to-identify-android-devices-c40080e04fa4 ANDROID_ID solution looks good, but the risk is that user will have two identical devices from the same manufacturer and they would get the same ANDROID_ID :-/ If I undertand the UUID solution would be also suitable, but needed to be used in conjunction with the Android backup feature to persist ater MMA uninstall? Is this feature available on all devices and all Android versions? Maybe it would make sense to continue using SerialNumber (SN) for devices where the SN is available and doesn't require user permissions and use ANDROID_ID or UUID solution in the other case? |
|
|
Despite the solution used we might want to re-open 0013408 and instead of adding the suffix we should rather ask user whether any already existing profile is the one (rather than creating duplicate) ? Currently MMW creates the duplicate profile without asking so users often don't realize that another profile was created and sync settings reset. i.e. in all the possible approaches there still can be a situation in which we are not sure which profile should be used (e.g. factory reset of the device), in that case we should probably give users the choice. |
|
|
I am not sure whether at least 0014480:0049035 was implemented? But according to my tests it wasn't? i.e. for now it would be enough for MMA to write the file to _both_ locations to resolve this issue. |
|
|
Fixed in build 1.3.7.904 |
|
|
Verified 905 Tested, by Manually delete of MediaMonkey Folder, Factory Reset (SDCard was out), Done maintenance. |
