[Galaxy Tab Pro 12.2, 10.1, 8.4 Q&A, Help & Trouble] roustabout:
Unfortunately, it's not something that Samsung decided to do, it's something Google started back in Android 3.2 and is now apparently asking OEMs to follow their lead on - or else the OEMs aren't reading the codebase much, which I think is also a problem.

The external storage permssions were spotted and commented on by Chainfire (he who gave us root, hallowed be his name :) ) in 2012!

https://www.xda-developers.com/andr...-preventing-write-access-to-external-storage/

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

I'm not 100% on this, but I think that the Samsungs are one of the first sets of devices to get KitKat and to have sdcards. (don't know what the status of the gpad 8.3 is) It will be interesting to see if the Gpad 8.3 does the same thing; I'm pretty sure the Tegra Note did, and then EVGA pulled back on their KitKat update due to bugs, of which this was one (glad they called it a bug, but if they'd looked at the code before implementing the changes...)

This issue goes way beyond the sdcard. Remember when your device could be connected to your computer and turn up as a mass storage device, not a media player or a camera?

The MTP protocol originally implemented by Google was hugely troublesome on that score when it was first introduced. There were absolutely insane failure modes. To get an accurate readout of what was on your device you couldn't disconnect from your computer and reconnect, you couldn't disconnect, reboot the Android device and reconnect - nope, you had to reboot your computer.

I haven't thoroughly tested failure modes but at least the warning on copy from PC to Android works correctly now.

When first implemented by Google, file deletions on in Android were not reported to the computer connected to it if they occurred while connected. So you could move a folder and then try to copy files that didn't exist, and Android wouldn't report the file was not there.

This is an example of silent failure, which is the worst possible failure mode. It gets beaten into the heads (or once did) of programmers that you always produce and report an exception on failure. Not doing so is negligent and might be actionable depending on the context.

I just deleted a file from the Samsung and it's taken more than 30 seconds for the Windows system to get information on what's on the Samsung.

Great - I also couldn't enumerate my local disk drives while I waited, more than 3 minutes (i7-2600k, 8 G ram - not a PC side issue!) I finally disconnected and reconnected the USB cable and was able to get my disks to populate immediately on disconnect, and an accurate poll from the Samsung on reconnect.

I suspect that Google's 'fix' for the not-notifying-on-delete bug is to throw a disk not ready message back at the host system.

So, why does Google not see any of the following as important?

- easy local disk mounting

- viable sdcard use

- well-written MTP implementation

I don't think it's about the cash - sure, Google's selling a few books and a few movies and such, but they're really an advertising broker; the revenue from that isn't why they're worth gazillions.

I think it's actually much more insane than that: Google is all about big data and the supremacy of databases over all else.

Including files themselves - Google wants to drive toward a world where files don't exist, only pointers in databases exist.

http://glasskeys.com/2011/02/28/why-google-uses-mtp-instead-of-usb-file-transfer-on-android-3/

is a perspective on MTP that is essentially diametrically opposed to mine - it's quoting Google as pointing out that there is both simplicity and allegedly a greater degree of security from MTP.

The security comes from the filesystem retaining 'nix style ACLs and helping to maintain sandboxing between applications by not exposing storage as a fat32 filesystem and thereby giving up granular access controls.

---------

(As an example of silent failure that I think may be the subject of civil litigation: the flaw that broke SSL/TLS validation on most Apple devices - phones, tablets and OS X based computers. If you look at the code, it's blindingly clear what happened.

http://appleinsider.com/articles/14...pdate-is-present-in-os-x-fix-coming-very-soon

http://arstechnica.com/security/201...aw-in-ios-may-also-affect-fully-patched-macs/

This flaw may well explain the Snowden documents that indicate that the NSA has access to any Apple device at will. When those documents were first being reviewed, there were two responses:

- it isn't true

- Apple is in bed with the NSA.

Ignoring a bug that easy to spot in a functional test for years tends to make me wonder if the second explanation may not hold water.)