While Samsung Galaxy devices had new restrictions on microSD read/write access, it was hard to say whether this was the start of a trend for all Android OEMs as restrictions on microSD were bypassed by most OEMs, as the vast majority of functionality such as moving apps to microSD were ported to Android 4.x builds. The story is more than just about Android 4.4 though, as the change in microSD functionality happened some time in the 3.x releases of Honeycomb.

Before Honeycomb, Android was heavily reliant upon microSD cards, as the vast majority of smartphones carried forward the storage model from the days of Windows Mobile, with very little internal storage for the OS and its applications. Everything else had to be placed on a microSD card, which meant the OS was useless if the microSD card was ejected. The same was true of most early Android smartphones. This is the model that most everyone is familiar with. Any application could read and write anywhere they wished on the microSD card with appropriate permissions.

The new model arrived with Honeycomb, which placed permission controls on the microSD card. This disallowed any third party application from writing to the microSD card, although they could write to their own private folder on the microSD card, much like how applications can write to their own folder on /data/apps/ but they can't modify any other folder in that directory. With permission to write to external storage, it is possible to read any file on the microSD card that isn’t a private folder, but it isn’t possible to write to any other folder. The permission to write to any folder on the microSD card is now limited to system/OS applications only.

This means that while Google Play Edition devices like the LG G Pad and Samsung Galaxy S4 followed the behavior that was set by Google as far back as Honeycomb, devices like the Galaxy S4 with TouchWiz never had such restrictions on microSD, custom ROMs altered the restrictions that Google had placed, and in general, microSD behavior continued to work as it did in Android 2.3 for the vast majority of people using Android.

The big news isn’t that Samsung is adopting the change. Rather, it seems that Google is now enforcing this change in microSD behavior across all OEMs. Presumably, this means that the Android CTS (Compatibility Test Suite) now requires compliance with the new system of accessing microSD storage. Based upon user feedback, both Samsung and HTC devices with microSD slots are no longer capable of allowing user applications to write to folders outside of the application’s private folder. While it was once hard to say whether this would only be followed by a few OEMs, it seems that this standard is well on track to universal adoption.

This sounds like a major issue, but Google has clearly planned this out, as the Storage Access Framework feature in Android 4.4 allows file manipulation of data on the microSD slot and can provide access to data on the microSD card without allowing free access of all data on the microSD card. At any rate, an example of the SAF UI can be seen below.

What seems to throw a wrench into everything is that the primary internal storage partition still has the same behavior as microSD cards before Honeycomb. This means that any data in the /data/media/ directory has no permission control. It seems that Google has backed themselves into a corner in a way, because this odd inconsistency is needed to maintain backwards compatibility with applications that still assume that /sdcard/ can be written to in any manner, and any file on /sdcard/ can be read as well. Google also hasn't done anything about USB-OTG storage, which is still left up to the OEM to decide implementation. That means nothing changes when it comes to primary internal storage and USB storage.

Some may say that this is a clear attempt to kill off expandable storage and attempt to force cloud storage upon more users, but recent events have made it clear that this is a move targeted at OS security, as the popular chat application Whatsapp could have all messages easily accessed by any application that could read the SD card. On 4.4, despite the lack of security on the part of the developer, such a security breach wouldn’t be possible. However, whether this gain in security is worth the transition period between a robust permissions system for microSD/FAT systems on Android and the status quo is another question entirely, and is one that may not have an answer.

Comments Locked


View All Comments

  • JoshHo - Friday, March 14, 2014 - link

    The difference is that even with storage permissions, it isn't possible to read text messages. That needs a much more questionable permission.
  • wisi - Friday, March 14, 2014 - link

    Because it's one example. What do you mean by people? Are there other articles talking about the gimped SD card access on Android and calling out Whatsapp? I understand the comments on this article because it was mention in it.
  • wisi - Saturday, March 15, 2014 - link

    Apps still have READ permissions on the SD card. So those logs and other data can still be read by other apps if they're on the SD card.

    This crappy permission thing Google's forcing is limiting WRITE permission.
  • CSMR - Saturday, March 15, 2014 - link

    No, the better solution is to provide for a secure location for storage of application data (managed by the OS and inacessible to other apps), but also allow access to all public locations when authorized by the user.
  • danjw - Friday, March 14, 2014 - link

    I am for anything that moves toward improved security for Android. I do think they need to give app developers a time frame to get their apps updated for the new security model. After that cutoff, the non-compliant apps should be removed from the Play store. They also need to move to this security model for all external storage, not just the SD card.
  • Zstream - Friday, March 14, 2014 - link

    Just FYI, this does work on the Nokia 1520 as well. That might be something to talk about.
  • wisi - Friday, March 14, 2014 - link

    Stupid Google hiding behind "security" to gimp access to the SD card. The internal and USB (less likely used) storage stay the same...

    The direction Google has been taking with Android has really been making me root for Sailfish and Ubuntu phones.
  • Guren88 - Saturday, March 15, 2014 - link

    This is almost like Apple. So what's the use of sd card anyway?
    Before i have been downloding files directly to sd card. But now i cannot do it. Still lucky that i can still move them to sd card but that's another more time to do. Moving like 4Gb of data to sd card. I am not suing my laptop anymore to download because i finally have large storage to use. And now you want me to fully use my internal memory and transfer to sd card after? I dont care about security. It is the users fault if something happens.
  • Tarwin - Saturday, March 15, 2014 - link

    Hear! Hear!
  • digi_owl - Saturday, March 15, 2014 - link

    Here is the gist of the issue.

    When Android launched, all internal space was dedicated to Android and apps. Any kind of generally accessed space, for music and such, was expected to be on a true removable SD card.

    But later OEMs started partitioning the internal space of their devices, and mounting one of them as the "SD card".

    This resulted in various issues, like phones being sold with 8GB of storage where only 1GB (or even less) was available for installing apps.

    Problem is that Google dropped the ball, and rather than introducing a new API that could handle multiple storage areas they introduced "move to SD". Thus forever cementing the idea of internal space being "SD card" within the API.

    End result is endless confusion between Google and users about what is actually meant by "SD card". Google talks about the APIs, while users talks about the actual physical cards they can insert and remove. But only when you have a device with no internal space and a physical SD slot are those one and the same. And good luck finding those on the market today.

    It seems that Google insist that Android is to be a web terminal and PMP, not a full on OS like it could be with proper handling of files. We can see this in how file access since 3.1 is to be mediated via the media storage database and MTP, rather than straight access to the file system.

    And this latest change build on that with the introducing of the storage access framework. You can tell by how they have categories like images, but no concept of directories or file paths. This is the same kind of shenanigans that MS has tried, and largely failed, to push for a decade or more on the desktop.

Log in

Don't have an account? Sign up now