Re: What about removable SD card in 4.4

[cydi...@gmail.com]

Ok, I get why Google made this decision, but as a user I see a BIG issue with this.  If as a user I use 3^rd party apps, such as a camera, that app cannot save the image to anywhere on my SD card except within their app folder (or whatever one wants to call it).  Shouldn’t I be able to have the choice to have the file saved where ever I chose, namely with my OTHER pictures in this example.  Pictures that I’ve had for years and over multiple cameras.

 And before you suggest using the “cloud” I personally prefer not to keep things in any cloud for storage.  I have no control over that environment and if something happens to it I can do nothing.   I specifically chose to use a SD card for that reason.

 Also if a user uses multiple types of apps, like a camera, can the gallery app still find them?  Similar with a music player?  Do third part apps of these natures need to be able to “talk” together?

 Seems to me for files such as music or photos there needs to be some sort of backup plan.

[Marc BENSOUSSAN - ASPEN9000]

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-platfo...@googlegroups.com.
To post to this group, send email to android-...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/groups/opt_out.

[virtual]

It's very sad that Google is choosing this direction for Android (which claims to be "open", as Sundar said at MWC).
For me, as a user, being able to use a file manager to copy video files from my NAS connected to the network and organizing media on the External SD card is a HUGE advantage that Android *had* over iOS or Windows Phone.

Safety is OK, but disrupting a feature with an update is not acceptable for me.
I hope Google will revert his decision, otherwise root will be even more required (first the the disallow to set flight mode on 4.2 and then this!).

Il giorno lunedì 23 dicembre 2013 09:32:29 UTC+1, Andy Panda ha scritto:

Hi,

Since 4.4 was published we found one more change in storage configuration. Now it is deeper that was before because was
changed policy to rich WRITE_MEDIA_STORAGE permission.
So the problem is that non-system applications could not write to external SD (i mean not emulated but real removable one)
I had look inside sdcard service some time and played with fuse options, but could not find right solution how to mount/emulate
SD to provide write access for user installed application (actually non-system one).

So I'm able to open a photo in Gallery application, but I could not save it after some modification was applied.

Storage configured according to guide on source.android.com

[Liran Barsisa]

Jeff, I'm sorry but I have to say I agree with what people have written here and on many other websites.

This act of Google doesn't make sense, since the SD card is not the main place that gets garbage files. It's the primary external storage that does, and since it's built in, it can be out of storage quite quickly without any way to replace it with a larger one.

The first storage that gets out of space isn't the SD card. It's the internal storage types...

Most apps don't even use the SD card for putting their files.
Sadly, many popular apps still put their files on the primary external storage , and this includes : Waze (Google's app , BTW) , Viber, WhatsApp, Kongregate games, ZeptoLab games, Airdroid, ...

If anything, both storage points should be blocked for writing outside of apps' scope.

However, The user should still be in control of which apps he trusts to allow this, since there are just so many cases that it would make sense to allow it:
Third party cameras, social networks, file managers, image/video/documents editors, ...

I can't believe that the SD card is the one Google has picked on blocking, and that you expect that all the user's need will be done either via the PC or by built in apps (which might not fulfil the needs or might not even exist).

This reminds me of how iTunes work for iPhone...

Please Google, fix this issue as soon as possible. 

The SD card main purpose (for user's files) in will be lost if that's how you treat it.

On Friday, February 14, 2014 11:55:24 PM UTC+2, Jeff Sharkey wrote:

An Android fan plugs their SD card into their camera while on a Safari. They get back to their hut and plug the SD card into their Android device. The camera put pictures in the folder "Camera".

These users will be able to see the photos on their Android tablet, but they won't be able to free up space or modify any of these photos until they get to a computer?

I agree this is a valid use-case that the platform should consider supporting in a future release.

Or does Google get a pass since it can sign its apps as system apps? Will Google+ Photos be able to delete photos, but no other competitor in the marketplace will be able to?

Google apps are just like any other third-party app; they get no special treatment or abilities with respect to external storage.

--
Jeff Sharkey
jsha...@android.com

[Liran Barsisa]

Can't agree more.

Google has made a very bad decision here, and I don't get why not tackle the primary external storage first, as it tends to have a lot more garbage files than the SD card.

Devices will still be filled with files on random places, and unlike SD cards, you can't do much about it since some devices don't give you enough storage there.

There are even a lot of popular apps that still put junk files that won't ever be removed even after uninstallation: Waze (which is of Google, BTW), Viber, Whatsapp, Kongragate games, ZeptoLab games, Widgetsoid, AirDroid,...

Google could have taken a confirmation approach (as done via firewalls) instead of just blocking , and let the users decide which apps are allowed to write anywhere and which won't.

It could also under the same management of admin rights, just like other special features.

The current situation reminds me of iTunes - you can't manage your storage unless you connect your device to a PC (or have a build in app for this, or root).

There are so many apps that should be able to write to the SD card even for places that shouldn't be removed: camera apps, documents/videos/images editors, ...

Now the SD card can only work as a cache folder for apps, since they can't reach any other place other than the primary external storage for content creation, and that is usually much more limited than the SD card.

I'm really disappointed by this act, both as an end user and as a developer.

[Alan Laas]

My initial reaction to this was shock and outrage but after reading some more articles on the situation and what you are trying to do with setting up SAF, what about an approach like this...

Let's say new groups with a directory for each was automatically created on the SD Card for specific file types such as Images, Music, Documents, etc. and a special permission was granted for each type that would grant write access to those types of files if it were requested.  Then apps could be designed to facilitate sharing by file type, data that is intended to be retained wouldn't be removed with an uninstall yet the clean up of other types of files that were needlessly left behind when apps uninstalled could work as you indicated.  The abstraction you seek with SAF could be facilitated easily as well.

[Sebastian Nielsen]

This also raised a issue with MicroSD Smart Cards.

Have wrote about it here:

http://code.google.com/p/android/issues/detail?id=66868

Also Another issue with this, is that I can't lend a USB stick from a co-worker, insert it using OTG, edit the EXCEL-file using a Office application on phone or pad, save the file and then allow the co-worker to edit the file on the computer.

For this to be possbile, I HAVE to know the app's internal app name - eg "com.android.example.myapp". Google Play its easy on - you can look in the URL. But samsung's app-store wont reveal that.. nor the Android interface, only the app's friendly name, like "POLARIS Office 5" is visible to the end user.

And why should I need to tell my co-worker which app I use to edit office documents?

See the suggested change, where a file, that Always are read-only when mounted on the phone, is put in the root directory of the media, which Controls access. So you can create this, Permit.xml file on the computer, and put it on the root of your SD card or USB device, and then Android reads that file and uses that to decide which permissions that should be valid *for that single storage device*. So if you want to allow access to your SD card to any app that have WRITE_EXTERNAL_STORAGE permission, you will have to eject the SD card, put it into a computer, and then use a text editor to add a Permit.xml file in the root of the SD card and write some XML sentences telling Android to permit all, and then put the SD card back into the device.

Same if you want to use a USB memory with Android. Then you simply "prep" all the USB memories you own with a Permit.xml file on the computer, and they will be usable from android.

This also allow the end user to specify if only specific signatures or apps should be allow to access that storage device, for example if you don't want malicious apps to be able to delete your precious photo Collection in your USB memory but still allow your file manager to manage that, you can add the name or signature of the file manager inside Permit.xml.

Then access permissions is then tied to every storage device, which is what the end user wants. Because some USB devices the user don't care about if they get full with garbage or if a malicious app wipes.

And some storage devices the user is fond of and want to keep the data or not have the app to fill with garbage.

So let the user select and use a permission system tied to the storage device actually accessed.

[Sebastian Nielsen]

Also this restriction makes it impossible to for example take a USB stick that was edited on a computer - and then put into USB-OTG and edit that file using a Office application on the phone.

The Office application is bought in the Samsung store - that do not show the internal appname "com.developer.xxx.xxx" type of name so you can't create folders manually to save the files.

I really don't understand this: Why allow reckless Writing to PRIMARY external storage - which is part of phones memory? If I want to effectively Clean that, I have to reformat/reset the phone.

A SD card or USB memory can be put in the computer and reformatted. Also there is possible to reformat the SD card from inside the settings without touching phone memory...

If I would select, I would rather have PRIMARY external storage protected against reckless Writing, so all the phone's memory is write protected except for the app's own directory, and then write as I want to the SECONDARY storage. (SD Card, USB Memories etc)

[Justin]

Hi Jeff,

If I use a Samsung Galaxy S4 with KitKat running Samsung software (just got the update today), I see the following things...

1.) Samsung's "My Files" app can delete files on the SD card and generally manage the SD card

2.) Samsung's "Music" app can delete songs that are on the SD card

My apps do not have the ability to edit or delete files not in my app's folder. I continue to get emails from customers who are frustrated that I cannot write an app that works as well as the "My Files" app on their device. I'm spending valuable time explaining and explaining why my apps are not functioning as they did in 4.3, and Samsung's still function the same.

If Google is sticking with this sandboxing implementation, it shouldn't authorize Samsung's updates that put third party developers in a bad light.

[Liran Barsisa]

I'm not sure I understand what you are offering, but anything is better than what they did.

They blocked the SD card writing, and left the primary external storage (which is the one that is usually being used and contain more junk) untouched.

They also don't provide an alternative for apps that used the SD card before and provide functionality that is supposed to work on it.

Now all the SD card can be used for on third party apps is for caches and temporary files. nothing more.

[Alan Laas]

The problem as I understand it is with apps that are uninstalled leaving behind various files (config, cache, etc.) that wastes space on the card and decreases the efficiency.  They haven't removed write access altogether for installed apps.  What they have removed is group level write permission such that apps can only write to files and directories they own.  What that breaks is access for any app to affect changes to any other apps files without some system where one app requests that the owning app execute the changes for the requesting app which would be a colossal mess to make work.  What they want is for when an app is uninstalled all the files that it would leave behind to be removed as well which is easy to do if they are all in the same directory.  They also want to set up a System Access Framework where developers are do not have to concern themselves with the directories that the files they are accessing are actually located in.  That part is abstracted.

What I am suggesting is that groups be created for specific file types (media, images, documents, etc.) and apps can request permission to get write access to each specific file type.  That way those files could be shared between the apps that need write access to them and all the other stuff that they are worried about could work the way they want.  And everyone would live happily ever after.

Alan Laas

--

You received this message because you are subscribed to the Google Groups "android-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-platfo...@googlegroups.com.
To post to this group, send email to android-...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-platform.

For more options, visit https://groups.google.com/d/optout.

[Alan Laas]

System apps that are preloaded by the OEM don't have the restriction. Only apps you install afterwards.

Alan Laas

--

[Liran Barsisa]

As Alan Laas said, the permission is granted to system apps, but not to third party apps.

However, maybe you could achieve the functionality via root.

I know it's not a solution for all users, but for power users it might be fine.

[Alan Laas]

For the benefit the others here, here is a really good article on this issue...

http://www.androidpolice.com/2014/02/17/external-blues-google-has-brought-big-changes-to-sd-cards-in-kitkat-and-even-samsung-may-be-implementing-them/

[Alan Laas]

Here is another article that explains some more which also explains why only removable SD cards are the problem and the internal storage isn't...

http://www.androidcentral.com/kitkat-sdcard-changes?utm_source=ac&utm_medium=dlvrit

To maintain compatibility with older systems SD cards are formatted fat32 (so that you can plug it into a computer if you remove it) which doesn't support unix style permissions at the file and folder level (ie. rwx separate for user group and world) everything is set when it is mounted at either read only or read/write.  The internal one is formatted ext and doesn't have to have this issue since it isn't going to be removed anyway.  If the card was formatted ext then this wouldn't be a problem because regular permissions at the file and folder level are natively available.  Since they aren't they have to simulate it in the OS which complicates things considerably.

[Liran Barsisa]

This can't be the reason for what Google has done, because:

1. Google said it's because they want to keep the SD card cleaner.

2. SD card is still reachable - apps can read from it, and they can write to their designated folder there.

So the OS can handle SD cards just fine, even on kitkat. 

[Alan Laas]

That has to be enforced artificially by rules within the OS not by the filesystem though.  They are restricting it to writing within a single path on the SD card if that path exists.  That’s pretty easy to set up and enforce.  However to recreate the granularity of the user/group/world system for all directories and files (even ones created outside of android) and manage that artificially would be far more difficult not to mention trying to do it efficiently.  With the native files system it’s built in and automatic.   That begs a question for me though.  If a person were to reformat their SD card ext2 like the internal one, would the issue go away?  Perhaps some changes to the system would have to be made in order to mount it but I wonder if it would bypass the problem.

--

[Liran Barsisa]

"They are restricting it to writing within a single path on the SD card if that path exists"

what? the path doesn't exist when the app is first installed. 

the app must create its own folder before using it.

if the OS can handle the SD card, any app should be able to do so without any problem. the OS is responsible of letting apps to use the SD card.

That's why built in apps can write anywhere into the SD card. 

The restriction has nothing to do with the format type of the SD card. It worked before, and it can work again.

You can even do it using root.

[Alan Laas]

The path is created by the installer for the app not the app itself.  You don't understand.  It worked before because it was wide open.  The internal storage isn't wide open.  It has the benefit of being able to use file system based permissions to restrict certain files and folders by setting user and group level permissions.  It doesn't have to worry about being compatible with other OS's that will want to mount the partition.  The SD card can be mounted one of two ways read only or read write for all users.  You don't have any granularity beyond that at the file system level.  So it is mounted read/write which is wide open by default.  Then in the OS they have to create rules to restrict it.  That could become complicated to replicate.  You also have the problem of how to handle permissions for data that was added outside of the OS since the data is removable.  They have chosen to make it restricted to a single path.  I still think they should make it restricted to a single path with exceptions by file type to allow people to share documents and data files between apps.

[Alan Laas]

And the change has been in place since ICS.  It’s not new to KitKat.  What is new is that Google is insisting that OEMs don’t simply override it like they did before by threatening to pull their certification for the ROM on their devices.  Here’s a link talking about it where it was discovered early on in ICS back in 2012:

 

http://www.chainfire.eu/articles/113/Is_Google_blocking_apps_writing_to_SD_cards_/

 

Now, for users that root, they can simply go in an modify the platform.xml file the way OEMs like Samsung did to make their devices work like they did before for apps that don’t use root.  It’s just not being done for you anymore by OEMs.  That also doesn’t help developers though that want to make their apps work for people who aren’t willing to root.

[Liran Barsisa]

If the OS can still write to the external storage, the problem is not with the file system that it doesn't allow apps to write there.

The OS can easily grant permission to write to the SD card, and there is already an easy patch for rooted devices to let the OS permit it for third party apps (just one line to add), and some customized ROMs already have it (like CM).

Google could find so many alternative solutions, but it chose differently.

Google has almost completely ruined the whole purpose of the SD card, and I really hope it will change.

SD cards should be used for more than what Google has done (only built in apps, and specific paths that get removed for third party apps).

This marks the end of SD card usage for third party cameras, third party content editing (documents/audio/video/...), and so many other apps , since the files that they create should not be removed when the user uninstalls them.

[David Cakalic]

Excellent example of how this affects the end user.  Also like the office (Kingsoft) example further down this thread.

I can't fathom how Google dev's let this go... except that maybe they've all been given Nexus devices lacking an SD card so it never got tested... never affected them. (Or perhaps they're just jealous of the rest of us?)  These real-world issues would have been obvious to me when I was in 4th grade using an Apple II... if the disk is write protected, I can't save or edit my document or file I just created = lost data = poor user experience.

OK... you want to clean up SD cards... thanks.  You also want to protect us from 3rd party .APK's not from the Play Store too. Understood, I don't mind that.  But do you realize how you solved that second problem?  You put an option in the settings clearly outlining the dangers and risks involved and let me override it. Why could you not do the same here?  You could even bury under hidden developer menu.  

As others have said here, the reasoning Google is doing this is for security doesn't ring true... does that mean my friends Nexus devices are inherently LESS SECURE because apps have full read/write access to internal storage?

Besides, wouldn't the major security issue of a malicious app be READ access in first place?  Seems this was a restriction in search of a real-world problem.  Just as larger hard-drives have made it less necessary to search out duplicate or orphaned files than years past, so too have the larger SD cards.  

Besides... when I uninstall a camera or office app, I don't necessarily WANT it to DELETE ALL MY PICTURES or documents!!! Are you SERIOUS? That action would make me more angry than leaving the orphaned files behind.

Very poor planning and lack of respect for users by implementing this, IMO. And this has been a possibility since ICS?  I don't know what to say. These are common sense situations that potentially affect millions of users - they've been called out in previous articles well before KitKat that I've researched (through Google - you have a search engine guys... use it) and should have been addressed by now.

On Thursday, February 13, 2014 4:58:09 PM UTC-6, Justin wrote:

I'll write a simpler follow up scenario not using my software, just to highlight what a big change this will be for Android users, not just software.

An Android fan plugs their SD card into their camera while on a Safari. They get back to their hut and plug the SD card into their Android device. The camera put pictures in the folder "Camera".

These users will be able to see the photos on their Android tablet, but they won't be able to free up space or modify any of these photos until they get to a computer?

[Alan Laas]

I initially thought like you that the fact that they are limiting the SD card but not the internal storage and claiming it was a security issue didn’t make sense.  That is until I understood the issue better.  The problem is not about whether it is internal or external.  The problem is the file that the partition is formatted with.  SD cards are FAT32 formatted which can be mounted only two ways. Read only and read/write.  That’s it.  At the file system level it is all or nothing for write permission access.   And they have to be FAT32 formatted so that they work when you take them out and pop them in other legacy systems that don’t understand anything else.  However with the internal storage they don’t have this problem.  Since the internal storage is never going to be removed and popped into another system where it would be expected to be able to be mounted and read, they can format it with the ext2 file which has a much more robust permissions system built in.  They can automatically limit or grant access to users and groups at the file and directory levels without having to write a single piece of code for that.  That is where the security issues lie.  I still wonder though if I take a SD card and purposely reformat it ext2 then pop it in to use as just extended storage will it mount and not have this problem.

 

From: android-...@googlegroups.com [mailto:android-...@googlegroups.com] On Behalf Of David Cakalic
Sent: Friday, March 14, 2014 3:28 PM
To: android-...@googlegroups.com
Subject: Re: What about removable SD card in 4.4

 

Excellent example of how this affects the end user.  Also like the office (Kingsoft) example further down this thread.

--

[Alan Laas]

I agree that their solution could and should be better than what they have done.  Still I see their dilemma.  Leaving it wide open is kind of a mess and not very secure.  And I think they will eventually add some nuance to the way it works.  What that will be we will have to wait and see.  If they redesigned the system to make exceptions for specific file types that are typically what end users care about managing and sharing between apps, but locked out the rest to anything but a specific path I think it would accomplish their goal and make everyone happy.

[Liran Barsisa]

it's a good thing to handle the junk folders.

I hate them myself, but since I don't have an SD card (yet), I find this action completely useless since the primary external storage is still not handled by the same action.

This means I have junk folders and files that will remain even after uninstallation.

Google treated only the SD card, and apps usually don't write there and instead they use the primary external storage instead.

What I don't like is that they didn't come up with a solution for apps that should be allowed to write to the SD card, like cameras and other content creation/editing apps.

One easy solution is to make it like the admin confirmation screen that Android has:
If an app needs to write outside of its designated paths (or either the primary external storage or the SD card), a new screen will be shown that asks the user if it should allow it or not.

Since it requires user's confirmation, we enjoy it from both ways.

Apps developers that don't really need to write files outside of their designated paths will need to find the correct way to develop their apps, and apps that do need it will have the user's permission to do so, otherwise they will warn the user that the some functionalities and features will not be available.

[Yonatan Yehezkeally]

1. That it's a potential mess is super relevant when designing a new eco-system. It's immaterial when unilaterally altering the behavior of an existing one, to the degree of breaking functionality (of paid-for products, no less, when the transaction was handled end-to-end by Google itself!)

2. Pointing at Honeycomb as the origin of this change to 'ridicule' current outrage is disingenuous. Now is when Google cracked down on OEMs, so now is when standard users have noticed the policy.

3. As to internal memory running on EXT2/3/4, that's interesting, but if every part of it (at least, any part I ever tried to write to) has rw permissions to all apps, I don't see how that's a relevant argument either.

Finally, I don't see that allowing certain file-types is a comprehensive solution. It might get professional photographers off Google's back, but it does nothing for me (I used to sync certain work and private folders to my external SD card, to have them available wherever I go. Imagine that one of these folders is encFS with encrypted file-names, and you begin to see the problem; Yes, I need root--and FUSE--to mount that folder anyway; but I shouldn't need it for the sync part).

In short: when I got my Android it could do things for me that it no longer can. This is unacceptable, and particularly that it happened without warning (none that I had any reason to be aware of, anyway). Shame on Google, and here's to hoping someone out there finds something actionable about this whole escapade.

[Sebastian Nielsen]

Theres lots of people who advocate "root" here.

The problem is that DMCA laws here in my country prohibit rooting/jailbreaking/such things. The reason is that you will be given access to things that content makers did not expect you to have access to, and thus have not implemented protection (eg Widewine and such) against this, because you aren't expected to have access at all.

Thus the "no-root" on Android Platform is considered to BE the DRM protection, and thus its copyright infringement to remove it (and Google/Samsung can't give permission to root it, only the indivual content owner of ALL media content available to Android, can authorize such things and theres millions, if not billions of different content owners on Android and Everyone - even content not loaded on your phone - needs to say yes since you CAN load such content.). 

So please don't say "Root it" when discussing this SD Card restriction. Even if people are "developers" or "advanced users" and are prepared to root it with the technical and security consequences it may have, they may not have legal right to do so, and can face legal consequences for doing it.

And I really don't understand what the problem is with apps that fill the SD card with garbage and wont remove it at uninstall? If I feel my SD card is full of garbage, I put it into computer, search through it, and then reformats it.

Can I do it with internal memory? No.

So why not apply this restriction ONLY to internal flash memory?

Also Samsung had a very nice way to prevent "dangerous settings" to be exposed to users: To enable Developer options, you have to go to Status screen and tap "Build number" 10 times in a row. The first few taps wont give away that this is a secret "enable Dev menu" sequence.

Why not a similiar thing to enable a setting in Security: "Tap Model number 10 times in a row" -> Shows a hidden checkbox inside Security, that says: "Enable arbitary apps to write to SD card" -> checking pops up this: -> "Warning: If you enable this option, any app can write to the SD card. This means any app can fill the SD card with unwanted files, use it to store files across uninstallations and reinstallations, and even physically damage your SD card, which in turn can damage your phone. This may cause unstable or nonworking phone and/or apps. Do you want to proceed? [Yes] [No]"

To prevent apps from regularly telling users to do this - this could be done in Android Developer Guidelines that a app in Google Play market may NOT tell the user to enable the SD card unrestriction feature. (and publishing apps in Play Market that contain dialog boxes or UI text that tells user to unrestrict SD card, is then a violation of the terms of service - like publishing porn and such)

So the end user has to simply find out how to unrestrict the SD card themselves or Contact the app developer - that may tell the user how to do.

The support pressure will force regular app developers to only store in their personal folders or use SAF because else they will have a high support pressure.

And end users which really want to "mess upp their SD card" can do it.

[Alan Laas]

I am in complete agreement with you about the way they handled this being a major blunder.  Furthermore I only pointed out that they introduced this with ICS (not HC) to highlight that the way they tried to force this covertly a long time ago without regard for who would be affected by it and without any consideration for the OEMs or developers that build on the platform. What they should have done is introduced what they saw as the problem to the community and requested input for how best to address it before hamfistedly trying to force the change on everyone. Still I understand better now where they are coming from (which is also a problem because it took a good deal of research to decipher all of the "why" for this since they choose not to disclose very much in that area. Still as for your specific complaint, as your purposes require root they still will have access.  The problem is for developers who build for the masses that do not care to root or even know not what that is.

[Alan Laas]

As for my file types suggestion, that is coming from the perspective of what most users are concerned with managing when it comes to files. Make no mistake here, you may be a developer that all of a sudden can't do something that you could before and that has upset your apple carr but that means very little compared to what effects this gas on the average users of the platform.

On Mar 16, 2014 10:17 PM, "Yonatan Yehezkeally" <yon...@gmail.com> wrote:

[Liran Barsisa]

About rooting, I know it's not a solution for common users, but you can solve it this way:

1. root the device.

2. use the fix, for example here: http://reviews.cnet.com/smartphones/samsung-galaxy-s4-google/4540-6452_7-35761621-4.html

or do it manually by yourself: http://trendblog.net/fix-kitkat-sd-card-write-restriction/ , http://www.androidheadlines.com/2014/02/galaxy-s4-note-3-kitkat-sd-card-update-issue-youre-not-alone-root-fix-inside.html

3. unroot the device

About "Samsung had a very nice way to prevent "dangerous settings" to be exposed to users" , this is actually Google's decision - it's available on all Android devices. 

However, I think that since SD card isn't such a super user feature, it shouldn't be hidden at all. I think it should work as "admin-rights-confirmation" at most, like what happens when you allow apps to lock the device (try out "Widgetsoid" if you don't know what I'm talking about). 
When the user opens an app that wishes to use the SD card, the app could request to show a confirmation dialog so that the user will know that this is what's about to happen, so the app will be able to use it from now on.

[Alan Laas]

The DMCA has nothing to do with rooting/jailbreaking anything.  It has to do with unlocking the carrier restrictions which is completely unrelated to the any of this.  If you are simply worried about fixing YOUR phone, rooting may be an option for you.  However, if you are a developer trying to deal with countless customers who purchased your app that has now suddenly been broken by this decision and are calling you to complain, rooting isn’t exactly an answer.

 

From: android-...@googlegroups.com [mailto:android-...@googlegroups.com] On Behalf Of Sebastian Nielsen
Sent: Sunday, March 16, 2014 9:59 PM
To: android-...@googlegroups.com
Subject: Re: What about removable SD card in 4.4

 

Theres lots of people who advocate "root" here.

--

[wesley house]

This breaks my daily use of android .
I use File explorers Extensively as well as apps that save to many different places on the EXTsd  .. It should have at MINIMUM been allowed in developer options . This is unusable .
. Unless addressed soon I may have to change platforms when its time to change phones . .

On Thursday, January 9, 2014 1:25:38 PM UTC-6, Jeff Sharkey wrote:

Right, starting in KitKat, Android now offers APIs to access secondary external storage devices.

Apps have direct write access only to their package-specific directories as obtained through Context.getExternalFilesDirs(), Context.getExternalCacheDirs(), etc.  "Direct" access is defined as using traditional file access APIs, like POSIX open().  Direct access to the remainder of these secondary external storage devices remains read-only for apps.

However, apps can create/write files outside of their package-specific directories on secondary external storage devices by using the new CREATE_DOCUMENT intent, which involves the user in the file creation process.

The reason for this design is to ensure that all app data can be effectively cleaned up when that app is uninstalled.

Hope this helps.  :)

j

On Mon, Dec 23, 2013 at 12:32 AM, Andy Panda <loland...@gmail.com> wrote:

Hi,

Since 4.4 was published we found one more change in storage configuration. Now it is deeper that was before because was
changed policy to rich WRITE_MEDIA_STORAGE permission.
So the problem is that non-system applications could not write to external SD (i mean not emulated but real removable one)
I had look inside sdcard service some time and played with fuse options, but could not find right solution how to mount/emulate
SD to provide write access for user installed application (actually non-system one).

So I'm able to open a photo in Gallery application, but I could not save it after some modification was applied.

Storage configured according to guide on source.android.com

--

You received this message because you are subscribed to the Google Groups "android-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-platfo...@googlegroups.com.
To post to this group, send email to android-...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-platform.

For more options, visit https://groups.google.com/groups/opt_out.

--
Jeff Sharkey
jsha...@android.com

[Alan Laas]

As long as you are only concerned with your own phone, rooting provides you options.

For more options, visit https://groups.google.com/d/optout.

[Sebastian Nielsen]

You are wrong.

Carrier restrictions are allowed to unlock as long as the contract with the carrier does not state its their property at least here where I live at least.

So if the phone is yours, you are free to unlock the carrier lock. Theres even services out here that do it for a small fee, so its legal.

(Sometimes the contract will state that the phone belongs to the operator legally until unlocked - then you can't legally unlock it since its not your property. You are not even allowed to sell it on Ebay Before you have unlocked it)

DMCA is about copyright.

Eg, if you rent a online-Movie, and play the Movie, the Movie will be protected with DRM so you can't play the Movie when the time's up and you can't copy the Movie, for example by taking screenshots.

A DRM solution has 2 Components: A encryption - to prevent players that do not understand the digital license, to play the Movie, and a licensing system that tells the player whats allowed to do with the Movie.

The encryption key is then only given to those that can sufficently gurantee that the licenses will be abided.

DRM protections do have protection in law.

On Android phones, theres 2 different types of DRM:

Widevine, which disable itself - or SHOULD according to specification, disable itself if the phone is rooted. So Widevine DRM is not considered bypassed. When talking about Widevine - its safe to root legally, since Widevine does as I said, disable itself when it can no longer gurantee protection is valid.

But then we also have those "home-built" DRM's where a app maker do create their own DRM, and use Androids built-in DRM and protection functions (for example SurfaceView.setSecure()) to prevent content
from being copyed.

Both DRMs have protection in law, and thus if you root the phone, you will for example be ABLE to record content protected with setSecure(), and thus its illegal per the DMCA law to root or jailbreak the phone.

It does not matter if you never will play secured content on the phone - the fact that you disabled the protection is enough.

So no, its illegal to root or jailbreak phones here.

[Jeff Sharkey]

Hi all, this thread is getting a bit off topic.

We've talked about the current implementation as of API 19, and how it now supports interacting with secondary physical SD cards through public APIs.  Before this, secondary external storage was not supported by Android APIs, full stop.

It's also worth noting that apps can gain write access to any location on secondary SD cards through the new OPEN_DOCUMENT and CREATE_DOCUMENT intents, because they involve the user in the file selection process.

Thanks everyone for sharing their feedback and use-cases.  The Android platform is continually evolving, and new behavior may be added in future platform releases.

If you have additional questions as a developer, Stack Overflow may be a better place to ask, as this mailing list is focused on Android platform internals.

j

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-platfo...@googlegroups.com.
To post to this group, send email to android-...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/d/optout.

--
Jeff Sharkey
jsha...@android.com

[Liran Barsisa]

But will the new API allow you to make batch operations (multiple-deletion/adding/modifying of files), and also make silent operations (that won't need any user interventions ) ? 

What would be of third party camera apps? Will they need the user confirmation of every picture being taken?

What you've written barely supports the Office-like apps. There are so many other cases.

No matter how you look at it, it's a huge limitation compared to the previous state.

Google didn't support SD cards? How about the first Nexus device? It had SD card support already. 

Sure, it didn't have another external storage (as far as I remember), but it's still the same functionality that all other devices have.

With a little help, even Kitkat can be installed on this device.

[Yonatan Yehezkeally]

Jeff, with due respect, I find your reply dismissive and offensive.

The use-cases posted herein suffice to demonstrate that this (new) move by the Android team truly amounts to a bug--not a feature--in KitKat. You did *not* contend yourselves to creating new API's; you actively broke existing functionality, without offering satisfactory alternatives.

While I don't know that I can expect Google to host such things, know that unless the team acknowledges the validity of this point of view, you can expect to continue to receive bad press on the issue, and lose customers over it.

Thanks for issuing a comment,

--Yonatan Yehezkeally

On Wednesday, March 19, 2014 8:14:38 AM UTC+2, Jeff Sharkey wrote:

[David C]

Very disappointed - Three points

1) been using Galaxy Note 3 (on Android 4.3) as a mini PC, managing files and storage on SD card and NAS drive over WIFI. This will no longer be possible if I upgrade to Android 4.4

2) Was planning to buy a tablet running Android to effectively replace my PC since using my note 3 was so effective. Will now have to bin that idea and will have to look at windows 8.1 on a tablet instead.

3) If I make the switch to a windows 8 tablet then why stick with an android phone

See where I am going with this...

I actually just moved from an Apple iPhone (owned two over the last four years) to the note 3 choosing Android for its supposedly more open approach to users and the Note 3 for its SD Card slot - shame to see the two benefits disappearing. Hope Google rethink this strategy.

[Sebastian Nielsen]

A problem with using the OPEN_DOCUMENT intent or CREATE_DOCUMENT intent, is that its not possible to open() the file afterwards.

You have to use the provided file descriptor. And proprietary C++ NDK's does not support file descriptors.

What about doing OPEN_DOCUMENT and CREATE_DOCUMENT like the Contacts system - eg when you OPEN_DOCUMENT or CREATE_DOCUMENT, on a SD card, your app will gain temporarly permission to POSIX open() and write to just the file on the SD card that the user selected in addition to the file descriptor returned?

So if you use OPEN_DOCUMENT or CREATE_DOCUMENT, and the user selects a file, its up to you if you want to open() the file yourself, or read/write to the file descriptor that the intent returned.

[Liran Barsisa]

Not sure if what you've offered is practical, but anything is better than what Google has done here.

I just can't believe it has happened.

I have a solution (using root), but so many normal users won't. 

Why does Google go in this path? I even keep seeing more and more phones with non-replaceable batteries.

[Jeff Sharkey]

Right, the SAF intents return a content:// Uri, which you can open using ContentResolver.openFileDescriptor().  If you're working in native code, you can call ParcelFileDescriptor.getFd() to get the raw int, and pass it across JNI to make any desired syscalls.

However, be aware that the FD will not always be a regular file on disk.  For example, some SAF providers implement storage with pipes, like the Vault example that encrypts all data stored inside:

https://plus.google.com/+JeffSharkey/posts/9BmGb3xbPcA

Once you're done, always be sure to call PFD.close() or PFD.closeWithError() to signal the remote process that you're finished.

j

--

You received this message because you are subscribed to the Google Groups "android-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-platfo...@googlegroups.com.
To post to this group, send email to android-...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/d/optout.

--
Jeff Sharkey
jsha...@android.com

[Kruse Ludington]

Does KitKat still allow a person to move an application to or from the SD Card in the app settings under the Application Manager?

[Jeff Sharkey]

Yes, if the physical SD card is configured as the primary external storage device then moving apps to the SD card is supported.

j

On Thu, Mar 20, 2014 at 4:02 PM, Kruse Ludington <rklud...@gmail.com> wrote:

Does KitKat still allow a person to move an application to or from  the SD Card in the app settings under the Application Manager?

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-platfo...@googlegroups.com.
To post to this group, send email to android-...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-platform.

For more options, visit https://groups.google.com/d/optout.

--
Jeff Sharkey
jsha...@android.com

[Miagio Gates]

Hi all , bad luck here as new to android etc got the note 3 with 4.3 a month and worked fine , by accident updated the f 4.4.2 and all messed up...
Q: Is it possible to use a file explorer and give the read/write permission to the ext.card ? like with right click in windows ? will that be accepted by the system ?

Sorry for the maybe silly question i m aged and know nothing about phones ...what affected in my phone was the use of navigators that cannot reead the f maps

G.

[Liran Barsisa]

You can fix this restriction issue only by root, and this is something I've already written about how to do it, here:

https://groups.google.com/d/msg/android-platform/14VUiIgwUjY/5FnxnIRDorsJ

[Mike Stanley]

I agree with the pushback against the latest SD card permission behavior.

I write business apps where we don't want to be limited on the sd card, and certainly not auto-delete files on uninstall.

Yes, I understand what the workarounds are, but this adds to the list of changes being focused on casual app/gaming or cloud/social-network stuff.

There are more use cases to mobile devices than taking pictures and playing games.

Mike

[Alan Laas]

Built in file explorer should still have read write permissions the same as before. Just 3rd party ones lose it.

--

[Miagio Gates]

As i understand no way to solve the prob without root (that affects warranty) the phone ...also samsung service denied to install the 4.3 over the 4.4.2 and washed their hands ...

[David Camilleri]

Completely agree. Currently using an Android 4.3 phone and sd card to manage files, down load and organise files including on my NAS drive. Basically substituting my main PC. If I upgrade to 4.4 can't do that. Staying on 4.3 indefinitely until this is sorted or my guarentee is up and I can root my phone. Was going to get an Android tablet but now looking at windows tablet instead.  Very poor move Google.

[Alan Laas]

You should still be able to manage files with the apps that were preloaded on the phone though.

On Mar 21, 2014 2:16 PM, "Miagio Gates" <mia...@gmail.com> wrote:

As i understand no way to solve the prob without root (that affects warranty) the phone ...also samsung service denied to install the 4.3 over the 4.4.2 and washed their hands ...

[virtual]

This KitKat limitation on the External SD card write permissions is causing a lot of debates over the Internet!
Some people are OK with it (mostly those that don't have an SD card on their phone either), but a lot are disappointed for that decision and even won't upgrade to KitKat.

If you see on the Android Open Source Project Issue Tracker website, there are every day new tickets opened due to this problem with people and developers complaining for the missed feature they used before. Unfortunately, those tickets are closed without appeal.

Do you guys at Google think you can reconsiderate your decisions for the future?
I mean at least providing a new permission (so the apps have to be updated anyway) to grant 3rd party File Managers to write, delete and create files in any folders as before?

For most of the applications world-read access and write to their own folder on the Ext SD is enough, but not for ALL.
Not to mention the other problem with the removal of the files during uninstallation of the application.

And about file scattering over the memory cards, I would like to ask how many people have more folders and files (created by applications) on the external SD card than on the internal one? Normally the mess is in the internal storage and there nothing has changed.

Sorry for the long post, but I wanted to express my feelings (even though I'm still with Jelly Bean).
Bye

[Liran Barsisa]

I agree with almost all of what you've written, and in fact it's part of what I've written too (just a few posts above).

I write almost, since the solution of adding a new permission might not help , as apps that used to leave junk files will still be able to do so by just adding this permission...

I also write that it might not help, because maybe this way it will teach developers that this is a bad thing to do (to leave junk files).

[Boris bvaisoft]

Jeff, 

Is there are any way to rename, delete files, create, delete directories? As you probably know in order to create a file in a safe way - a temporary is written first then renamed after all data is written. It looks like a half baked api at most, not mentioning that it requires user intervention. 

As for the sd card new policy - very strange move from Google, I won't be surprised if a class action lawsuit is filed.

--

Regards, Boris.

[Miagio Gates]

well , i dont know bout google democratic behavior as per this issue (closing tpics etc) , i bought a samsung and i expect from them a solution NOW or to turn me back to WHAT I BOUGHT._

[Miagio Gates]

who erases the comments ? and why ?

[Miagio Gates]

who deletes messages ?

[Miagio Gates]

if you dont like us close the topic as you prolly wish

[Jeff Sharkey]

The responsibility for reliably persisting a file rests solely on the SAF provider, since it's in the best position to implement any rollback strategy.  For example, renaming as an atomic update operation is only relevant for files residing on traditional filesystems.

SAF providers can use ParcelFileDescriptor.checkError() to detect client errors/crashes, and recover as needed.  SAF clients can use PFD.closeWithError() to communicate errors to the provider.

For example, Vault uses temporary files to offer an atomic rollback strategy in writeMetadataAndContent():

https://android.googlesource.com/platform/development/+/master/samples/Vault/src/com/example/android/vault/EncryptedDocument.java

The ExternalStorageProvider built into the platform could be extended in a similar fashion, but it's not as straightforward.  Vault uses well-defined filenames, so it has the flexibility of adding ".tmp" suffixes to mark temporary files, but we don't have that luxury on raw external storage devices where any filename is valid.

j

[Kristopher Micinski]

On Sun, Mar 23, 2014 at 12:16 AM, Boris bvaisoft <bvai...@gmail.com> wrote:
> As for the sd card new policy - very strange move from Google, I won't be
> surprised if a class action lawsuit is filed.

Whatever your viewpoints on the policy, it seems very inappropriate to
suggest (in a threatening manner) that someone will take legal action
against Google. There is no basis to suggest that legally, and the
topic of ascertaining whether there is is completely off topic from
the designated topic of this discussion forum.

Kris

[Boris bvaisoft]

Kristopher,

I don't suggest anything, neither threaten anyone. This is a hint to Google of what's going on public forums. Are you a moderator on this forum?

[Boris bvaisoft]

Jeff, 

This works as long as no app crash happens. Say, a normal file write operation would be to clean up temporary files upon app restart or card reinsertion. But with SAF one would need to go with File Picker UI to obtain file descriptor just in order to remove  corrupted temporary files, am I correct here? How can parsel file descriptor be obtained without File picker intents, i.e. without UI? Can't find much documentation on it, any android source code reference would help a lot.

--

Boris.

[Jeff Sharkey]

PFD.checkError() also detects remote process crashes, allowing a SAF provider to rollback corrupt/partial writes.

The OPEN_DOCUMENT and CREATE_DOCUMENT intents return a Uri, which you can open with ContentResolver.openFileDescriptor() to obtain a ParcelFileDescriptor for reading/writing.  You can also use ContentResolver.takePersistableUriPermission() to persist long-term access to these Uris, across process launches or device reboots.  As long as you have a Uri permission grant, you can call openFileDescriptor() without showing any UI.

The SAF provider is responsible for management/cleanup of any temporary files, since they're an internal implementation detail of the provider.  A related example is overlapping writes to the same document; the SAF provider is responsible for merging any changes, or prompting the user to resolve them.

The platform ExternalStorageProvider currently doesn't offer this functionality; it always writes in-place.

j

[larry...@seriousgamesinternational.com]

I've delved around with Unity, and the prognosis is that apps REALLY REALLY need write SD permission. Google, I know you're looking to Apple for inspiration (don't deny this), so you should know this is a sticking point for Apple users.) If it must be restricted to directories, then have each app implement that list, not lock it to some predefined thing that can only be conveniently overridden if you're in bed with the OEM. 

* (wildcard) must be an option too.

I don't mind if you trash the cache and chaff when uninstalling stuff (you SHOULD do this to internal storage anyway).

I don't mind if in future we only get to use ExFAT or ext2 or such on SDCards, since I agree we should be moving away from FAT32 anyway. You get a more secure filesystem on your card, which is exactly what Android needs, without the need to implement kneejerk hacks like completely trashing a useful feature. 

But there must be a mechanism to allow applications to access more than one directory in the SD card. This mechanism should also allow users, not just developers, and absolutely not just the ones in bed with the OEMs, to define the directories written to, even if it is not the same as the app's install directory. If you don't want crap to be written willy nilly fine, mandate this field be FILLED upon app install, but let the user sort out the mess later.

The Cloud is not a solution; Check my country, one of the most connected in Southeast Asia (by virtue of the number of people having 3G plans). 2 years ago ALL telcos reduced their generous data plans from 12GB to 2GB. We don't have the consumer pressure capable of undoing this decision. Businesses are the only ones receptive to the Cloud right now.

Internal Storage is not a solution. 90% of all devices have less than 16GB of storage. 99.9% of all devices are partitioned for much less actual space. The sole exception is Google developer devices, which unfortunately are not bound to any telco and most cannot afford. >_>'

Asking people to root their devices draws the ire of manufacturers and places unnecessary technical burdens on them, don't do that. 

-- Do NOT contribute to E-waste, do not build in obsolescence. --

[Ricardo de Almeida]

I agree, for people like me that use third party file managers kitkat is horrible. And i use much. For me this is so serious that with that limitation makes no sense to me to have a smartphone/tablet whatsoever. I moved to IOS to Android because the freedom that Android offers. Now they destroyed it. I will stay in 4.3 as long as i can, but very dissapointed.

[Jeff Sharkey]

Could you elaborate more on exactly how Unity would like to write to secondary external storage?  Is there a specific reason it cannot use the package-specific directory, which it has full write access to?

j

--

You received this message because you are subscribed to the Google Groups "android-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-platfo...@googlegroups.com.
To post to this group, send email to android-...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-platform.

For more options, visit https://groups.google.com/d/optout.

--
Jeff Sharkey
jsha...@android.com

[Liran Barsisa]

Actually games and games engines (like Unity) shouldn't usually need the secondary external storage.

Maybe in very rare cases.

Is it perhaps a requirement of the Unity framework?

[Boris bvaisoft]

That's fine for individual files, but how about directories. Say I want to code a simple app to unzip an archive containing multiple files to a Video folder on external sd card and setting files modified time stamp to the original. Is there any way to do it using either SAF or any other method?

[Miagio Gates]

ppl all we need is the reverse procedure by manufacturers (like samsung that denies it) so we can go back to a WORKING ANDROID VERSION._

[Mike Stanley]

Yes, why not allow both? If apps want to use cloud or some bureaucratic method, they can do that. Other apps (the ones I prefer), save files to directories and can be inventoried and selected from with standard file I/O. I thought I needed to go to iOS to be told there's only one way to do things.
At least allow for a new permission, I suggest this warning for the user, "this app will access the sd card like any app you've ever run on a PC"

[denis]

The disappointed people can be counted also by the number of installations of this app:

https://play.google.com/store/apps/details?id=nextapp.sdfix

which of course requires ROOT.
And this does not include people that fixed the permission manually :-)

[Miagio Gates]

We re talking to walls , they decided for me and pushed the garbage 4.4.2 , sent my sd (64gb SAMSUNG) to the garbage and now they lough maybe ?
Shame , who could think that irresponsibility ...congrats , seems that nowadays decisions are taken by 20ers or kids maybe between an apple and an orange ...

[Richard Barley]

I've read a lot of these posts but all I need to know is 'what is google going to do about it?'
It's all well and good them trying to push us towardscloud storage but for me there are these issue
1 - it's MY device and I should be able to do what I want with it and that includes having access to the sd card facility that I bought it for (tegranote 7)
2 - this is a non-sim tablet so how the hell am I supposed to access the 'cloud' when I've got no wifi?
3 - I don't want to have to keep taking the sd card to my desktop whemever I want to edit something on it.
I don't want to go down the rooting route (why should I have to mess with my OS just to get it working the way it was when I bought it?)
Come on Google - FIX IT
Richard

[Miagio Gates]

thx R.Barley , very precise and straight.

[Alan Laas]

I certainly understand your sentiment which is typical and ultimately growing. Still from what I have read, I understand why they are doing this to a certain extent. FAT systems are horribly outdated and insecure. Yet to maintain compatibility with legacy systems that are still in use everywhere, the SD cards are formatted with FAT32. What I don't understand is why Android can't just treat cards this way only if they are formatted as FAT32. Sure ext2 formatted cards wouldn't be able to be popped into many systems without add-on software being installed, but at least there would be an option where apps could work properly without severely limiting the functionality.

Alan Laas

[Jenny Loola]

I would just like to echo the sentiments on here that not having access to the SD card is causing me major problems in my work as a lawyer. I used to be able to use an app to synchronise current research and client documents to my phone (I currently have about 30gb of pdfs and word docs which I need to update regularly as the case progresses). Using the devices SD card meant that I could synchronise my work saved on the server with my phone, PC and tablet so that I could really work on the go.

 

With a 64GB card, there was also enough room to synchronise recent photos and music from my home NAS.

 

On my Galaxy Note 3, there IS no system app which will let me access server or NAS files, so there is now no way I can get to these. I really appreciate all the work that various developers have done to give us the tools to use my phone & tablet to their fullest capacity, and I am appalled that Google left it for me to spend valuable time wondering if perhaps my new SD card was faulty (tried swapping them around etc) before I discover online that they have just decided to block the user's access to functionality on their own device!

 

Security should be an individual's responsibility and there are plenty of options which enable you to use your SD card and/or prevent unauthorised access.

[Yonatan Yehezkeally]

Precisely where I'm at.

Jeff, could you perhaps help developers overcome this hurdle by answering the following:

(a) Is it possible for an app to 'take ownership' of a folder on external memory outside its dedicated path? Is it possible for several apps to 'share ownership' (a la group permissions), so that the folder would remain in tact as long as not all apps are removed? For that matter, might user-input be utilized to 'protect' a folder from removal upon removal of its parent app?

(b) What happens when an app creates a folder on the internal memory? What permissions does that folder receive, and how come every other app can access it and change its content? Why does it persist regardless of removal of its parent app? (In short, hearing about ext2's advantages in this regard, I'd like to know how they're utilized on the internal memory, to better understand how the situation is different with the external one.)

(c) Naturally, if you could see your way clear to allow reformatting of the SD card with a different FS as means of relaxing these restriction, I assure you that such a feature would be very much desired.

[Alan Laas]

As I explained earlier in the thread, the internal storage uses the ext2 filesystem format which supports user and group permissions at the filesystem level which is why it isn’t a problem for the internal system as folders and files can be created with more granular permissions that can be used to grant or deny access where needed at the user or group level.  However the FAT32 filesystem does not have this.  I can be mounted two ways - read only or read-write.  Mounting it read-write allows write access for all users which is not very secure.  To overcome this they have built in the restrictions at the OS level.  Restricting apps to write access to a specific folder isn’t terribly difficult to accomplish and manage but trying to recreate the granularity of permissions that is built into the ext2 filesystem at the OS level would be very complicated to try to do.  This is part of the problem.

--

[Simon Kenyon]

my first linux system used umsdos to run line on top of a FAT filesystem.

maybe this could be resurrected.

On 27 Mar 2014, at 15:57, Alan Laas <visions....@gmail.com> wrote:

As I explained earlier in the thread, the internal storage uses the ext2 filesystem format which supports user and group permissions at the filesystem level which is why it isn’t a problem for the internal system as folders and files can be created with more granular permissions that can be used to grant or deny access where needed at the user or group level.  However the FAT32 filesystem does not have this.  I can be mounted two ways - read only or read-write.  Mounting it read-write allows write access for all users which is not very secure.  To overcome this they have built in the restrictions at the OS level.  Restricting apps to write access to a specific folder isn’t terribly difficult to accomplish and manage but trying to recreate the granularity of permissions that is built into the ext2 filesystem at the OS level would be very complicated to try to do.  This is part of the problem.

 

[Alan Laas]

I think the issue there may be performance.

[Yonatan Yehezkeally]

Dear Alan Laas, I don't know if perhaps you're replying to someone else's post, but it was my intent to convey that I'm not only familiar with the differences between FAT- and ext-variants, but I'm also aware (and appreciative) or your previous illuminating posts pointing at their relevance to this policy of Google's. I'm sorry if my chosen words didn't reflect that.

The question remains, however, how these differences are put to use. What permissions do folders on the primary external memory receive upon creation, and how does it work that apps are free to create and delete folders, change the contents of another app's folders, and leave their files behind when they're removed? What is it exactly that Android *does* (not what it *could* do) on primary external memory and cannot do on secondary external memory, due to the FS difference? Without that information, we're at a loss for the precise issues this policy is aimed at (and possible ways to go about addressing them).

Of course, another valid question (which you've raised yourself) is why the division should be based on primary/secondary memory, rather than FS (that is, why can't I reformat my SD card to ext4 and be done with this issue)?

I'm sure you can appreciate how leaving us in the dark regarding these issues is part of the problem here.

[Alan Laas]

I’m sorry I think I may have misread your post.  I haven’t looked myself but I’m wondering if you can’t find out what the user/group permissions on some of the files and folders in the primary storage simply by installing a terminal app and doing a ls –al on one of them. It appears that the user / group permissions on my device (which is rooted but still 4.3) for the directories in /sdcard (primary storage) are as root.sdcard_rw.   And yes, I am in complete agreement about how they seem to be very selective about what questions they choose to answer and which one’s the conveniently don’t.

[Frankie Moran]

Lets just say I am completely annoyed at this choice to remove the SD card from Android users. I just bought a new HTC One M8 comes with an option to have an SD card great went bought class 10 64GB only to find out its bloody worthless. What option do I have but to Root my device? Really GOOGLE you want to force people to root there device just so I "We" can have the user experience we pay for.

 Well and truly shocked at this choice, I have 10GB internal space free we have Games coming out that are 2GB in size Guess WHAT GOOGLE my data is filled up before you even know it. £450 for a phone that cant even have more that couple high end games.

**** YOU

 

[Nicholas Wong]

So Android is slowly moving towards Apple's direction, i.e. limitation.  

Why can't the bloody Google understand why is it that people have moved from Iphones to Android phones?

I never use HTC because they are very similar to Iphones, non detachable batteries and no external SD. 

Sigh. Never repair what is not broken. 

 

[Miagio Gates]

 Is there any samsung tech wondering the damage they made ? Are they a queue of google ? Their time is running ...Obviously we all have suggest all friends NOT to upgrade the stupid kitkat kidish garbage and ready to go ...

[Liran]

Isn't it possible to move apps to the SD card?
Also, don't apps that take more than 50MB use the SD card (or external storage) for the extra storage (up to 4 GB), using the expantion library:
http://developer.android.com/google/play/expansion-files.html
?

--
You received this message because you are subscribed to a topic in the Google Groups "android-platform" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-platform/14VUiIgwUjY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to android-platfo...@googlegroups.com.

[Frankie Moran]

Will Google make some changes for the good in the next Android release?

[Henry Kwan]

I would like recommend any friends and relative to upgrade to Android Kitkat 4.4 because of this issue. 

[larry...@seriousgamesinternational.com]

It used to be possible. 

Now the process is:

1. Not visible to the user, Move To SD is usually disabled.

1a. Legacy apps compiled using older SDKs which still had the move enabled, will still have the Move To SD button present and enabled, but it will only move to Internal SD, not External SD anymore. Of course you can cheat and mount external as internal, but that's not helping. 

2. Now works like this: will base space requirements on Primary. If you don't have enough space on Primaryl, TOUGH LUCK, you shouldn't be installing 500MB games and apps anyway, complain to the developer. Primary is defined as the partition your OS is installed on, not the other one which is known as Internal SD to some OEMs. If you only have 1GB because Samsung says so, TOUGH LUCK, even if you have 7-11GB more sitting in your Internal SD, go look for Samsung not us.

2a. It's supposed to be the developers responsibility to package their apps in such a way that upon install, there will be a data folder in Android\ in the Internal SD. This data can be downloaded separately. Or at least, that should be the way. Luckily, most game engines have already caught up and do this automatically. 

2b. No you cannot move anything to External SD. Root your device or something and use a third party app.

They didn't want you to move apps to External SD simply because it generally uses an unprotected filesystem, and they do not want to mandate the use of Ext or pay for NTFS or exFAT; This is regarded as dangerous for app data. Too bad Android is intended to be a connected OS with multiple users, otherwise the devs will gladly look the other way like Windows Mobile did.

It doesn't help that Android's Low Memory warning is pretty anal and will literally disable All The Things when it comes on when there's still 100MB left in your 1GB partition. Just one of the other bad ideas, like removing mass storage drivers when their MTP doesn't work properly on anything other than Windows*.

* Fix Android File Transfer on Mac pls: everyone's on Mavericks now, and it simply isn't as stable as it was on Lion - keeps disconnecting my dev devices requiring a reboot, while ADB still works... alternatively you SHOULD put mass storage back, it was useful on a Raon Everrun, and it is similarly useful here. I know Apple hates your guts but that isn't an excuse. >_>'

[Frankie Moran]

So you saying because Google made this change its Tough LUCK to me? So after spending £450 on a New HTC One M8 with 16GB storage 10GB available to user and I also have 64GB SD card. Its Tough LUCK how I want to control my data? Games are becoming more demanding on Mobile some are already 2GB in size I should have the right to have most the games data onto the SD card if so I wish ITS MY DATA, MY PHONE

[Ricardo de Almeida]

Let me ask something. Does Google care about we think? Or we are just invisible to them?

[Ricardo de Almeida]

[Ricardo de Almeida]

[Miagio Gates]

Only way is legal act against the beast , if you just talk they put you in garbage ...

[Dianne Hackborn]

On Mon, Mar 31, 2014 at 9:48 PM, <larry...@seriousgamesinternational.com> wrote:

It used to be possible. 

Now the process is:

1. Not visible to the user, Move To SD is usually disabled.

1a. Legacy apps compiled using older SDKs which still had the move enabled, will still have the Move To SD button present and enabled, but it will only move to Internal SD, not External SD anymore. Of course you can cheat and mount external as internal, but that's not helping. 

That is not true at all.

Apps on SD card was implemented for the old storage layout where internal storage was a relatively small partition on the device's built-in storage (typically < 1GB) and external storage was on a dedicated SD card.  Apps can indicate whether, in this configuration, they are allowed to go on external storage, because some types of apps will break when they do so.  (For example a home app if on external storage would disappear when external storage is unmounted for USB access, which you Really Do Not Want To Happen.)

In Android 3.0, a new storage layout was created which makes more sense for devices that increasingly have large amounts of internal storage: external storage is instead mapped to a directory on internal storage, so "internal" and "external" exist on the same shared storage space.  This greatly simplifies the user experience for such devices, since the user can just install apps and take pictures and otherwise use their storage without having to deal with running out of space in one place when they have lots of space in the other.

For example, the Nexus S would have been much better if it was using this system.  However, we didn't have that facility at the time it was created, so instead had to hard partition its built-in 16GB storage so that 1GB of it was the internal storage partition and about 14GB was a separate FAT filesystem for "external" storage.

So what is wrong about your statements:

1. Apps on SD card is not removed, it has never been removed, and it is still available for devices that are configured with internal and external storage on separate partitions (which typically means external storage is an SD card).  This is still a valid configuration of the platform, though it doesn't make sense on devices that have a lot of built-in storage.

2. "Legacy apps compiled using older SDKs which still had the move enabled" is completely wrong, I can't imagine where this is coming from -- there is *no* difference in behavior of whether an app can go on the SD card w.r.t. it being a "legacy" app.  The only thing at all is that of course in Froyo when we introduced apps on SD card, we had to assume that no existing apps could be moved to the SD card.

3. Apps on SD card as implemented in the standard platform has only ever been able to move an app to the single "external" storage location when that is truly a separate partition.  Manufacturers may have modified the platform to allow you to move apps to other SD cards (besides the normal external storage wherever that may point to), but this has never been a feature of the platform, and I don't think any changes in 4.4. preclude continuing such a feature.

Along those lines, keep in mind: until Android 4.4, the official Android platform has not supported SD cards at *all* except for two special cases: the old school storage layout where external storage is an SD card (which is still supported by the platform today), and a small feature added to Android 3.0 where it would scan additional SD cards and add them to the media provider and give apps read-only access to their files (which is also still supported in the platform today).

Android 4.4 is the first release of the platform that has actually allowed applications to use SD cards for storage.  Any access to them prior to that was through private, unsupported APIs.  We now have a quite rich API in the platform that allows applications to make use of SD cards in a supported way, in better ways than they have been able to before: they can make free use of their app-specific storage area without requiring any permissions in the app, and can access any other files on the SD card as long as they go through the file picker, again without needing any special permissions.

I'll leave this with a few more responses:

 

2. Now works like this: will base space requirements on Primary. If you don't have enough space on Primaryl, TOUGH LUCK, you shouldn't be installing 500MB games and apps anyway, complain to the developer. Primary is defined as the partition your OS is installed on, not the other one which is known as Internal SD to some OEMs. If you only have 1GB because Samsung says so, TOUGH LUCK, even if you have 7-11GB more sitting in your Internal SD, go look for Samsung not us.

This is also just wrong.  The typical partitioning of a device's built-in storage is:

(a) The read-only system partition.

(b) The read/write data partition.

(c) The hidden cache partition.

Applications are installed on the data partition (barring apps on SD card), all application private data goes on the data partition.  The "OS" is not installed on the data partition, that is on the system partitions, which nobody can write to and never has been possible to write to.

I assume when you say "Internal SD" you are talking about the whacky partitioning like the Nexus S, where internal and "external" storage got their own partitions.  First, as I said, nothing about the capabilities of this layout has changed in 4.4, it still works exactly the same.  Second, *nobody* should ever want to ship a device like this since 3.0, since the unified internal/external layout is better in every way, and lets you freely use that storage for everything you want however you want.

 

2a. It's supposed to be the developers responsibility to package their apps in such a way that upon install, there will be a data folder in Android\ in the Internal SD. This data can be downloaded separately. Or at least, that should be the way. Luckily, most game engines have already caught up and do this automatically. 

This is only relevant for large apps.  This was a kind-of hack introduced for when we had the hard partitioning between internal and external storage, allowing very large apps to put their content as a separate large file on external storage.  Note that in the modern layout internal and external is the same storage space, so there isn't really any benefit of putting large data there.  (But it is still useful for cheap devices that still have a small built-in storage space so continue to rely on putting external storage on a separate SD card.)

 

2b. No you cannot move anything to External SD. Root your device or something and use a third party app.

If your device is set up with the classic internal/external storage split, yes you can move apps to SD card, and nothing about this has changed in 4.4.

 

They didn't want you to move apps to External SD simply because it generally uses an unprotected filesystem, and they do not want to mandate the use of Ext or pay for NTFS or exFAT; This is regarded as dangerous for app data. Too bad Android is intended to be a connected OS with multiple users, otherwise the devs will gladly look the other way like Windows Mobile did.

And this is just a complete outright lie, since Android has in fact supported putting apps on the SD card, on a FAT filesystem, since Froyo, and this implementation has always been done by putting the app in an encrypted container within that FAT filesystem so that it gets the proper permissions.  And this continues to exist and work today in the platform, as long as you have a device with this old school layout.

 

It doesn't help that Android's Low Memory warning is pretty anal and will literally disable All The Things when it comes on when there's still 100MB left in your 1GB partition. Just one of the other bad ideas, like removing mass storage drivers when their MTP doesn't work properly on anything other than Windows*.

This is actually pretty important because flash storage performance falls off the cliff as you start to get past those limits.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[Justin]

Hi Dianne,

Thanks for taking the time to straighten out some facts in this forum.

Can you address my question about KitKat SD support? I have an app that syncs music files over USB or WiFi, customer's choice.

1.) When syncing over USB to a KitKat device's SD card, where should I put the users music files? If I put them in the "Music" folder, then the user cannot delete the songs, or edit them from Android's third party apps. They cannot free up space without a desktop computer. Further, they will have duplicates if they sync over USB and WiFi, as the sync locations would be different. (Samsung compiled their music player as a system app with permission to edit the SD card, just FYI)

2.) If I sync files to over USB or WiFi to "Android/data/<My Package Name>", then my app can edit/modify the files if I provide a software interface to all other music players and they adopt it. Further, users will not get duplicates if they sync over WiFi and USB. However, if you place an MP3 file in your "Android/data/<My Package Name>" folder, the media scanner will not populate the files into the Android media store properly. See my issue report on this. So music players do not see the music files copied to the device with this method, unless I write my own media scanner and manually populate the Android media store.

Both option #1 and option #2 have serious drawbacks for my users. One way results in duplicates and no ability to remove music without a computer. The other way results in having to implement a full media scanner on my own. What is your guidance? Further, is there anyway to get the media scanner to treat "Android/data/<My Package Name>" files like media files?

-Justin

[David C]

Thanks you for your reply. As a user, not a developer, I would like to point out that, to put it simply, I don't like what you have done. Therefore, whether rightly or wrongly, it is seen as a step backwords. I am now looking at alternatives to Android (and so are many others). Now Google can ignore us, however Microsoft did that with Windows 8 and look at how well that worked for them.

[Yonatan Yehezkeally]

Dear Dianne, thanks for commenting.

On Thursday, April 3, 2014 4:44:03 AM UTC+3, Dianne Hackborn wrote:

Along those lines, keep in mind: until Android 4.4, the official Android platform has not supported SD cards at *all* except for two special cases: the old school storage layout where external storage is an SD card (which is still supported by the platform today), and a small feature added to Android 3.0 where it would scan additional SD cards and add them to the media provider and give apps read-only access to their files (which is also still supported in the platform today).

Android 4.4 is the first release of the platform that has actually allowed applications to use SD cards for storage.  Any access to them prior to that was through private, unsupported APIs.  We now have a quite rich API in the platform that allows applications to make use of SD cards in a supported way, in better ways than they have been able to before: they can make free use of their app-specific storage area without requiring any permissions in the app, and can access any other files on the SD card as long as they go through the file picker, again without needing any special permissions.

-- 

Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

Respectfully, this is disingenuous (at best, considering that the real issue here has been spelled out so many times above). Vanilla Android might or might not have supported the use of secondary external memory before 4.4, but popular vendors included that support in their products. What you guys did here wasn't just adding your own mechanism for utilizing secondary external memory (that is, honest to God 'external' SD cards, not ones that are welted to the phone's internals), but also crack down on vendors to force them into breaking their support for it.

Fact: until now anyone using a Samsung device could use whatever program to manage whatever part of their removable SD card (which includes 3rd-party camera apps, 3rd party music players, file managers, syncing apps such as Folder Sync, and various other use-cases that have been mentioned throughout this thread). HTC did the same with those models that allowed a removable SD card. So did others, but it hardly matters. This option is gone now, and with it the possibility of carrying around your data on your phone for anyone for whom 10-30GB (depending on their model) isn't enough. I'm not among that unlucky number (thank God), but I'm frankly still livid. I shouldn't have been made to figure out on my own why my music and docs stopped syncing to my SD card, never mind loss of access to current files until I figured out there was a problem.

Needless to say (considering I'm in the middle of throwing a fit here), feigned innocence does little to alleviate my dissatisfaction. Be frank about what you believe, what you did, and why you did it. I might not like it; I might even decide to leave Android behind. But it wouldn't leave me wishing for a Google/Gmail/Gdrive/Gcalander alternative.

[Emile Belanger]

>Along those lines, keep in mind: until Android 4.4, the official Android platform has not supported SD cards at *all* except for two special cases...

SD Cards have been used extensively and successfully since Android 1.0 by many manufactures WITHOUT issue. I have *never* heard anyone say "I wish my SD Card was totally locked down so I can not write to folders I wish"

>Android 4.4 is the first release of the platform that has actually allowed applications to use SD cards for storage

WRONG, Android 4.4 is the ONLY release to STOP applications using the SD card, why do you think there is a 132 post (and counting) thread on the issue? What you are saying is completely at odds with reality, it is completely baffling!

This real issue here is you forcing manufacturers to crippled their devices, this is unacceptable.

[Liran Barsisa]

@Dianne Hackborn

No matter how you look at it, the purpose of the SD card as an extra storage for whatever the user wishes has been reduced so much that only built in apps can use it.

Only built in camera apps can put images and video files there.

Only built in documents apps can put documents there.

Only build in file managers apps can navigate there.

Only build in images/audio/video files editor apps can use the SD card.

And I'm sure there are plenty of other examples.

For all other third party apps, they can only use it for cache or just stay there (obb files etc...). 

If the user is unhappy with any of the apps I've mentioned above (if they even exist), other third party apps are useless if the device is currently short in storage, so they don't have any alternative.

Now users will continue to wonder "why does the OS say I don't have enough storage? I have plenty of storage on my SD card" .

This problem existed in the past, and now it will come back...

People can no longer say "ok, I have a small storage on the device, but that's ok - I can still buy an SD card".

Also, SD cards are fine for media files and documents, and its technology is becoming better and better.

I still think you should have come with a much better idea.