Slashdot Mirror
Android 5.0 Makes SD Cards Great Again
An anonymous reader writes: Over the past couple of years, Google has implemented some changes to how Android handles SD cards that aren't very beneficial to users or developers. After listening to many rounds of complaints, this seems to have changed in Android 5.0 Lollipop. Google's Jeff Sharkey wrote, "[I]n Lollipop we added the new ACTION_OPEN_DOCUMENT_TREE intent. Apps can launch this intent to pick and return a directory from any supported DocumentProvider, including any of the shared storage supported by the device. Apps can then create, update, and delete files and directories anywhere under the picked tree without any additional user interaction. Just like the other document intents, apps can persist this access across reboots." Android Police adds, "All put together, this should be enough to alleviate most of the stress related to SD cards after the release of KitKat. Power users will no longer have to deal with crippled file managers, media apps will have convenient access to everything they should regardless of storage location, and developers won't have to rely on messy hacks to work around the restrictions."
I can only hope this is actually implemented transparently. Having to choose (and pay for) all the memory you'll ever use the day you buy your phone is ridiculous, and limiting people to what the manufacturer's cost targets are (and no mfr is interested in a bunch of expensive, slow moving stock) made no sense in the market.
Now if Verizon can get it's head out of it's ass and roll out 5.0 updates quickly after the mfrs release them, things might be looking up.
Is it just my observation, or are there way too many stupid people in the world?
I expected the Nexus 6 to have a microSD card slot because they were supposed to gain first-class support in Android 5.0.
But it doesn't, so external storage support must still be a second class citizen on Android.
This will help me on my phone, which has an SD slot ... but it won't help me on my Nexus tablet, which, as far as I can tell, doesn't have an SD slot.
So, I guess I'm only partially impressed. :-P
Lost at C:>. Found at C.
For a long time, I've been hoping for an OS where, by default, the apps cannot access anything outside of their private areas.
It's possible with chroots and cgroups and other facilities but it's always a mess of third-party after-thoughts.
There's no reason I should have to give my satnav app full read-write permission to the entire SD card just so it can save my favourite places to permanent storage. It shouldn't even be able to know where it's saving them, that's for me to choose.
As such, these are all moves towards a safer, more secure environment. The problem, as always, is what happens in the meantime for the transition or if we mess up and stop apps doing what they need to do. No photo app needs read-write access to the entire SD card, nor can it cope with just read-write access to a private app area. It needs to share the files it writes with the user. Isn't this precisely what the amalgamation of several folders into, say, "Pictures" or "Music" is on several OS? All the app needs to do is say "this is a pictures folder that the user might want to use". And when uninstalled, it stays around because it's still one of the many listed pictures folders for that user.
Gone are the days of full-write-to-everything access. We don't need it. It's not necessary. But we do need the facilities to ensure apps can do what they need to do. This very much pushes into the filesystem-as-a-database idea that we've been wanting for decades. There's nothing stopping an app opening up a separate table for its photos and having the database just join the rows from several tables when the user wants to look at all their photos. And that does not require giving the app access to every table and row in the entire database.
I used to love the openness of Android and I would have never considered iOS. However, after this blatant destruction of what Android and any true open system should stand for, I did not have any reservations getting an iPhone to replace my Galaxy S4.
So long Google, you fucked up. Badly,
That's why you should always root and use https://play.google.com/store/...
Is it just my observation, or are there way too many stupid people in the world?
I, too, love the openness of iOS. Their SD card support, file management tools, inter-application data sharing, and overall system accessibility to users and developers is top notch.
I would just like to point out that iOS users never had any problems with built-in SD card readers.
Get free satoshi (Bitcoin) and Dogecoins
Google has servers for this. You're supposed to be letting them index/scan/use your info, not storing it privately on flash.
Duh, it's a network device, everyone has unlimited network access everywhere don't they?
Eh I googled it and didn't bother to switch it. Beta is horrible though.
So that I can control an installed apps permissions one by one? Or do I still have to grant all apps all permissions (which is what it was in practice)?
As an Android user, I really appreciate this sentiment. I would love to control the permissions of my apps, especially the ones that I know are designed to violate my privacy.
As an Android developer, the thought of how this would impact the testing of my apps is troubling. Much of my code depends on being able to do certain things. The simple fact of software development is that "all untested code has bugs". So now I need to test my app with all combinations of requested permissions disabled. That would, even for my simple app requiring only 5 permissions, result in a 32x increase in testing effort. Far more likely scenario: I would make sure that all needed permissions are available and, if not, just refuse to start.
the growth in cynicism and rebellion has not been without cause
So can we install apps to the SD card again? At one point, you could move apps to the SD card and run them from there instead of from internal storage. This was great if you had about 3GB of "applications storage" (the internal storage area was divided into system, applications, etc) and were running some large Android games. You could get a cheap 32GB or larger microSD card, put that in, and instantly have all the space you would need for the foreseeable future, Then, this feature was removed and apps were restricted to the "applications" area of internal storage again. It would be great if you could put apps on the SD card again.
(Yes, I know this might be possible if you root the device, but there's something to be said for building this feature right in instead of keeping it only for the people who know how to root their devices.)
My sci-fi novel, Ghost Thief, is now available from Amazon.com.
MTP is and was a terrible idea to keep users out of the core OS files. I get the fact that there needs to be a dedicated section separate from the OS partition to store pictures videos and music but MTP just turns the device into a blackbox. because the protocol was developed by microsoft, fragmentation is encouraged and most vendors are wildly different in how they approach it. MTP-Tools and the libmtp project for linux contains releases that are largely workarounds and kludges for this.
Make android EXT4 with MTP enabled for windows connections. If the device is connected to a linux machine, maybe it should just assume the owner is intelligent enough to handle the raw filesystem partitions. if you want this access in windows, install cygwin.
Good people go to bed earlier.
Well, look at it this way ... I as a user really would prefer to control WTF apps on my devices are doing.
So, if I actually had granular permissions, and they broke your app ... my problem is solved, because I'm going to uninstall your application on the assumption that it's either malicious, and doing stuff it shouldn't, or badly written, and doing stuff it shouldn't.
In either case, I win. Because one less badly written application is on my device.
The problem is, Google isn't going to give us this, because people might use it to block ads and other unwanted crap where Google makes its money from.
But your flashlight app? It doesn't need access to my contacts, my phone state, the state of the wireless connection, my storage, or pretty much anything else. If it can't survive me disabling those features, I don't want it installed.
So, if you wrote an app which just asked for every permission on the assumption you might eventually need it ... I don't want your crappy application anyway.
I see breaking your app as a win-win for me.
Lost at C:>. Found at C.
That would, even for my simple app requiring only 5 permissions, result in a 32x increase in testing effort. Far more likely scenario: I would make sure that all needed permissions are available and, if not, just refuse to start.
It's not that bad. I don't know what set of permissions you're using, or what your app even does, but a lot of things would just be rolled into testing you're already doing. Want to test if network access is denied? Do it while you're testing how your app behaves when the phone doesn't have a WIFI or 3G/4G signal (and if your app is one of those that refuses to start without a net connection, then just please ragequit)
99% of the problems apps have with permissions managers like that is just assuming data will be there instead of doing proper input checking (data from the system is still "input"). I remember back when an "android tablet" was basically a Nook Color with a modified phone rom on it, I came across some very nosy apps that shat themselves when they tried to get a phone number.
Never trust the client.
I've often gone to eBay etc to pick up my electronic odd-and-ends. I'd have to say that for stuff like SD cards - though you do pay the price locally - it may be a safer bet to buy in a B&M than online.
The amount of fake cards is staggering. I'm not just talking about a "no-name" brand that's labelled as Samsung, or a class 4 listed as a class 10, but cards that are labelled as 16, 32, 64GB etc, are IDENTIFIED BY THE OS as the labelled capacity, but actually contain only 2-4GB and have modified firmware causing them to report as larger. That means the card seems to work fine initially, but when you go over the 2GB/4GB mark it actually starts overwriting existing sectors/files resulting in rampant data corruption.
If you want to test your card, you can use a utility like h2testw It will tell you if the card is having bad writes - which could indicate a faulty card - but also tells if it's doing stuff like writing back over existing files (which indicates a fraudulent "over-capacity" card).
[h2test2 is windows software. Sorry but I'm not sure if there's a 'nix equivalent. One could probably make a script that DD's numbers across various sectors and then checks afterwards whether they overwrote previous sectors).
Just root your phone and re-enable the SD card. even the stock android phone app will gladly take advantage of the SD card when the fix to the OS is added.
Do not look at laser with remaining good eye.
Is that manufacturers can have multiple "external" sd cards even though only one is removable (my Moto for example).
So when a user with one of these phones wants to get a new phone, they are practically forced to use phone mfg/service provider for transferring data to a new phone.
The conspiracy theorist in me thinks this is all about lock-in.
I hate all the edge case code I have to maintain to choose the correct "external" storage.
Has this been addressed?
O_o
What security problems? You can't autoexecute stuff off an SD under Android. The only time there's a security concern (and it's going to be the SAME on the on-device eMMC...) is that you can execute code off of an SD that vendors didn't intend for you to run. That's how people side-load in the first place. They didn't change anything with this little change they made in KitKat and didn't break anything any worse than it was with this change back.
The reason that they quit including SD slots was because they want everything on Drive or similar and it lowered the BoM cost to peel those out. It's not security- quit deluding yourself and everyone else with this tripe.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
I will never trust Google with Android again, not for a platform for anything serious. When I bought my tablet, I could organize my pictures on it, and now it it sits in my room as an implement for occasional light browsing. Android had an edge over IOS, because I could do useful things with it, without begging Itunes to limit what types of files exist on my tablet.
I love QuickPic, for my pictures, and my Galaxy Note 8 may never be upgraded to Lollypop, so what I am to do throw it away?
Although I am angry, I have only myself to be angry at for trusting Google in the first place. Not evil, my ass!
https://www.youtube.com/c/BrendaEM
There's a reason Google stopped including SD slots in flagship devices.
To force users onto Google Drive and cut them off from their data when in remote locations.
I am becoming gerund, destroyer of verbs.
So, if I actually had granular permissions, and they broke your app ... my problem is solved, because I'm going to uninstall your application on the assumption that it's either malicious, and doing stuff it shouldn't, or badly written, and doing stuff it shouldn't.
Maybe I'm misunderstanding, but... Why do you need granular permissions to do that? You can already see what apps need what permissions, right? And apps can't change those permissions without your explicit consent. The only think you can't do is allow or deny permission to them on a per-app / per-permission basis, but it should be pretty obvious that a flashlight app doesn't need access to your contacts or phone logs, or SMS messages, right? As such, the result is the same - stay far away from that app, because it's asking for too many permissions, and therefore can't be trusted.
Irony: Agile development has too much intertia to be abandoned now.
I'm still not holding my breath for Google to finally get a clue and include SD slots on Nexus phones.
I can see what they're asking for. I can't always see why they're asking for it.
I may be interested in the app, but I might want to say "you can do this stuff, but not that". I'd like to be able to go back and remove some permissions. In some cases, I'd like a better explanation of why you need a certain permission.
In short, I think the ability to selectively enable/disable permissions on an app ... because there may be times when I briefly want it back on, but in general don't.
On my Android phone, when I get a voicemail, a little while later I get a text from my cell provider saying an app on my phone is trying to access the interwebs ... even though I don't have a data plan, and leave wifi turned off most of the time. So, something in there feels entitled to access the internet when I get a voicemail ... and I'd really love to be able to identify it, and either delete it, or disable that.
In other words, I don't necessarily trust apps, and want to have the control over what can do what when ... while I'm using you, sure, maybe I need to give you access to the network. But while I'm not using you, if you try it access the network, I want to see an error.
Unfortunately, Google just lumped a lot of permissions in, and don't really do much to tell you why an app claims it needs something. Like that whole "this permission could cost you money, but we're not going to tell you anything more".
It's my device, give me control over it to make my own decisions about how and when apps can do stuff. But giving them blanket permissions without a proper explanation is terrible.
Let me find out for myself what happens when I disable them.
Unfortunately, the only way to do that is to root my device and risk destroying it.
Lost at C:>. Found at C.
Yeah, I understand the feeling a bit. I'm not sure I agree that this feature would be worth the price in development costs and app stability. This would utterly break all of the existing apps on the market. If you don't want to give apps permission, you might as well just disable the app completely, at least in practice, because it would probably just crash out at some random time. That's not a good user experience, even if it was actually what you wanted.
I think a lot of this could be alleviated if Google simply encouraged developers to provide more detailed reasons as to why various permissions are needed. Perhaps for each permission, the developer should be required to fill in a line or two indicating which features of the app rely on that particular permission. I've look at apps before and wondered to myself "why the heck do you need permission for x or y?"
That seems a bit more user and developer friendly than trying to play guess-the-permission games with your apps by selectively turning them off and on again and watching where they crap out.
Irony: Agile development has too much intertia to be abandoned now.
You can't autoexecute stuff off an SD under Android.
So the databases form every app on your phone have no value? No reason to keep every app in the system out of the SQLLite file from your banking app?
Jesus H Christ in a Fish Bucket. It's hopeless I guess I give up when even the technical people can't figure out it out.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Now if only we could get general USB storage instead of this MTP bullshit back without having to root the phone and download some random apps to make it work.
MTP is slow as hell, especially when dealing with thousands of files (directory listings alone take several minutes). It also requires specific OS support.
Yeah, I get that MTP is supported on Windows/Mac/Linux, but this isn't always where we're working. I used to use my phone in place of carrying around a USB thumb drive for system servicing. I had my Micro SD card loaded up with things like NIC drivers for Windows XP/Vista/7 (once it has NIC, it generally has net to download the rest of the drivers). It had patches for server systems that didn't have net access. It even had my XBox360 gamer profile on it.
ALL of these have since been lost and had to result in going back to carrying around an extra device or two just to accomplish the same task that was possible just a few years ago with a cell phone and USB cable.
Yes, definitely, or at least a sizeable chunk. The "move app to sd card" operation will move a 10MB or so of a 1GB game to the card. And then the game may or may not still work. Why can't a critical small 10MB part stay on the built in storage, if worried about piracy, and the rest go on the card??
Finally!!! Now just revert all the other stupid crippling decisions. Like banning airplane mode switch and other stuff that used to work before. The current version of Android is just totally useless crap, you have to downgrade to version 2.3 or something to get a usable Android version.
But, you know, fine ... let me put it into a mode where I can say "yes, I'm wearing my big-boy pants, and I will take responsibility for this". Let it be an app that I install myself.
Give me the ability to do a big fat "reset all app perms back to where they were before I did this".
Don't leave me wondering what, exactly, this app needs a specific permission for. If the app wants to just ask for everything, we should be able to turn some of that off.
In fact, we should more or less be able to treat all apps like we don't necessarily trust them, and don't want them accessing our private data without a good explanation.
Lost at C:>. Found at C.
You may be relying too much on testing to find bugs. "Testing shows the presence, not the absence of bugs." --Edsger W. Dijkstra
Any sufficiently unpopular but cohesive argument is indistinguishable from trolling.
Beaming has worked 100% of the time for me (NFC + Bluetooth combo)?
I've never tried another method.
Change is certain; progress is not obligatory.
Perhaps for each permission, the developer should be required to fill in a line or two indicating which features of the app rely on that particular permission. I've look at apps before and wondered to myself "why the heck do you need permission for x or y?"
That won't really help. The problem isn't asking for permissions which explaining why they're needed; the problem is what the app can do with those permissions once it has them. Sure, that social media app has a nifty feature for inviting your contacts to join, and for that it needs access to your contact list (whether you want to use the feature or not). But once it has that access it can just as easily grab all your contacts' e-mail addresses for the purpose of sending junk mail.
In most cases it's entirely possible to disable a permission in a way that won't cause the application to crash. Instead of supplying the user's real contact list, just give the app an empty list. When the app asks to connect to the Internet, pretend the device is in airplane mode or out of the service area. Never reveal that a permission was denied, since that would allow the app to refuse to work without it.
As for whether the permission should be enabled in the first place, the system should ask the user the first time the permission is used. And rather than listing what the app claims it will do with the permission, the system should list the most damaging things the app could do with it.
To fight "permission bloat", every additional permission requested by the app should also require a thorough audit by the app store (at the developer's expense) to verify that the permission is used responsibly. Someone needs to follow up on how permissions are used as a basic security precaution, and it isn't reasonable to expect users to take up that task for apps released through the app store. (Sideloading is another matter.)
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
[Apple iOS is locked down but] Everything works.
Including <input type="file"> with data types other than pictures and videos? Or contributing to an open directory of hotspot locations (like Mozilla Stumbler)? Or decoding video that is lawfully encoded in the United States without having to pay royalties?
Translation, the already shitty security around files on SD cards on Android has now gotten fantastically worse - look for "media managers" that can also handle opening databases from other applications stored on an SD card...
Security from what? "Security" is meaningless without a defined threat model. Sometimes you want to open another application's database to see what information it's storing about you, or to export documents that you have created in that application. That's not a threat, as I see it. See how OLPC defines its threat model and tell me if there's anything you'd add or remove.
Sandboxing exists even in an operating system with a single human user because some people want to keep data on the SD card private from proprietary (and therefore untrusted) third-party applications that might disclose the data, destroy data that is still waiting to be backed up through a non-cellular Internet connection, or both.
I've even considered going back to Apple, I never ever thought I'd type that sentence, yet here we are.
Google continue to make decisions best for them, not their users of late. If it's not that, it's the design team fiddling with something which doesn't need adjusting, making it worse.
It's been at least 2 or 3 years since I've read an article and thought "wow google is amazing, they are the best, a shining beacon of what a company should be, just incredible" (I really used to think that!)
Look, I am glad we have a standardized file system browser now and so it'll lessen the annoyance from having to face yet another custom built file browser. I am especially glad as a developer. I don't have to grab some library off of github hoping it's as good as people say it is.
At the same time, as a user, I don't browse the file system often. Maybe once in a while when I setup an app to point to the sd card, download something or transfer from a pc. So, it's a low priority.
Now... how about a color picker intent? please?
Do you know what you're asking for, in essence? The Apple store. Some people complain about how locked down it is, but on the other hand, malware is almost non-existent on iPhones. Android, on the other hand, gets something like 97% of the world's mobile malware. That's the essence of a walled garden. It's kept pretty, beautiful, and safe because of those walls surrounding it.
Maybe the walled garden approach is better for some people, but I think others enjoy the freedom that Android gives them. Google has decided that it doesn't want the responsibility of vetting apps, so that's what we get. I'm not sure I'd mind, since I think I'd probably prefer fewer but safer apps that were vetted instead of the current glut of millions of "free" apps we have now. I can imagine I surely don't speak for everyone, though.
Irony: Agile development has too much intertia to be abandoned now.
Sometimes you want to open another application's database to see what information it's storing about you
At which point it has an API to do so or GTFO.
Correct me if I'm wrong, but it sounds like you're saying it's unsafe for the owner of an Android device to use any application that didn't come from F-Droid. Without source code, you can't add an API, and without an API or some other access method, you have no way of knowing what an app could possibly be storing about you or of pulling out data that you created within the app.
The attitude you are promoting led to a world of malware/spyware and identity fraud across the PC industry.
And the attitude you are promoting, one of allowing applications to arbitrarily deny the owner of a computing device the ability to implement workarounds that promote things like interoperability and accessibility to people with disabilities, is leading to a world of digital handcuffs and rent-seeking across the mobile industry.
Do you know what you're asking for, in essence? The Apple store.
Perhaps. However, I'm not saying that the device should be locked down like Apple devices are—you should be able to install apps from other sources, at your own risk. Distributors (and particularly the default distributor for broad range of devices) should take responsibility for the behavior of the apps they distribute; users, in turn, should be free to choose where they get their apps from.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
Much of what you describe is CyanogenMod's Privacy Guard feature.
Privacy Guard is enabled for all apps by default. The first time an app requests a permission, the user is asked to allow/disallow that permission, and can choose whether to have that choice remembered or be asked every time. Disallowed permissions simply present the app with false data. Apps work fine, they just think you have no friends/live in the middle of the Atlantic/never connect to WiFi etc etc.
Most internet-connected households have Wi-Fi
That's useful if you happen to live within range of cable or DSL with no cap or a usably high cap. If your home Internet is satellite or cellular, or if you happen to live in the southern hemisphere of the anglosphere (NZAU) or certain parts of Iowa, too bad.
and many public areas, shops and hotels also provide Wi-Fi (often free of charge)
I've had a strange experience with Wi-Fi in Subway restaurants. The Wi-Fi in the local Walmart is run by Subway, where I often wait for my roommate to finish her shopping. But if I stay on for more than a few minutes, HTTPS connections stop being made, and HTTP connections go back to the AirTight page saying something to the effect of "wait 30 minutes to connect again" (I didn't take a screenshot at the time for the exact wording). Besides, even with unmetered home Wi-Fi, you can get the 30 GB up to Google, but you can't get it back down to watch homemade or purchased video on a long ride as a passenger in a vehicle.