What about removable SD card in 4.4

[Andy Panda]

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

[Jeff Sharkey]

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

--
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

[Andy Panda]

Thank you.
This really helped.

Четвер, 9 січня 2014 р. 21:25:38 UTC+2 користувач Jeff Sharkey написав:

[Emile Belanger]

This change totally breaks all my app by the way. What are Google doing?! (Again making life more difficult for devs)

My apps NEEDs to access anywhere on the external SD card, I already have 4 support emails in the last day as people are now upgrading to KitKat, I expect many more and many bad reviews because of this.

Thanks

[Robert Alm]

Hi; I have the same issue and the same question but i'm not especially satisfied with the answer...

How come I can write on the primary external storage (mounted as /sdcard) and then when I uninstall those files are not removed? To me it would have made some sense if that rule was applied to "primary external storage"; but never on my "user supplied sdcard (secondary external storage)" Thi sis one of the real major benefits of Android.. the free coice of handling my own files as I wish.. How about USB mass storage devices? Do they fall into the same restrictive slot?... wierd... and wrong.. Ill probably jump ship (either change to another OS/device or simply do not upgrade; which is a shame - as I know many others will when they find out...)

What if I use one application to download data and then another application to alter that data (not an uncommon usecase) .... And dont refer to the Document class; it is just totally wrong... let me handle my files using a file manager! (or at least let me have the option to do so from developer settings at least!)

This is causing a step-back to the rationale of convergence of PC:s and handheld devices.. I was under the impression people wanted them to converge... and this is diverge... 

Sorry for the rant..

Regards // R

[Justin]

Hi Jeff,

Justin Tipton here. Creator of iSyncr and Rocket Player. Two top ten music applications with several million active users. One application allows syncing your iTunes music to your phone's SD card over USB or WiFi. The other, Rocket Player, allows for a great listening experience, including the ability to edit music tags and delete songs.

If I understand you correctly, under KitKat, iSyncr should sync all music over WiFi that the user wants on the SD card to "<SDCard>/Android/data/com.jrtstudio.iSyncr".

Then, when someone uses my Rocket Player app to delete a song, I should toast and say "The Android team doesn't want you to be able to delete this song", because Rocket Player can only access "<SDCard>/Android/data/com.jrtstudio.RocketPlayer", and not "<SDCard>/Android/data/com.jrtstudio.iSyncr".

I'm I understanding this correctly? Apps that sync data wirelessly are confined to a single directory on the SD card that no other apps can access without APIs being built into app that synced the files?

I hope I'm wrong. I really really do.

(P.S., Users are playing files that the media scanner doesn't pick up. Formats not natively supported Android. Do not suggest the MediaStore as a work around for music applications. It isn't.)

[Jeff Sharkey]

First, thank you for all the hard work you've done to create excellent apps for Android users.  :)  I hear your frustration, so bear with me as I offer some general background before digging into your specific question.

Before KitKat, public APIs only supported a single primary external storage device, which on some devices can be emulated and backed by internal storage.  Primary external storage devices continue to work the way they always have since API level 1; if you request WRITE_EXTERNAL_STORAGE you have full read/write access across that entire device.

We've come a long way since API level 1, and looking back we found that some apps would scatter their files across external storage.  If an app was uninstalled, these files would be orphaned, and users had to manually scavenge through all these files to free up disk space.  This was a bad user experience, and something we wanted to avoid repeating.

So when we added APIs for secondary external storage devices in KitKat, we carefully limited write access to directories belonging to the running app.  This gives us the best of both worlds: apps can take advantage of the extra storage space, and users have better visibility into and control over how apps are using their storage space.  (These package-specific directories are surfaced to apps through Context.getExternalFilesDirs(), etc.)

Before KitKat, some OEMs chose to leave external storage devices unprotected, where apps could write if they guessed a special filesystem path.  These were never part of any platform public API; they were an internal implementation detail.  We've always maintained that internal details like this can (and will) change without warning, and that apps should not depend on these hidden behaviors.

Now, on to your specific question: there are many ways that your two apps could coordinate to share/manage files between themselves.  One way would be to use a ContentProvider to offer access from the first app to the second.  We've encouraged the use of ContentProviders like this because they support granular access controls through temporary Uri permission grants.  FileProvider is a good place to start, since it already handles the details related to sharing files, including support for deleting:

http://developer.android.com/reference/android/support/v4/content/FileProvider.html

FileProvider may not be a perfect fit, but it's a good starting point for writing a custom provider.  Using a provider creates a cleaner contract between the two apps, offering an abstraction layer around where/how the files are actually stored, and a place to surface metadata such as download progress, etc.

If you'd like to keep things simpler, another approach would be to define an internal protocol between your two apps, where the second app could request that the first app delete a specific file, perhaps through a broadcast that you protect with a permission.

Hopefully the details above shed more light on why these behaviors exist, and hopefully one of the strategies described above can help improve the interaction between your two apps.  :)

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/groups/opt_out.

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

[Justin]

Hi Jeff,

Thanks for taking time to provide more of an explanation and confirmation that what I fear to be true is indeed true.

I agree that apps leaving orphaned files is an issue. I'm as much at fault as others, as iSyncr will leave some orphaned files when removed. However, having answered more than 30,000 customer emails over the last four years, experience tells me that removing the ability for customers to manage the contents of their removable SD card with an app isn't best for the OS. Most users don't want to have to plug their SD card back into their computer each time they want to delete a file not in an Android/Data folder. 

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?

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?

[Ferenc Hechler]

Hello Jeff,

I can understand your security concerns about apps which might be malicious or just sloppy with the data on the secondary storage device.
From this point of view it is clean to restrict access.

> If you'd like to keep things simpler, another approach would be to define an internal protocol between your two apps,

But as Justin stated there are other use-cases for removable media which assume, that one app provides data and another app consumes and modifies the provided data.
One benefit for the user is the freedom of choice, which app to use independently from the app which provides the data.
The camera app I use should not restrict me on which image editor app I am able to use.


About my background and intentions:

I was very disappointed about the Nexus devices not to support mounting attached USB mass storage devices.
So I wrote the USB-Stick Plugin for Total Commander which allows users to access the content of external storage (Flashdrive / SD-Card Reader) attached via USB-OTG. Inside the Total Commander the locally attached storage is treated like a remote filesystem (FTP for example).

Now many users asked, how to access the files outside of Total Commander, for example to show images in a different Gallery app.
This was not possible, because the files do not exist in the local filesystem.

With KitKat I thought the Storage Access Framework could solve this problem.
Every app can access files independently from the (Cloud-)storage where the file is persisted.
So I wrote StickyCloud, a Provider for the SAF which grants access to the files on the USB device.
This works fine as long as the consuming app uses the System-File-Picker to open and save the documents.
But as soon, as he tries to access other files a SecurityException is thrown.
There are only very few applications which support SAF and I think one reason is the restriction to the System File Picker.

Another developer asked me, how to access the files provided from my app and so I wrote a ContentProvider which does not have the limitations of the SAF and published a reference implementation (StickyCloudClient) which he can use.
Similair to what you proposed using FileProvider.

But this is the same issue as above. Only apps which know each other can exchange their data.

Because of this I have opened an enhancement issue for this: https://code.google.com/p/android/issues/detail?id=65139

In my oppinion we should leave the decision to the user, whether he wants to be secured and limited in his choices, or whether he wants to allow arbitrary apps to access his storage.


A possible solution:

When I attach an USB-Device a dialog appears which queries me, which app should gain access to this device.
Perhaps we could also implement a permission, which queries "Full"-Access to storage devices.
So if I start the Image-Gallery, it asks me, whether I grant rights to have FULL-Access to the sd-card, or not.
So the user is aware of security issues and has the freedom to grant his beloved music player to allways access the secondary storage.

- feri

[Justin]

For further clarification, I had a KitKat device with SD card support overnighted from the Play Store, so I could see this up close.

When the shiny new device arrived, I put in a 64GB SD card with 60GB already filled up with my music and pictures. As discussed, I have been unable to delete anything on the SD card, and so it is effectively a 4GB SD card when used on KitKat.

At least I have a device now, and can spend my time supporting this change and educating users on why iSyncr USB and WiFi syncs to "Android/Data/com.jrtstudio.iSyncr" now. Customers were going to get Chromecast support or other cool features, but now they'll just have to wait while I retrofit my apps.

[Jeff Sharkey]

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

[Justin]

Thanks again for weighing in Jeff!

I've started a feature request for Android to allow users the option to grant apps direct access to SD cards without rooting. I think it is a viable solution. It gives users choice, but users would have to proactively allow apps to have write access to the SD card. Otherwise apps remained constrained to their folder.

https://code.google.com/p/android/issues/detail?id=65974

[Emile Belanger]

Jeff,

This decision need to be reversed. I know Google does not like the SD Card, but effectively disabling it software is unacceptable. I can only hope manufactures see sense and modify there custom ROMs so their SD card is actually usable.

The SD Card is a key selling feature for a lot of power users, these power users expect to be able to use the SD Card like... well an SD card. Android device are computing devices

Having one directory the app can write in to, *which gets deleted on app uninstall!* is not how anyone uses their external storage space. 

http://beranger.org/2014/01/30/how-kitkat-4-4-killed-android-and-google-keeps-screwing-things/

[성인수]

Hi Jeff.

 

Both ES File Manager and QuickPic are saving file on non package path. I checked it and both apps work properly. How they did it?

If so, is this security hole of new kitkat's sd storage policy?

 

Regards,

Kein.

2014년 2월 15일 토요일 오전 6시 55분 24초 UTC+9, Jeff Sharkey 님의 말:

[Justin]

ES File Manager is not working for me. It claims to delete a file, but after refreshing the directory, the file is still there.

[성인수]

I didn't testing if delete command is working properly, but ES's copy command is working.

Did you try QuickPic app? This app allow user move or copy pics in external sd to specific path user choose.

They know something how to skip Google SD restriction. who know their trick?

and i also would like to know Google also know about this and allow thier update.

 

2014년 2월 18일 화요일 오전 8시 30분 23초 UTC+9, Justin 님의 말:

[William Wanghui]

Hi, Jeff,

I am the manager of the design team of Kingsoft Office for Android. 

Kingsoft Office is one of the most broadly used office app for Android, it is in the top 5 apps list in the business category of almost all countries in the world for a very long time (and still now).

And now i would like to give everybody a real case, just like Robert has imaged:

1, There is a doc file in the folder "sdcard1/downloads", which was download by the user by Chrome browser.

(Or, There is a doc file in a folder on sdcard1, the secondary external storage, the user browses the folder by using ES File Manager)

2, The user tapped the file, and opened it by Kingsoft Office.

3, The user made some changes, and tapped "save" button: it will then fail to save the file, for Kingsoft Office can not write the folder/file now.

Now we are wondering what we should do for the user:

Should we ask the user do not to open the downloaded file from Chrome browser or the system statues bar or ES File Manager?

Or should Kingsoft Office force the user to save all the changed files to the folder: sdcard1/Android/data/<package-name> ? Should we enhance the features of folder management, to allow the user arrange the folders under the folder <package-name> ? Or, Should we force the user to save all files in to Google Drive or other cloud storages, but what if the is no network connection right now?

If Android is going to act like iOS: every app has it's own sandbox for file storage, if that is the policy of the feature, we need a official confirmation so that we designers can then make better decisions. 

Many users have emailed to our support team and asked us what's wrong with our Office.

And our OEM partners are pushing us to provide a solution.

We do need to make an update for our app, and we are wondering which way we should choose.

We do need more information from google, thanks a lot.

(And it's so great to find you guys discussing this issue here!)

[Mauricio Cirelli]

I would like to comment about it as an iOS user.

In iOS I can open a file from a File Manager app using another app (such as a PDF reader) and then, when I want to save some changes, the reader app will save a COPY of this file in its own sandbox space. Thats AWFUL. After saving these changes and creating a NEW copy of my file I need to manually sync these files between these apps, which is DEFINETELY a pain for me: I have duplicated files (which wastes storage space, unless I manually delete them after syncing) and I have to manually synchronize these files elsewhere (some apps offer uploading back to dropbox, for instance, but it is not always the case).

Regarding Android, I understand the concerns about bad apps messing up with files, but the drawback is really bad for users. In a computer we do have this issue (about "bad programs") but how would be our life if we could not edit the same file in different apps?

If I would chose, as a user, I would prefer the risk of having some bad apps messing up the filesystem (or, perhaps one may find another solution for this?) than the drawback of not being able to edit the same file in different apps.

[Manfred Herrmann]

there are a lot of "valid use-cases" out in the field

I agree ... the filesystem on Android (Windows, Linux...) is not realy "easy usable" without a lot of experience and admin-efforts. But a lot of android devices supporting external sd-cards. And this feature is very important for a lot of users.

The problem is:

Changing main platform-features "on the fly" without "communication" and without a long transition time (i. e. 2.x > 4.x).

The solutions?

1. never release a "main platform-change" without the option to "enable/disable" this feature!

2. rooting a device and implement the "work around". > Not realy user-friendly

3. switch to a i. e. "chinese model" with customized android/linux version.

4. search for a "open" linux based smartphone platform. > ubuntu, tizen ???

I would prefer solution 1.

[Mohamed Hafniyaas Mohamed Hanaas]

Hi Jeff,

Reading on below, I first want to say, I am no developer. I am rather a power user. Since I started using an Android phones, I have been spending less time on my home computer. I use my phones for both entertainment and work. I usually do a lot of work from my phone unless I need a larger screen for something. The main and only reason that I like Android is the freedom it grands it users, even without rooting it. And one of that freedom is managing my files the way I want it and being able to use any application I desire to manipulate my files.

Currently I am using a Galaxy S4 and largely I chose it over HTC one was being able to use a SD Card. Now you are telling me that you are restricting this option, for me it is more like totally crippling it.

Kindly arrange so that users, that means US, can enable this feature on/off or providing some form of control panel via I can select which of my applications will have full/partial access to my SD Card/external storage.

Please do not become iOS, by restricting access of the users to their phones. Like I said, the main reason I like Android is the freedom, do not turn Android into a capitalistic product for your ease. Kindly check with users what they want and desire before going onto implementing or removing features of the OS.

I for once will not update to Android 4.4.2 now until this is solved. Known devil is better than an unknown angel.

And one important question, to Jeff and other developers:

Is this restriction only applicable when manipulating files on SD Card/external storage? Or same applies for files in device storage.

[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]

--

[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!).

[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.

[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

--

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.

[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.