owner

Discussion  - 
 
KitKat will make your SD Card completely useless: per the Android API specification, apps can no longer write files to your SD card.  And Samsung is following it.

This only applies to dual-storage devices, i.e., devices with a user-writable internal flash storage AND a removable SD card.

From http://source.android.com/devices/tech/storage/index.html:

"The WRITE_EXTERNAL_STORAGE permission must only grant write access to the primary external storage on a device. Apps must not be allowed to write to secondary external storage devices, except in their package-specific directories as allowed by synthesized permissions."

If your device has user-accessible internal flash storage, your SD Card is a "secondary external storage device".

What this means is that with KitKat, applications will no longer be able create, modify, or remove files and folders on your external SD card.  As a for-instance, you can no longer use a file manager to copy files from your computer to the SD card over a network.  This ability, which has existed since the beginning of Android, has been taken away.

The only stated reason for this removal of functionality is that, "Restricting writes in this way ensures the system can clean up files when applications are uninstalled."  I do not pretend to understand this logic.  Apps are still allowed to write in arbitrary directories on the primary storage (with the appropriate permission), but are denied the same access to external storage.

Samsung has implemented this feature with their KitKat OTA updates.  Note3 users are now complaining that FX File Explorer can no longer write to their external SD cards.  There are solutions to this problem for users with root access.  Users without root access appear to be screwed.

I'm not quite certain how Google intends for you to place files on your SD card.  Perhaps you have to use proprietary Google apps that contain permissions unavailable to the rest of the developer world.  Perhaps you're supposed to put everything on the cloud and pay carrier data fees to get it there.  Perhaps you're supposed to use some kind of WIRE to attach your WIRELESS device to your computer and have the computer do that work for you.

In my opinion this is a horrible misstep by Google and the Android Open Source Project.  Functionality has been removed without reason, to the severe detriment of users and developers alike.

I apologize for not bringing this to everyone's attention when KitKat 4.4 was released, but it was not mentioned in the Android 4.4 changes document: http://developer.android.com/about/versions/android-4.4.html.  It's only mentioned in the article on source.android.com.  I was only made aware of its existence from user reports as a result of Samsung implementing this change in its KitKat OTA updates.
146
123
Alex Kravchenko's profile photoEmile Belanger's profile photoAllen Wang's profile photoChristoph Nahr's profile photo
33 comments
 
IIRC, Google never wanted dual storage devices anyway, but this sucks for non rooted users. There's a reason Nexus devices switched to internal storage only. 
 
What about the status if external SD is mounted inside /sdcard/SomeFolder....?

What does the following mean?
External storage devices surfaced through these APIs must be a semi-permanent part of the device (such as an SD card slot in a battery compartment). Developers expect data stored in these locations to be available over long periods of time. For this reason, transient storage devices (such as USB mass storage drives) should not be surfaced through these APIs.
 
The problem should exist regardless of mountpoint, assuming that the Android firmware obeys the specification.
 
I just update my Galaxy Note 3 to KitKat, then was irritated when I couldn't use QuickPic to move some pictures to a folder on my external SD. I also tried using a file manager, but of course that also failed. I had to connect the device to a PC, then copy the files from the device to a folder on the PC, then copy them back to the folder I wanted them on in the SD card. Ridiculous.

I see that the Camera app CAN write to the external SD just fine. photos are still going to the DCIM folder on my external SD card.
 
ES File Explorer is able to copy files from internal SD to external SD just fine without root.
 
ES was also able to do this on Google Play Edition devices for a while, then an update killed it.  I'm not certain what they were using to do it, but I don't believe it's in the standard API.   One workaround is that the media content API will let you create and delete files in any directory, but creating/removing directories is not possible.
 
The camera app and other system apps can write to the secondary-storage/SD card because they have the WRITE_MEDIA_STORAGE ("Modify/delete internal media storage contents") permission.  This permission is only granted to system apps that request it.  User installed apps can request the same permission but the system will ignore it.  The Samsung file manager gets this permission, so you may be able to use it to do what you need (while not being at all anti-competitive :)).  

Here's a screenshot of the apps that get this permission on a stock Verizon Note3 (stock ROM):  http://android.nextapp.com/content/fx/external/MediaWrite.png
 
Thanks for the info. This "feature" is certainly very irritating. I hope the folks at XDA come up with a way to root the Note 3 under KitKat.
 
Oh sorry, just seen you have commented on ES file manager above :) Found out their trick?
 
If you're only storing game data, you can still write to /Android/data/your.package.name.   Regrettably if they uninstall your app (even for an moment), it's all gone.  You should still be able to read arbitrary locations on the card, so you can copy (but not move) it in there.

I don't know if it still works on KitKat with secondary storage and I wouldn't recommend it in any case, but you may be able insert new files on the SD card using the Media content provider (e.g. insert a row at URI  MediaStore.Images.Media.EXTERNAL_CONTENT_URI) and write data to the returned URI via ContentResolver.openOutputStream().  I'd recommend against doing so in production, but I'm curious to see if it still works.  This mechanism can also delete items (there's a DB trigger that will kill the corresponding real file when rows are deleted).  There doesn't appear to be a means of creating/removing directories though.  And again, not a fan of solutions like this even if they do work...there's nothing to say they won't be removed in future releases.
 
Thanks for the reply. Yes for normal games this is possibly OK, however these are ports of PC games, they require the user to copy over a load of game data, then the game uses this directory to run in, save games, settings etc. Its all C/C++ so URI stuff is not really possible.
This update is really going to break a LOT of apps, and annoy a LOT of users. I hope the manufacturer's (Samsung) get a lot of complains and decide to fix KitKat to allow access.
Anyway good luck with it all!
 
I've devised a possible solution here: http://forum.xda-developers.com/showthread.php?p=50008987

Any help testing on that would be appreciated, bear in mind it should be considered very experimental at present.  I'm currently only able to test it on a VZW Note 3 on Jelly Bean where I've restricted permissions to behave as they would on KitKat.
 
Hi, Tod,

This workaound is ok for Android 4.3 but does not work on Android 4.4. I have tried it on G Pad 8.3 Google Play Edition.

I am also finding the solutions now. Your fix may work because of the logic of MediaProvider.java class. But on Android 4.4 this class has fixed this behavior.

You can find the change at following link: http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android-apps/4.4_r1/com/android/providers/media/MediaProvider.java#MediaProvider.checkAccess%28android.net.Uri%2Cjava.io.File%2Cint%29

It does not allow to write to external sd card using media provider any more. You can find the comment like this: "// don't write to non-cache, non-sdcard files."

I am also studying new DocumentProvider now but it is also permission protected. "android.permission.MANAGE_DOCUMENTS" is a system level permission:(
 
Good work on the investigation guys. Is it not illegal for a manufacture to remove a hardware feature after the sale? I would say removing write access to the SDCard the same as (major) feature removal. I think Samsung must roll out another update soon to re-enable access.
 
+Allen Wang Thanks for looking into this, that certainly looks like a showstopper for the media content provider workaround.  I would be curious to know if this is also the case on a TouchWiz phone.  I'd imagine the behavior is the same, as I doubt Samsung would make modifications at that level.  
 
+Emile Belanger I don't know the legality of it.  I am pretty amazed they did it, then again I'm shocked Google added it to the API in the first place.   It's anti-user and anti-developer.  Google, the phone manufacturer, and your cellular carrier--all the parties making the decisions--are not affected.  Users tend to blame app developers first, which of course doesn't improve my mood on this one bit :).   And the decision making parties are well aware of this.

In the event this can't be worked around, my solution looks like this: http://android.nextapp.com/content/fx/external/MediaFail.png.  That text needs to be modified a bit, e.g. it should read that it, "affects all applications except those installed by Google, your device manufacturer, and your cellular carrier."   A "Tip" dialog will also be appearing on all KitKat+ phones with a media card when FX starts (with a default "don't show again" checkbox).
 
And one more question...anyone here tried the experimental build of FX that uses has the mediafile workaround in place?: http://forum.xda-developers.com/showpost.php?p=50028014&postcount=2008

If you do, make sure you enable this experimental feature in the "File Management" section of the settings.  Please then try the following tasks on the external SD card:

* Create a file (or copy a file to the external SD card).
* Create a directory.
* Delete a file
* Delete a directory.
* Rename a file. (Should fail, not supported by FX)

And to those who mentioned ES, does that actually work on 4.4?  How does it fare with the above 5 tasks?
 
I just installed the 4.4.2 update on my Sprint Galaxy S4 and was immediately horrified to learn of this issue... I just tried ES and I am able to create and delete a file, but not edit it or rename it, and I am able to delete a folder, but not create one (unable to try renaming a folder).  As I think you noted, the build-in file manager is able to do it all, but without the SMB support that FX or ES offer I'm in a real bad place (and, I expect FolderSync to be broken as well, and I have that set to run every night and that's the biggest loss for me at this point).
 
Hey Tod, I noticed your app doesn't declare the WRITE_MEDIA_STORAGE permission... I noticed this after I had the bright idea of converting FX to a system app via Titanium... I figured if it declared the permission, in theory, it should work, since as I understand it, only user apps are prohibited from getting that permission now, but of course it didn't work... obviously not a generic solution since it requires root, but I wonder, can you validate the theory?  If you declare the permission in your manifest, do root users at least then have an "out" to getting back to the previous operation?
 
I think having that permission and being a /system app are the requirements, but I've not thoroughly investigated/tested it.

The best solution for rooted users though is to modify  /system/etc/permissions/platform.xml.  Just add <group gid="media_rw"/> inside the WRITE_EXTERNAL_STORAGE permission element, i.e., directly below the <group gid="sdcard_rw"/> line.

Example: http://forum.xda-developers.com/showthread.php?t=2617921

I'm just looking for solutions for non-root users (getting several emails a day now about this problem).  I never actually mention/suggest rooting to them unless they indicate they have root access.
 
Yep, I discovered the root fix a few minutes ago over at xda, worked like a charm. Agreed though, certainly not a generic answer. 
 
The biggest impact on me is being able to copy from my network shared folder. What I'm doing to work around this on my Galaxy Note 3 is to copy the files from the network folder into my built-storage using FX File Explorer and then move them to external microSD card using Samsung's My Files file manager. Cumbersome and requires free space on your built-in storage but at least it works without root.
 
Fucking Google and fucking Android. That's not an opensource project if Google is deciding what the users should do and what they shouldn't. Android development is closed, the license is non-copyleft, so that's not true FOSS.

And it started at least when Google decided to remove UMS, and in fact maybe even earlier.

Anyway
a) Having OTA updates enabled is insane today - newer Android versions only add more restrictions, DRM modules, selinux, knox and etc. There's NO new features.
b) Having a non-rooted device is idiotic and should make you feel like an apple user, because that means a device you don't control at all.
 
+Виталий Филиппов I don't think the removal of USB mass storage was all that evil, but certainly understand what you're saying.  USB mass storage had to go as they wanted to move away from using a FAT filesystem for the internal storage, which does make sense.  

This move (the elimination of user SD card write access) is a bit more "unique".  I've never seen Google take such a misstep before with Android.  The claimed reasons of being able to cleanly uninstall all app data and protecting access on multiuser systems don't measure up.  

The removable media card should be a world-writable mass storage device (for apps that declare the correct permissions).  Desktop computers handle removable media this way by default (at least on Linux, OS X, and Windows).  If the user is able to physically remove the media, there's not much point in trying to protect it.
 
Why didn't Google simply require that people reformat their flash cards with a proper file system, like F2FS or ext2/3/4, where file ownership and protection works just the same as the rest of the OS's file spaces?

Then youd have file spaces for music, movies, ebooks, documents etc which can be shared amongst apps which have a genuine reason to read or read-write the files.

Ok, so you can't take the memory card out and put in a windows or mac computer without a file system driver, but there's still MTP; and I'm sure it's not beyond the wit of Google to improve the linux ext3 or ext4 file system drivers for OSX or Windows.
 
+Paul Mansfield I agree that would have been the correct solution (if there was actually a problem), but my understanding is that Google doesn't like the idea of dual storage devices at all.  Bear in mind there was no API for dual storage access between Eclair (Android v2.1, API level 7) and Jelly Bean MR2 (Android v4.3, API level 18).  I mention Android 2.1 because I believe that's when the first dual storage device (HTC Incredible, gen 1) entered the market.  Twelve API revisions over 3.5 years, with most popular phones adopting dual storage, and in all that time they never bothered to even consider addressing the issue for developers.

In a nutshell, I don't think they care.
 
* FOR ROOTED DEVICES ONLY *

I've developed an app for root users to resolve the issue.  This uses the standard "fix" or reverting the /system/etc/permissions/platform.xml to allow apps with WRITE_EXTERNAL_STORAGE to belong to the Android UNIX group "media_rw".  It modifies that file using XML APIs to add just this specific permission, rather than pasting something new over the top of it.

XDA Thread is here: http://forum.xda-developers.com/showthread.php?t=2684188

No Play Store upload yet, currently APK must be downloaded directly (see XDA thread for details).
 
That's great! I hope this will work on Sony devices too.
 
+Paul Mansfield there is no ext4 support on uSD because exfat is a proprietary tech by MSFT and Sandisk, google/moto contest that patent, in the meantime fat32 is used for reading to the PC, windows doesnt play well with ext systems, this is why if you dualboot like i do i can't see my ubuntu files from windows but i can access the ms partition in ubuntu. this is how MS gets monies from android, the patent to allow the storage to be read like a usb under windows. remember the JB stuff that it wouln't read files to the PC? and how some OEMs have suites to transfer files to the PC? its related. this is also why even the low lumia 520 can support 128GB cards and next month, get apps to install on the uSD. all with the competition between MSFT and GOOG. fortunately i'm rooted and cm11 has this ux bug sorted out.
 
+Vita Vidaurre you can format an SD card as ext4, f2fs or any filesystem, you don't have to leave it as FAT, exFat.
It's only by convention and for convenience people keep them as FAT filesystem format.

On my 32G card, I have set aside 3GB which is ext3, and there's a Debian Linux install there which I can mount and chroot into.
 
+Caroline Nguyen Apps can still use the external SD card as a cache, which is what Play Music is doing here. This is now the ONLY real permitted use though, and all data is deleted if that app is uninstalled. Google did essentially declare that the only effective use for your SD card was as a cache for such cloud-storage apps though, so you're still pretty close to the mark.
Add a comment...