What about removable SD card in 4.4

23999 views
Skip to first unread message

Andy Panda

unread,
Dec 23, 2013, 3:32:29 AM12/23/13
to android-...@googlegroups.com
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

unread,
Jan 9, 2014, 2:25:38 PM1/9/14
to android-...@googlegroups.com
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

unread,
Jan 21, 2014, 9:21:21 AM1/21/14
to android-...@googlegroups.com

Thank you.
This really helped.

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

Emile Belanger

unread,
Feb 1, 2014, 7:21:48 AM2/1/14
to android-...@googlegroups.com
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

unread,
Feb 6, 2014, 3:07:35 AM2/6/14
to android-...@googlegroups.com
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

unread,
Feb 12, 2014, 5:37:02 PM2/12/14
to android-...@googlegroups.com
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

unread,
Feb 13, 2014, 5:24:04 PM2/13/14
to android-...@googlegroups.com
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:


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

unread,
Feb 13, 2014, 5:58:09 PM2/13/14
to android-...@googlegroups.com
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

unread,
Feb 14, 2014, 4:53:32 AM2/14/14
to android-...@googlegroups.com
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

unread,
Feb 14, 2014, 10:35:27 AM2/14/14
to android-...@googlegroups.com
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

unread,
Feb 14, 2014, 4:55:24 PM2/14/14
to android-...@googlegroups.com
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

unread,
Feb 14, 2014, 5:08:15 PM2/14/14
to android-...@googlegroups.com
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.

Emile Belanger

unread,
Feb 15, 2014, 10:13:31 AM2/15/14
to android-...@googlegroups.com
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. 


성인수

unread,
Feb 17, 2014, 4:29:24 PM2/17/14
to android-...@googlegroups.com
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

unread,
Feb 17, 2014, 6:30:23 PM2/17/14
to android-...@googlegroups.com
ES File Manager is not working for me. It claims to delete a file, but after refreshing the directory, the file is still there.

성인수

unread,
Feb 18, 2014, 6:16:12 AM2/18/14
to android-...@googlegroups.com
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

unread,
Feb 19, 2014, 9:47:26 AM2/19/14
to android-...@googlegroups.com
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

unread,
Feb 19, 2014, 1:34:49 PM2/19/14
to android-...@googlegroups.com
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

unread,
Feb 22, 2014, 6:07:19 AM2/22/14
to android-...@googlegroups.com
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

unread,
Feb 23, 2014, 9:22:24 AM2/23/14
to android-...@googlegroups.com
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

unread,
Feb 23, 2014, 10:41:49 PM2/23/14
to android-...@googlegroups.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 3rd 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

unread,
Feb 26, 2014, 6:46:24 PM2/26/14
to android-platform
--

virtual

unread,
Mar 1, 2014, 6:23:44 AM3/1/14
to android-...@googlegroups.com
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

unread,
Mar 4, 2014, 4:41:01 PM3/4/14
to android-...@googlegroups.com
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

unread,
Mar 5, 2014, 2:08:54 PM3/5/14
to android-...@googlegroups.com
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

unread,
Mar 6, 2014, 5:54:59 PM3/6/14
to android-...@googlegroups.com
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

unread,
Mar 8, 2014, 3:57:32 PM3/8/14
to android-...@googlegroups.com
This also raised a issue with MicroSD Smart Cards.

Have wrote about it here:


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

unread,
Mar 9, 2014, 4:48:59 AM3/9/14
to android-...@googlegroups.com
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

unread,
Mar 10, 2014, 2:15:10 AM3/10/14
to android-...@googlegroups.com
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

unread,
Mar 11, 2014, 5:16:40 PM3/11/14
to android-...@googlegroups.com
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

unread,
Mar 11, 2014, 8:35:19 PM3/11/14
to android-...@googlegroups.com
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

unread,
Mar 11, 2014, 9:37:47 PM3/11/14
to android-...@googlegroups.com
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

unread,
Mar 12, 2014, 2:29:47 AM3/12/14
to android-...@googlegroups.com
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

unread,
Mar 12, 2014, 3:24:56 PM3/12/14
to android-...@googlegroups.com

Alan Laas

unread,
Mar 13, 2014, 1:46:52 PM3/13/14
to android-...@googlegroups.com
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

unread,
Mar 13, 2014, 2:46:42 PM3/13/14
to android-...@googlegroups.com
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

unread,
Mar 13, 2014, 2:58:39 PM3/13/14
to android-...@googlegroups.com

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

unread,
Mar 13, 2014, 4:48:38 PM3/13/14
to android-...@googlegroups.com
"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

unread,
Mar 14, 2014, 2:28:36 PM3/14/14
to android-...@googlegroups.com
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

unread,
Mar 14, 2014, 2:50:06 PM3/14/14
to android-...@googlegroups.com

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

unread,
Mar 14, 2014, 3:57:15 PM3/14/14
to android-...@googlegroups.com
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

unread,
Mar 14, 2014, 4:28:27 PM3/14/14
to android-...@googlegroups.com
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

unread,
Mar 14, 2014, 5:55:53 PM3/14/14
to android-...@googlegroups.com

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

unread,
Mar 14, 2014, 5:41:51 PM3/14/14
to android-...@googlegroups.com

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

unread,
Mar 15, 2014, 5:39:24 AM3/15/14
to android-...@googlegroups.com
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

unread,
Mar 16, 2014, 8:27:55 AM3/16/14
to android-...@googlegroups.com
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

unread,
Mar 16, 2014, 10:59:14 PM3/16/14
to android-...@googlegroups.com
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

unread,
Mar 16, 2014, 11:44:21 PM3/16/14
to android-...@googlegroups.com

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

unread,
Mar 16, 2014, 11:57:03 PM3/16/14
to android-...@googlegroups.com

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

unread,
Mar 18, 2014, 4:57:59 PM3/18/14
to android-...@googlegroups.com
About rooting, I know it's not a solution for common users, but you can solve it this way:
1. root the device.
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

unread,
Mar 18, 2014, 6:17:42 PM3/18/14
to android-...@googlegroups.com

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

unread,
Mar 18, 2014, 10:41:19 PM3/18/14
to android-...@googlegroups.com
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

unread,
Mar 18, 2014, 11:50:14 PM3/18/14
to android-...@googlegroups.com

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

unread,
Mar 19, 2014, 1:30:37 AM3/19/14
to android-...@googlegroups.com
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

unread,
Mar 19, 2014, 2:14:38 AM3/19/14
to android-...@googlegroups.com
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

unread,
Mar 19, 2014, 2:32:40 AM3/19/14
to android-...@googlegroups.com
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

unread,
Mar 19, 2014, 5:20:32 AM3/19/14