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.