1

I have a modern Android 4.4 device - LG L34C that comes with KitKat 4.4

Relative to the https://github.com/commonsguy/cwac-provider library - I see that there is mention of getExternalFilesDir - but not the plural version.

My testing of getExternalFilesDirs() shows that the returned array index has 0 for "emulated /sdcard" and index 1 has the actual External SD Card.

Is it possible to get a syntax for paths.xml that works with the plural getExternalFilesDirs secondary index?

RoundSparrow hilltx
  • 799
  • 6
  • 16

1 Answers1

1

StreamProvider does not support that, and off the top of my head, I have no idea how it could support that. The number of and contents of removable storage are unpredictable.

You are welcome to open an enhancement request and offer some suggestions on what this support might look like.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Thank you for the reply. You confirm my understanding. This is an area that in simple terms, "sucks" on Android. The fact there is no predictable path or naming convention for the MicroSD removable path. 4.4 seems no better in this simple aspect. I appreciate your writing and time. Regarding the API, I quote Joseph Campbell "The virtues of the past are the vices of today. And many of what were thought to be the vices of the past are the necessities of today. The moral order has to catch up with the moral necessities of actual life in time, here and now. And that is what we are not doing." – RoundSparrow hilltx Aug 03 '14 at 19:36
  • In regard to solving the actual problem, I tend to favor the obvious and simple. In Android, I see too sometimes the simple solution rules. Example: blank ".nomedia" file regarding scan behavior. Maybe a kind of tag attribute in the paths.xml entry that points to a scan file on the removable SDCard? mediatag="thisisit" yeilds a iteration of all the getExternalFilesDirs() until one has that in root (or root + specified subpath)? – RoundSparrow hilltx Aug 03 '14 at 19:45
  • @RoundSparrowhilltx: I'm not a big fan of your approach, as it can easily result in unexpected output. If there are N possible copies of `foo.txt`, which one is served depends on which removable media those copies reside upon and, for all I know, in what order the removable media is inserted. You can certainly create a streaming CP that handles removable media, but I think it needs to have more app-specific smarts. Here's a sample project demonstrating the basic technique: https://github.com/commonsguy/cw-omnibus/tree/master/ContentProvider/GrantUriPermissions – CommonsWare Aug 03 '14 at 19:54
  • The TAG could be unique to match the file (unique tag flag file on each SD Card). You reply seems over-focused API theory in my view. In reality, I want to be able to pop in a 128GB MicroSD card and use it for 3 months then change it. In the lifespan of this API being called on *every file fetch* the media change itself is a rare event. -- In a way, aren't we talking the very issue that migrated server and desktop Linux away from /dev/sda conventions to UUID? even FAT has a 4-byte volume ID. In reality most are 0000-0000... – RoundSparrow hilltx Aug 03 '14 at 20:11
  • @RoundSparrowhilltx: "You reply seems over-focused API theory in my view" -- yes, well, I'm the guy who has to support the library. That means I am "on the hook" for all users of all apps that use the library, which means that I err on the side of caution. – CommonsWare Aug 03 '14 at 20:42
  • I view it that you see there is a need to establish a better standard. But you are waiting. The UUID of the SDCard would seem a proper approach - and a warning in your writing and release notes about "many duplicate UUID exist on FAT volumes" would get us out of the failures of the past and into the future ;) – RoundSparrow hilltx Aug 03 '14 at 20:47
  • @RoundSparrowhilltx: "But you are waiting" -- no, I am busy. I do scratch other people's itches in my libraries, but not always, and not when the results are not reliable. Even to the extent UUIDs exist, they are not available in the Android SDK AFAIK. Documentation warnings are ineffective in my experience and do not help users of the apps, who are the ones who will be harmed. – CommonsWare Aug 03 '14 at 20:57