About USB Mass Storage Support in Ice Cream Sandwich

From the early reviews of devices (namely the Galaxy Nexus) on the new version of Android 4.0 (also known as ICS, also called “ice cream sandwich”), it turned out that they do not support such a great chip as USB Mass Storage, i.e. Using the phone as a flash drive, without additional tweaks. Users of Android devices, up to version 3.0 of “Honeycomb” (and, as it turned out, the changes occurred in this version) know that in order to transfer files to or from the phone, it was enough just to plug it into the computer without regard to which operating system or software installed on it. It is logical that the news about the disappearance of this option in new versions did not arouse enthusiasm among Android users, and even made many people think about the existence of a certain problem or flaw. Fortunately, one of their Google engineers, Dan Morrill, in the comments to the angry post in reddit , clarified the situation by explaining in detail what actually happened and why. In my opinion this is very interesting, so I translate the translation of his comments below.

ICS itself supports USB Mass Storage (UMS). And the Galaxy Nexus phone is not. This is the same story as Honeycomb: HC supports UMS, but the Xoom tablet does not. If a device has an external SD card, then access to it via UMS is supported. If only the internal memory is available (as with the Xoom and Galaxy Nexus), then the device’s memory access is supported only via MTP * (Media Transfer Protocol) and PTP * (Picture Transfer Protocol) . Physically, it is impossible to support UMS on devices that do not have a dedicated partition for storing information (such as, for example, an external SD card or a separate partition, as in Nexus S). The reason is that USM and this is a block low-level protocol that gives the host machine direct access to the physical blocks of the media, which prevents it from being simultaneously mounted in Android. With the new integrated storage model that we introduced into Honeycomb, all 32GB (well, or all 16GB, or all N ...) are fully shared with both applications and media files. You no longer have to sadly look at the free 5GB on your Nexus S, while the internal section for applications is packed to capacity - now this is one big, happy section. Unfortunately, the price that had to be paid for this is that Android can no longer afford to give the PC direct access and allow it to be hauled to the USB storage device with impunity. Instead, we use MTP. On Windows (which most users have), there is built-in support for MTP in the explorer, and the device looks exactly the same as a regular drive. On Linux and Mac, unfortunately, things are not so simple, but I am sure that soon the situation will improve. In general, this should make using the phone much more convenient.

To the question if Nexus S has only internal memory, as programs like file managers work without root, Dan explained:
')

Magic. ;)

First, we allocate a directory on the internal memory that will be an “SD card”. Then we take the FUSE file system, which does nothing except remounting this directory as / sdcard with access control turned off. In addition to access, FUSE is just a pass-through shell transmitting the record and read directly to / from the directory. In other words, we use the FUSE file-file system, to remount a specific directory that is disguised as an SD card. This is completely transparent to applications that do not know that they do not directly access the disk.

Further, to the question whether it turns out that for the sdcard directory there is no access control, it reminds:

Yes. Actually, by definition, the folder / sdcard working under FAT32 (or, as it is called in the API, “external storage folder”) does not support restricted access, which is normal, since it is common, open to all file servers, where one application can tread on files other. She was originally conceived for such things as music and photos, and not private data that “live” in the personal storage of applications located on the internal memory with shared access.
On devices without an SD card, the only physically file system is the storage of personal application data. So we choose a directory, declare it as a garbage file, mount it as a separate FUSE file system that ignores access rights, just as they are ignored in FAT32.

On the reasons for all these changes, Dan explained:

(...) We did not do this because we wanted to switch to ext3, although we won it as a side effect. We did this because we wanted to combine publicly accessible storage space for information (for example, for music and photos) with internal storage for applications. We are tired of watching phone manufacturers include gigabytes of memory for music, while users still run out of space for applications and information. This approach allows you to combine everything into one section, which is much better.

Another person asked why it is impossible to use both approaches, because the memory slot takes up very little space. To which, it was told a little about the ideology of Android:

Technically, there is no problem in iron to deliver both. The problem is that this will not make a convenient interface.
One of the basic principles of Android is that the user does not need a file manager. Never. We wanted to avoid the syndrome when the file selection dialog pops up for every sneeze, as is often the case in other OSs. Internal information with which applications can work should be simply accessible “by magic” or stored in the cloud. You can not force the user to engage in speleology, searching for files on the SD-card.

The problem is that supporting both internal memory and external SD card, suddenly following this principle becomes much more difficult. For a specific picture, the camera should save it to the internal 16GB or SD card? Applications from the Market - put them on the internal memory or on the SD? And so on. Yes, we can decide this by forcing the user to choose or set the settings. But this ultimately is that file selection dialog, or something like it so much that we don’t like it either.

In addition, there will be consequences for the API - if you stick an SD card with photos, should the system media content provider index them? .. If so, applications will suffer, because they were not designed to take into account that photos can suddenly appear and disappear .
At some point, we will probably add the concept of import / export from pluggable media. Then the camera will always save photos to internal 16GB, and when you stick an SD card (or connect a USB flash drive), you can start the migration or get an import / export window. But until that moment, most devices will have either an SD card or a large internal memory, but not both. I understand that many people like SD cards, and I myself don’t have enough USB Mass Storage, but that’s why it’s so cool that we have so many devices to choose from :)
In general, of course, this is a tangle of problems. We are already thinking about compromises for future versions.

I hope this helped you a little to clarify the situation too, and it was interesting to look at the internal kitchen of Android developers :)