New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate: Sdcards with no UUID #231

Closed
d4rken opened this Issue Mar 29, 2015 · 11 comments

Comments

2 participants
@d4rken
Owner

d4rken commented Mar 29, 2015

Originally reported by: Bitbucket: d4rken, GitHub: d4rken


There is currently a single case on a LG G3 where SD Maid can not get access to the external sdcard on Android 5.0 through the Lollipop storage framework.

Currently it looks like that sdcard returns no UUID from
StorageVolume.getUUID() and thus this StorageVolume entry gets rejected by SD Maid.

As other LG G3 devices do not experience this issue, it is mostlikely not SD Maid at fault but an issue with the sdcard. The UUID value is used for unique identification, to lookup reverse uri<>path mappings and to sort out duplicate storage entries.

While the code could be made to work without the UUID it is unclear what possible pitfalls this opens so this is basically not something that we could just try.

SD Maids volume mapping code is inspired by the ExternalStorageProvider which also rejects volumes without an UUID.

It's unclear how to further proceed here or if at all.


@d4rken

This comment has been minimized.

Owner

d4rken commented Mar 29, 2015

Original comment by Bitbucket: d4rken, GitHub: d4rken:


To proceed further on this we would need to know if this is just an sdcard issue (by trying a different sdcard) and what filesystem is used on the sdcard, FAT16/FAT32/EXFAT.

@d4rken

This comment has been minimized.

Owner

d4rken commented Mar 29, 2015

Original comment by Bitbucket: d4rken, GitHub: d4rken:


DocumentsActivity correctly shows the sdcard. Compare how it populates it's storage list with SD Maids method.

@d4rken

This comment has been minimized.

Owner

d4rken commented Apr 8, 2015

Original comment by Bitbucket: d4rken, GitHub: d4rken:


From http://forum.xda-developers.com/showpost.php?p=59987770&postcount=2073

I'm still investigating an issue where the system has no UUID value for an external sdcard, which makes it impossible for SD Maid to restore "normal" access to the external sdcard on unrooted devices with 5.0+.

I've attached two screenshots of the current stats i got, the LG G3 seems to be certainly a canidate and some Samsung devices.
The question is: Is this a ROM or sdcard issue?

An example output for an LG G3 device is:

#!bash

StorageVolume:
mStorageId=131073 mPath=/storage/external_SD mDescriptionId=17040808
mPrimary=false mRemovable=true mEmulated=false mMtpReserveSpace=0
mAllowMassStorage=false mMaxFileSize=0 mOwner=null mUuid=null
mUserLabel=null mState=mounted

For GT-I9505:

#!bash

StorageVolume:
mStorageId=131073 mPath=/storage/extSdCard mDescriptionId=17040804
mPrimary=false mRemovable=true mEmulated=false mMtpReserveSpace=0
mAllowMassStorage=false mMaxFileSize=0 mOwner=null mUuid=null
mUserLabel=null mState=mounted mSubSystem=sd mActivitySecureContainer=true

Both times, no UUID, normally the value is set and something like "C7BA-FD11".

To provide access on Android 5.0+, SD Maid needs to reverse map the URIs it gets from the system uris to actual files/pathes.
Currently this is done by using the UUID of the external sdcard as unique identifier, because the URI the system puts out are also defined by it.

In detail:
SD Maid asks the system for all storages and gets objects as the ones above.
What we want is to create a mapping like this:

#!bash

/storage/foobar/strawberry.apk - > content://android/tree/foobar/strawberry.apk

Normally "foobar" is the UUID of the storage in question.
Then we store an object in a map that contains the UUID and the path the storage is mounted on.
Now if we need to acess a file on the external sdcard, we look into the map and create the correct URI to access that file via androids storage provider.

But now we have storages without a UUID. The only case i could look at in details (LG G3) had the mount name, e.g. "extSdCard", for "foorbar" where normally the UUID is used. This seems very arbitrary.
I looked through AOSP code and found no instance which would explain where the id-value (foobar) comes from if the UUID is null.

Looking at

#!bash

 http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/5.0.2_r1/com/android/externalstorage/ExternalStorageProvider.java/#137

where i got my inspiration, they even use the same approach.
More mysterious is that they also throw the mapping away if the UUID is null, and the external sdcard access on 5.0+ works through the ExternalStorage provider.

@d4rken

This comment has been minimized.

Owner

d4rken commented Jan 17, 2016

Seems to common on CyanogenMod builds, but not exclusively.

cm_i9300-userdebug 6.0.1 MMB29T 99e11f5e45 test-keys
LRX22C.I9505XXUHOJ2

Here extSdCard was part of the voluem list but didn't return an UUID.

1452963069126 W/SDM:StorageVolumeMapper: Missing UUID for /storage/extSdCard
eu.thedarken.sdm.tools.storage.x.StorageAccessFrameworkException: No matching StorageVolume for:UriPermission {uri=content://com.android.externalstorage.documents/tree/240F-405B%3A, modeFlags=3, persistedTime=1449943582741}
eu.thedarken.sdm.tools.MissingVolumeRootException: No VolumeRoot for: /tree/240F-405B:

Another intresting case, we have a UUID-Permission match for the external sdcard but are looking for an additional entry, possibly an USB OTG device? The mount list didn't show any though. S5 (LRX21T.G900FXXU1BOJ1):

1452943669006 W/SDM:StorageVolumeMapper: Missing UUID for /storage/Private

1452943669007 D/SDM:StorageVolumeMapper: VolumeRoot: treeUri:/tree/6375-02FC:rootId:6375-02FC, title:6375-02FC, documentId:6375-02FC:, storagePath:/storage/extSdCard
1452943669012 W/SDM:StorageVolumeMapper: Missing UUID for /storage/Private

1452943669018 W/SDM:StorageVolumeMapper: Failed to build VolumeRoot via StorageVolume.
eu.thedarken.sdm.tools.storage.x.StorageAccessFrameworkException: No matching StorageVolume for:UriPermission {uri=content://com.android.externalstorage.documents/tree/7A1A-65B2%3A, modeFlags=3, persistedTime=1451258707841}
eu.thedarken.sdm.tools.MissingVolumeRootException: No VolumeRoot for: /tree/7A1A-65B2:
@d4rken

This comment has been minimized.

Owner

d4rken commented Mar 10, 2016

Using a device that allows to swap primary & secondary storage through a "Default write disk" incurs the same issue as the previously primary storage has no UUID either. See #312

@d4rken

This comment has been minimized.

Owner

d4rken commented Mar 10, 2016

The whole issue is ROM based.

An sdcard that was working on a HTC M9 on Android 5.1 (having a UUID), didn't work on a LG V10 on 5.1.1 (where it had no UUID).

@prozacfield

This comment has been minimized.

prozacfield commented Mar 26, 2016

Very interesting. I'm on custom ROM, so maybe that can be a problem here?

@d4rken

This comment has been minimized.

Owner

d4rken commented Mar 26, 2016

@prozacfield Nope, seen it on official stock ROMs, e.g. by LG.
I'm still looking for a case where this happens for one sdcard and not for another card, but on the same device.

@d4rken

This comment has been minimized.

Owner

d4rken commented Mar 28, 2016

v4.0.11 should fix cases that are similar to the LG device i got logs from in #330.

@d4rken

This comment has been minimized.

Owner

d4rken commented Apr 4, 2016

Removing the sdcard, formatting and reinserting it can help in some cases.

@d4rken

This comment has been minimized.

Owner

d4rken commented May 30, 2016

Likely fixed by #312

@d4rken d4rken closed this May 30, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment