Home Development for Android About “USB Mass Storage” support in Ice Cream Sandwich

About “USB Mass Storage” support in Ice Cream Sandwich

by admin

About "USB Mass Storage" support in Ice Cream Sandwich
From early reviews of devices (namely the Galaxy Nexus) on the new version of Android 4.0 (aka ICS, aka Ice Cream Sandwich), it turns out that they do not support such a great feature as USB Mass Storage, i.e. using the phone as a flash drive, without additional tricks. Users of Android devices, up to version 3.0 "Honeycomb" (as it turned out, the changes were made in this version), know that to transfer files to or from the phone, you could just plug it into the computer without any connection to what operating system or software is installed on it. It is logical that the news about the disappearance of this option in the new versions has not caused enthusiasm among Android users, and even led many to think that there is some kind of problem or flaw. Fortunately, one of their engineers at Google Dan Morrill. (Dan Morrill) in a commentary on An angry post on reddit , clarified the situation by explaining in detail what actually happened and why. I find it very curious, so below is a translation of his comments.

ICS itself supports USB Mass Storage (UMS). The Galaxy Nexus phone does not. It’s the same story as Honeycomb: the HC supports UMS, but the Xoom tablet does not. If some device has an external SD card, it is supported for access via UMS. If only built-in memory is available (like Xoom and Galaxy Nexus) then the device’s memory is only accessed via MTP *(Media Transfer Protocol) and PTP *(Picture Transfer Protocol) Physically, it is not possible to support UMS on devices that do not have a dedicated storage partition (like an external SD card or a separate partition like the Nexus S). The reason is that USM and it’s a blocky low-level protocol that gives the host machine direct access to the physical blocks of the media, which prevents it from being simultaneously mountable in Android. With the new unified storage model we’ve introduced in Honeycomb, all 32gb (well, all 16gb, or all N…) is completely shared by both apps and media files. You no longer have to stare sadly at the free 5gb on your Nexus S while the internal app partition is crammed to the brim – it’s now one big, happy partition. Unfortunately, the price you had to pay for this is that Android can no longer afford to give the PC direct access and let it harass the media over USB with impunity. Instead, we use MTP. On Windows (which most users have), there is built-in support for MTP in Explorer as well, and the device looks just like a normal drive. On Linux and Mac, unfortunately, it’s not so easy, but I’m sure that soon, the situation will improve. All in all, it should make using the phone much more convenient.

When asked if the Nexus S has only internal memory, how programs like file managers work without root, Dan explained :

Magic. 😉
First, we allocate a directory on the internal memory which will be the "SD card". Then we take the FUSE file system, which does nothing but remount that directory as /sdcard with access checking turned off. Apart from accesses, FUSE is just a pass-through shell passing writes and reads directly to/from the directory. In other words, we use a fake FUSE file system to remount a certain directory which is masked as an SD card. This is completely transparent to applications that don’t know they are not directly accessing the disk.

Further, when asked if it turns out that there is no access control for the sdcard directory, he reminds :

Yes. Actually by definition running under FAT32 the /sdcard folder (or as it’s called in the API – "external media folder") doesn’t support delimited access, which is fine, since it’s a shared, open to all file dump where one application can trample on the files of another. It was originally conceived for things like music and photos, not private data that "lives" in private storage by apps located on internal memory with shared access.
On devices without an SD card, the only physical file system is the apps private data storage. So we pick a directory, declare it a file dump, mount it as a separate FUSE file system which ignores access rights, just like they are ignored in FAT32.

The reasons for all these changes Dan explained :

(…) We didn’t do it because we wanted to move to ext3, although we won it as a side effect. We did it because we wanted to combine public storage space (like for music and photos) with internal storage for applications. We got tired of seeing phone manufacturers include gigabytes of storage for music, while users still ran out of space for apps and information. This approach allows you to consolidate everything into one partition, which is much better.

Another person asked why you can’t use both approaches, since the memory slot takes up quite a bit of space. To which, a little bit of Android ideology was explained :

Technically there is no problem in the iron to put both. The problem is that you can’t make it a user-friendly interface.
One of the basic principles of Android is that the user doesn’t need a file manager. Ever. We wanted to avoid the syndrome of a file selection dialog popping up at every sneeze, as is often the case with other OSes. The internal information that applications know how to work with should just be available "magically" or stored in the cloud. You can’t make the user do spelunking by searching for files on the SD card.
The problem is that by supporting both internal memory and an external SD card, it suddenly becomes much more difficult to follow this principle. For a particular shot, should the camera save it to the internal 16gb or to the SD card? Apps from Market – should they be put on the internal memory or on the SD card? And so on. Yes, we can solve this by making the user choose or set the settings. But that’s ultimately what the file selection dialog is, or something similar to it so much that we don’t like it either.
Apart from that, there will also be consequences for the API – if you plug in an SD card with photos, should the system media content provider index them…? If so, applications will suffer because they weren’t designed to take into account that photos can suddenly appear and disappear.
At some point, we’ll probably add the concept of importing/exporting from pluggable media. Then the camera will always save photos to the internal 16gb, and when you stick in an SD card (or plug in a USB flash drive), you can start migrating or get an import/export window. But until then, most devices will either have an SD card or a large internal memory, but not both. I totally understand that many people like SD cards, and I myself miss USB Mass Storage, but that’s why it’s so cool that we have so many machines to choose from 🙂
And in general, of course, it’s a tangle of problems. We’re already thinking about compromises for future versions here.

I hope this helped you clarify things a bit too, and it was interesting to have a look into the inner workings of Android developers 🙂

You may also like