В предыдущей статье мы попытались описать тот хаос, который творился в 1998-2003 гг. в области протоколов сопряжения плееров с ПК. Период 2003-2004 гг. стал для отрасли временем упорядочения. Множество ручейков проприетарных протоколов сменилось тремя стройными потоками. Точнее, двумя с половиной, т.к. два из этих потоков представляли собой вариации одного и того же протокола.

Это были:

1. «чистый» Mass Storage протокол
2. протокол Mass Storage с дополнительной программной настройкой
3. протокол MTP.

Чистый Mass Storage использовался наибольшим количеством производителей, особенно компаниями небольшого калибра из Кореи или Китая. В России он стал наиболее популярным протоколом. О нем наш сегодняшний рассказ.

Для обозначения Mass Storage «в быту» используются две аббревиатуры – MSC и UMS. MSC (Mass Storage Class) является официальной, а UMS (возможны варианты расшифровки: USB/Universal Mass Storage) – «народной». Друг другу они не противоречат, а скорее дополняют.

MSC сообщает о том, что протокол входит в число утвержденных стандартных «классов устройств» в рамках спецификации USB и тем самым является индустриальным стандартом де-юре. UMS говорит об универсальности протокола, который на сегодня поддерживается большинством операционных систем и бесчисленным множеством конечных устройств, что делает его стандартом и де-факто. Вариант расшифровки UMS как USB Mass Storage дополняет эту информацию, уточняя, что в качестве физической линии используется интерфейс USB. Буквы MS (Mass Storage), общие для всех аббревиатур, показывают, что перед нами протокол, предназначенный для работы с устройствами хранения больших объемов данных. Именно для них и был разработан данный стандарт – для «флэшек», карт-ридеров, мобильных HDD-накопителей. Как он попал в портативные плееры?

Протокол Mass Storage задумывался в первую очередь для подобных устройств. Его появление в MP3-плеерах было вынужденным шагом

В прошлых материалах мы неоднократно говорили о том, как стихийно, неожиданно появились и начали развиваться портативные аудиоплееры. Индустрия просто не хотела их замечать, сначала в силу их маргинальности, позже – из-за надуманной связи этих устройств с цифровым пиратством. Это имело много последствий, и одним из них было то, что плееры «обошли» при раздаче классов устройств USB.

Взглянем на список этих классов: тут есть и внешние звуковые карты, и коммуникационные устройства, и отдельный класс для периферии типа мышей и клавиатур, есть свои классы для принтеров, USB-хабов, вэб-камер, адаптеров беспроводной связи. Свой класс есть и для цифровых камер. И только аудио- и мультимедиа-плееры остались в категории «прочие».

Среди стандартных классов USB нашлось место для самых разных устройств. Но только не для мультимедиа плееров

Добрых лет пять никто не задумывался о разработке отдельного класса для них. Производителям оставалось выбирать из того, что есть.

На этом фоне MSC/UMS был единственным универсальным решением. Если ограничивать задачи исключительно «тупой» загрузкой контента в плеер, то ничего больше и не нужно. К тому же, протокол позволял превратить плеер в мобильный накопитель. Простые продавцы и покупатели и сейчас описывают плееры с данным протоколом как «работающие как флешка», «подключающиеся как флеш-накопитель» «программы ставить никакие не надо», «можно файлы хранить» и т.д. и т.п.

Простенький плейдрайв – « MP3- Stick» и Mass Storage протокол – созданы друг для друга

Эта дополнительная возможность хорошо вписывалась в подход «много-в-одном», выбранный азиатскими производителями MP3-плееров. Именно они стали пионерами в адаптации MSC/UMS в аудиоплееры. Они и компания Sigmatel, чья платформа STMP3400 в начале 2003 года начала поддерживать этот протокол.

Январь 2003 года – Sigmatel объявляет о поддержке Mass Storage в своих платформах D- Major

Достоинства протокола. Главное – простота: все операции осуществляются через стандартные файловые оболочки, в т.ч. Windows Explorer (Проводник), никакие дополнительные знания или обучение для работы с ним не требуются.

Распространенность – уже Windows Me и 2000 имели базовую поддержку протокола, Windows XP поддерживал его полностью. Множество других ОС – MacOS, Linux и т.п. – совместимы с Mass Storage.

ОС, в том или ином виде поддерживающие Mass Storage протокол

Сегодня сложнее найти ПК, не поддерживающий этот протокол. Поддержка в данном случае означает наличие драйверов протокола в составе операционной системы.

Mass Storage плеер на 1.8” жестком диске Toshiba подключен к ПК. Как MSC-устройство он использует стандартный драйвер USBSTOR. SYS, входящий в состав ОС. Как накопитель он также использует стандартные драйверы Windows. Установка дополнительных драйверов не требуется .

Так как вся работа с контентом также ведется стандартными средствами, через Windows Explorer (Проводник), у пользователя вообще не возникает необходимости в установке чего бы то ни было: вся поддержка протокола уже встроена в ОС.

Плеер виден в Проводнике Windows как еще один жесткий диск. Вся работа с контентом ведется в Проводнике или любом файловом менеджере на выбор пользователя. Установка дополнительного программного обеспечения не требуется

Получается настоящий Plug-and-Play: вынул из коробки, подключил и пользуйся. По таким параметрам, как прозрачность, невидимость для пользователя этот протокол просто не имеет равных.

С точки зрения совместимости с портативными устройствами у нас тоже все хорошо: протокол не зависит от файловых систем и может работать с любой из них, если она поддерживается ОС.

Немаловажным является существование спецификации USB host (on the go), позволяющей подключать Mass Storage устройства к другим портативным (и не портативным) аппаратам. Сегодня MSC-совместимый плеер можно подключить к обширному перечню устройств, будь то игровая приставка, стереосистема, автомагнитола, FM-трансмиттер, другой плеер.

Набирают популярность автомобильные FM-трансмиттеры, позволяющие подключать к себе любой Mass Storage плеер

Недостатки протокола являются продолжением его достоинств. Его функциональность является базовой, примитивной. Фактически он не способен ни на что, кроме копирования данных взад-вперед.

Но данные, с которыми имеет дело плеер, являются больше чем просто набором двоичных символов, это контент. У каждой единицы контента, будь то песня или файл, есть целый ряд свойств, таких, как название, формат, автор, продолжительность и т.п. Отдельные единицы могут быть частью более сложных совокупностей, таких, как альбом, плей-лист.

Ни о чем подобном Mass Storage знать не знает, что возлагает все заботы о менеджменте контента либо на пользователя, либо на встроенное ПО плеера. Последнее же чаще всего не способно эффективно справляться с задачей управления большим количеством контента. Как следствие, большинство MSC/UMS-плееров имеют крайне бедный механизм навигации – по папкам, аналогично навигации в Windows Explorer. При этом не используется значительный объем информации, содержащийся в метаданных, тэгах, который удобен для классификации контента.

Информация, которая может содержаться в тэгах (на примере программы MP3 tag). Мало что из этого используется в Mass Storage плеерах

Пользователь вынужден организовывать свой контент самостоятельно, с помощью системы вложенных папок. При этом, избрав, к примеру, систему классификации «песня-альбом-автор», он не сможет быстро и безболезненно перейти к системе «песня-жанр» или «песня-год записи», ему придется перетряхивать всю библиотеку.

Очень слаба по своим возможностям организация таких плеерах плей-листов. Плей-лист обычно возможен только один. Работа с плей-листами возложена исключительно на само устройство, и если через ПК в режиме MSC/UMS был удален один из файлов, входящих в плей-лист, это может нарушить работу всего листа в целом. Такая премиум-возможность, как отображение обложки альбома (Album Art или Jacket), «чистым» MSC/UMS-плеерам недоступна в принципе. Теоретически ее можно реализовать загрузкой графического файла из папки, но на практике никто этого пока не сделал. А если сделает, пользователю придется вручную рассовывать во все папки соответствующие картинки. Некоторые плееры имеют возможность отображения слов песни (Lyrics), но берутся эти слова не из метаданных: пользователю приходится самостоятельно подготавливать их с помощью специальной программы.

Во всем этом главная проблема Mass Storage. Плеер – это больше, чем просто мобильный накопитель, для эффективной работы он должен иметь глубокое понимание того, что, собственно, хранится в его памяти. Будучи современным мультимедийным устройством, рассчитанным на самый широкий круг пользователей, он не может просто пробубнить подряд все, что на него записано. Он должен уметь рассказать о том, что мы смотрим или слушаем, причем кратко, исчерпывающе и ненавязчиво, как высококлассный конферансье. Он, словно опытный библиотекарь, должен помочь нам быстро найти среди тысяч песен именно то, что нам нужно, даже если мы подзабыли название. Во всем этом предельно ограниченный в своих возможностях протокол MSC/UMS ему не помощник. И свежий зажигательный шлягер, и кандидатская диссертация, и своп-файл Windows для него являются лишь безликими массивами данных. Это превращает протокол в своего рода обезличивающее «бутылочное горлышко» между двумя мощными мультимедиа-системами – плеером и ПК. На плечи последних падает вся тяжесть преобразования безликого потока информации в удобную для пользователя форму.

На ПК все зависит от самого пользователя: проявит он усидчивость и изобретательность – организует музыкальную библиотеку на зависть всем. А может и просто сваливать все в одну папку, пока там не станет совершенно невозможно что-то найти.

На плеере же все зависит от разработчика, а они вовсе не горят желанием прилагать большие усилия для разработки мощной программной начинки. В результате конферансье из таких плееров так себе – монотонным голосом он прочитает название песни, автора, в лучшем случае – альбома. А может и вовсе только имя файла.

Интерфейс iPod по сравнению с интерфейсом Mass Storage плеера iriver h300 выглядит более спартанским, но при этом отображает значительно больше информации о проигрываемом треке. При этом плеер от iriver – это еще относительно удачный пример Mass Storage плеера

И библиотекарь он никудышный – так, рукой направление укажет, где искать, но не более.

Пользователь Mass Storage плеера (Cowon X5 в данном случае, слева) при поиске интересующей композиции может руководствоваться только логикой папок и файлов, созданной им самим. В случае применения иных решений (как в Creative Zen Touch, справа) у них есть возможность свободного поиска по параметрам

Есть отдельные исключения (например, плееры от Archos), но их не много.

Эта ситуация имеет очень простое следствие. Пользователи, которые с компьютером «на ты», привыкшие к концепции файлов и папок, не сильно требовательные к внешним эффектам и быстро приспосабливающиеся к новому, стоят горой за чистый Mass Storage. Прозрачность, открытость и распространенность протокола для них преимущества, рядом с которыми меркнут все минусы.

Компании iriver и Cowon своей популярностью среди определенных слоев покупателей обязаны не в последнюю очередь поддержке «свободного» Mass Storage

А вот пресловутые «обычные» пользователи не очень довольны. Для них плеер – это все-таки не флэшка, не хранилище для файлов, а плеер. Аккуратно сооружать пирамиду файлов и папок музыкальной библиотеки у них нет никакого желания, бродить в недрах этой пирамиды на экране плеера, ориентируясь лишь на названия папок, – тоже. Навигация по метаданным, проигрывание с красивым Album Art, автоматическая загрузка на плеер новых песен – все это им гораздо ближе. Значительное количество возвращенных в магазин и обменянных на iPod-ы MSC/UMS-плееров в тех же Соединенных Штатах – тому подтверждение.

И все же тон в отрасли задают производители, не использующие чистый Mass Storage

Есть и еще одна категория недовольных протоколом. Это студии звукозаписи и киностудии. Безразличный ко всему, Mass Storage уж точно никак не сможет отличить «пиратский» трек от честно приобретенного. Производитель, плееры которого поддерживают загрузку контента через «чистый» Mass Storage, вряд ли могут рассчитывать на плодотворное сотрудничество с крупными лейблами. Конечно, небольшим компаниям оно не очень-то и нужно. Но крупные корпорации, желающие дать пользователям вертикальное решение, включая приобретение контента, вынуждены принимать этот фактор во внимание.

В результате производитель, желающий создать плеер, который:

Привлекателен для «простого пользователя» в силу легкой, автоматизированной работы с ним, удобной, быстрой и красивой навигации, эффективного использования метаданных

Не вызывал бы отторжения у киностудий и студий звукозаписи, что позволило бы организовать удобное для этих самых «простых пользователей» (и выгодное для компании) приобретение контента

Не потребует больших вложений в разработку, как по времени, так и по квалификации программистов

– вынужден искать решения за рубежами возможностей «чистого» Mass Storage.

Для обозначения Mass Storage "в быту" используются две аббревиатуры - MSC и UMS. MSC (Mass Storage Class) является официальной, а UMS (возможны варианты расшифровки: USB/Universal Mass Storage) - "народной". Друг другу они не противоречат, а скорее дополняют.

MSC сообщает о том, что протокол входит в число утвержденных стандартных "классов устройств" в рамках спецификации USB и тем самым является индустриальным стандартом де-юре. UMS говорит об универсальности протокола, который на сегодня поддерживается большинством операционных систем и бесчисленным множеством конечных устройств, что делает его стандартом и де-факто. Вариант расшифровки UMS как USB Mass Storage дополняет эту информацию, уточняя, что в качестве физической линии используется интерфейс USB. Буквы MS (Mass Storage), общие для всех аббревиатур, показывают, что перед нами протокол, предназначенный для работы с устройствами хранения больших объемов данных. Именно для них и был разработан данный стандарт.

К классу устройств USB mass-storage относятся устройства, передающие файлы в одном или в двух направлениях. Типичные представители этого класса устройств: жесткие диски, CD-, DVD-приводы и флешки. Файловая система позволяет пользователю копировать, перемещать и удалять файлы в устройстве.

Почти все устройства USB mass-storage используют протокол передачи только массивов (bulk) данных (bulk-only transport, BOT, также называемый BBB). (исключение составляют некоторые полноскоростные дисководы для дискет, которые используют несколько типов передач данных: управляющие, передача массивов и передачи по прерываниям (control, bulk, interrupt), такой протокол называется CBI). Устройства USB mass-storage также используют команды SCSI, определяемые различными стандартами SCSI (Small Computer System Interface).

Протокол передачи только массивов данных определяет способ, с помощью которого USB хост может посылать команды и получать ответы используя передачу массивов данных, определенную в спецификации USB. В протоколе передачи только массивов данных каждый обмен информацией требует 2 или 3 USB передач данных. В первой передаче хост посылает команду в структуре, называемой CBW (Command Block Wrapper). За множеством CBW следует передача, которая содержит данные, посылаемые хостом или устройством. В последней передаче устройство возвращает статус в структуре, называемой CSW (Command Status Wrapper).

Достоинства протокола . Главное - простота: все операции осуществляются через стандартные файловые оболочки, в т.ч. Windows Explorer (Проводник), никакие дополнительные знания или обучение для работы с ним не требуются.

Распространенность - уже Windows Me и 2000 имели базовую поддержку протокола, Windows XP поддерживал его полностью. Множество других ОС - MacOS, Linux и т.п. - совместимы с Mass Storage.

Немаловажным является существование спецификации USB host (on the go), позволяющей подключать Mass Storage устройства к другим портативным (и не портативным) аппаратам.

Спецификации:

		221 Kb Engl USB Mass Storage Class – UFI Command Specification
		103 Kb Engl USB Mass Storage Class – Bulk Only Transport
		103 Kb Engl

23 ноября 2011 в 02:17

Про поддержку «USB Mass Storage» в Ice Cream Sandwich

• Разработка под Android

Из ранних обзоров девайсов (а именно Galaxy Nexus) на новой версии Андроида 4.0 (он же ICS, он же «мороженный бутерброд») выяснилось, что они не поддерживают такую замечательную фишку, как USB Mass Storage, т.е. использование телефона как флешки, без дополнительных ухищрений. Пользователи андроид-аппаратов, вплоть до версии 3.0 «Honeycomb» (а, как оказалось, изменения произошли именно в этой версии) знают, что чтобы перекинуть файлы на телефон или с него, достаточно было просто воткнуть его в компьютер без связи с тем какая операционная система или софт на нем установлены. Логично, что новости об исчезновении этой опции в новых версиях не вызвали энтузиазма среди пользователей андроида, и даже заставили многих задуматься о наличии некой проблемы или недоработки. К счастью, один их инженеров Google Дан Морилл (Dan Morrill) в комментариях к гневному посту в reddit , прояснил ситуацию, подробно объяснив о том, что, собственно произошло, и почему. По моему это очень любопытно, так что ниже перевожу перевод его комментариев.

Сам ICS поддерживает USB Mass Storage (UMS). А телефон Galaxy Nexus - нет. Это та-же история, что и с Honeycomb: HC поддерживает UMS, а планшет Xoom - нет. Если у некого аппарата есть внешняя SD-карточка, то к ней поддерживается доступ через UMS. Если в наличии только встроенная память (как у Xoom и Galaxy Nexus) то доступ к памяти устройства поддерживается только по MTP *(Media Transfer Protocol) и PTP *(Picture Transfer Protocol) . Физически, невозможно поддерживать UMS на устройствах, у которых нету выделенного раздела для хранения информации (как, например, внешней SD-карточки или отдельного раздела, как в Nexus S). Причина в том, что USM и это блочный низкоуровневый протокол, который дает хост-машине прямой доступ к физическим блокам носителя, что не позволяет ему быть одновременно примонтированным в Андроиде. С новой объединенной моделью хранения информации, которую мы ввели в Honeycomb, все 32гб (ну или все 16гб, или все N...) полностью находятся в совместном владении и приложениями и медиа-файлами. Вам больше не приходится грустно взирать на свободные 5гб на вашем Nexus S, в то время как внутренний раздел для приложений забит под завязку - теперь это один большой, счастливый раздел. К сожалению, цена, которую за это пришлось заплатить - это то, что Андроид больше не может позволить себе предоставить ПК прямой доступ и дать ему безнаказанно домогаться до носителя информации по USB. Вместо этого, мы используем MTP. На виндоуз (который у большинства пользователей), есть встроенная поддержка MTP и в эксплорере, и устройство выглядит точно так-же как обычный диск. На Линуксе и Маке, к сожалению, все не так просто, но я уверен, что в скором времени, ситуация улучшится. В целом, это должно сделать использование телефона гораздо более удобным.

На вопрос, если у Nexus S только внутренняя память, как-же программы вроде файловых менеджеров работаю без рута, Дан объяснил:

Волшебство. ;)

Сначала, мы выделяем директорию на внутренней памяти которая будет «SD-карточкой». Затем мы берем файловую систему FUSE, которая не делает ничего, кроме перемонтирования этой директории как /sdcard c выключенной проверкой доступов. Кроме доступов, FUSE это просто сквозная оболочка передающая запись и чтение прямо в/из директорию. Другими словами, мы используем липовую файловую систему FUSE, для перемонтирования определенной директории которая маскируется под SD-карточку. Это полностью прозрачно для приложений, которые не знают, что они не обращаются напрямую к диску.

Да. Собственно по определению работающая под FAT32 папка /sdcard (или, как она называется в API - «папка внешнего носителя информации») не поддерживает разграниченного доступа, что нормально, так как это общая, открытая для всех файлопомойка, где одно приложение может топтаться по файлам другого. Она изначально задумывалась для таких вещей как музыка и фотографии, а не приватных данных, которые «живут» в личном хранилище у приложений, расположенном на внутренней памяти с разделенным доступом.
На устройствах без SD-карточки, единственная физически файловая система - это хранилища личный данных приложений. Так что мы выбираем директорию, объявляем ее файловой помойкой, монтируем ее как отдельную FUSE файловую систему, которая игнорирует права доступа, так же как они игнорируются в FAT32.

О причинах всех этих изменений Дан объяснил:

(...) Мы не сделали это потому, что мы хотели перейти на ext3, хотя мы и выиграли это как побочный эффект. Мы сделали это так как хотели объединить общедоступное пространство для хранения информации (например для музыки и фотографий) с внутренним хранилищем для приложений. Нам надоело наблюдать, как производители телефонов включают гигабайты памяти для музыки, а у пользователей все равно заканчивается место для приложений и информации. Такой подход позволяет объединить все в один раздел, что намного лучше.

Еще один человек поинтересовался почему нельзя использовать оба подхода, ведь слот памяти занимает достаточно мало места. На что, было рассказано немного об идеологии Андроида:

Технически в железе нет никакой проблемы поставить и то и другое. Проблема в том, что этому не сделаешь удобный интерфейс.
Один из базовых принципов Андроида - это то, чтоб пользователю не нужен был файловый менеджер. Никогда. Мы хотели избежать синдрома, когда на каждый чих выскакивает диалог выбора файла, как это часто бывает в других OS. Внутренняя информация, с которой приложения умеют работать, должна быть просто доступна «по волшебству» или же храниться в облаке. Нельзя заставлять пользователя заниматься спелеологией, разыскивая файлы на SD-карточке.

Проблема в том, что поддерживая и внутреннюю память и внешнюю SD-карточку, следовать этому принципу внезапно становится намного сложнее. Для конкретного снимка, камера должна сохранять его на внутренние 16гб или на SD карточку? Приложения из Маркета - их ставить на внутреннюю память или на SD? И так далее. Да, мы можем решить это заставив пользователя самого выбирать или выставлять настройках. Но это в конечном счете и есть тот диалог выбора файла, или что-то на него похожее настолько, что нам это так-же не нравится.

Кроме этого, будут последствия и для API - если вы втыкаете SD карточку с фотографиями, должен ли их индексировать системный media content provider?.. Если да, то пострадают приложения, потому как они не были спроектированы учитывать, что фотографии могут внезапно появляться и исчезать.
В какой-то момент, мы наверное добавим концепцию импорта/экспорта с подключаемого носителя. Тогда камера всегда будет сохранять фотографии на внутренние 16гб, а когда вы воткнете SD-карточку (или подключите USB флешку), вы сможете начать миграцию или получите окно импорта/экспорта. Но до того момента, у большинства аппаратов будет или SD-карточка или большая внутренняя память, но не оба варианта. Я прекрасно понимаю, что многим нравится SD-карточки, и мне самому не хватает USB Mass Storage, но именно по этому так классно, что у нас есть так много аппаратов, из которых можно выбирать:)
А вообще, конечно, это клубок проблем. Мы тут уже обдумываем компромиссы для будущих версий.

Надеюсь, вам это тоже помогла немного прояснить ситуацию, и было интересно заглянуть на внутреннюю кухню разработчиков Андроида:)

По поводу режима USB Mass Storage, неизвестно куда "исчезнувшего" из Android Ice Cream Sandwich, в интернете нынче бушует много страстей. Высказались все, и знающие, но редко высказывающися, и незнающие, зато всегда имеющие мнение. Страсти бушуют настолько нешуточные, что мне даже пришлось "вернуться" с блоггерской пенсии, зайти в ЖЖ и написать несколько строк.

Если по-быстрому и по сути:
- USB Mass Storage mode - это режим подключения SD карточки в телефоне, когда телефон превращается в card reader для SD карточки.
- USB Mass Storage mode требует наличия в телефоне отдельной SD карточки, заменяемой или встроенной. То есть зависит он от конретной кофигурации "железа" в телефоне.
- Из Android 4.x ICS поддержка USB Mass Storage никуда не делась - достаточно поставить ICS на Nexus S, и вы увидите, что он там есть и прекрасно работает.
- USB Mass Storage не поддерживается на Galaxy Nexus, опять-таки из-за кофигурации "железа" последнего. Кто-то просто перепутал железо с софтом, а народ это подхватил.
- Преживающим за будущие телефоны: не переживайте. Производители телефонов прекрасно знают, что на многих рынках наличие SD card в телефоне важно для покупателей, и во многие модели будет включена поддержка заменяемой внешней SD карточки, зачастую вместе со встренной "внутренней" SD карточкой.

Начнем издалека. С кофигурацией хард драйвов при сборке домашнего компьютера сталкивались все гики. Кто-то покупает один большой и разбивает его на несколько разделов, кто-то покупает небольшой SSD для установки на него системы и большой внутренний SATA для хранения файлов, кто-то докупает еще и внешний USB для хранения/переноса фильмов, фотографий и музыки. Надо прикидывать, какого размера покупать диски, какой скорости, с каким интерфейсом подключения, какой фирмой произведенные, и т.п. Знакомая ситуация? Так вот с аналогичной ситуацией сталкиваются и производители телефонов при проектировании и производстве очередной модели.

Что нужно хранить на телефоне? Да практически то же самое:
1. Системные файлы (ОС)
2. Установленные программы и их файлы
3. Файлы пользователя

Допустим, вам надо сделать так, чтобы разные типы данных хранились на разных дисках: C, D и Е, соответственно. Про подобную разбивку и ее достоинства я . Напомню, что подобное разделение дает некую "гибкость", в том числе и на десктопе. Например, надо переустановить систему - форматируем С, а наши данные на D и Е остаются. Тогда речь шла в основном про C и D. А теперь поговорим про Е.

Е - это где вы и ваши программы хранят свои данные, особенно если эти данные занимают много места. Вы обычно кладете туда свой медиа контент (фильмы, музыку, фото), камера туда пишет новые фотографии и видео, GPS навигаторы загружают туда свои гигабайтные карты, и т.п. В Андроиде - это ваша SD карточка. Исторически так сложилось, что "внутренняя" флеш-память для C и D была дорогая, и если нужно было хранить что-то обьемное, это нужно было делать на внешней дешевой microSD, то есть диске Е. Дополнительной радостью от этого было то, что пользователь получал возможность регулировать размер "диска Е", а также использовать microSD для обмена данными с другими устройствами, с целью чего она форматировалась под файловую систему VFAT, понятную всем. Примерно так, как если бы диск Е у вас был внешним USB хардом, и вы бы его подключили к другому компьютеру чтобы "скинуть фильмы".

Продолжая аналогию microSD с USB внешним хардом, скажем, что процесс подключения его к другому устройсву (компьютеру, медиа плееру, и т.п.) требовал его полного отключения от вашего смартфона. Нельзя же USB хард воткнуть сразу в два устройства. Вот и при включении USB Mass Storage Mode контроллер чтения/записи SD карты полностью переключался на USB. В результате телефон доступа к SD карте больше не имел, а контроллер ее выступал в роли USB ридера. Как и в случае с любым ридером, компьютер работал с SD картой напрямую. То есть если бы она была отформатирована под файловую систему, неизвестную ОС, стоящей на компьютере, ОС вам просто сказала бы, что целостность SD карты нарушена, и ее надо бы отформатировать. Так работает любой ридер, он не понимает файловой структуры на накопителе, он просто дает доступ к "блокам" (кластерам) на нем, остальное должна "понять" ОС.

Производители экспериментируют много. В каких-то телефонах ставят быстрый дорогой маленький С, менее быстрый, более дешевый, и больший по размеру D, и дают пользователю самому выбрать Е (Galaxy S), в каких-то C и D "живут" на одном "физическом харде", а Е по-прежему живет на microSD. А в каких-то (таблетки, Galaxy Nexus) - все живет как логические разделы на одном большом чипе. А бывают, что производители ставят и внутренний логический Е, а пользователю дают возможность воткнуть еще и диск F - внешнюю microSD (Samsung Vibrant). Выбор конфигурации обусловлен многими факторами. Факторы разные, в зависимости от компании. Например, в устройствах от Эппла все будет жить на одном внутреннем дорогом чипе. У других конфигурация будет обуславливаться в основном ценой комплектующих, пожеланиями операторов и рынком сбыта. Андроид (благодаря использованию ядра Линукс), спокойно поддерживает любую кофигурацию.

А теперь давайте перейдем на терминологию Линукса, где все устройства (логические диски, дисководы, CD-ROMы и т.п.) являются директориями, и назовем вещи своими именами. С станет /system, D - /data, E - /sdcard. На таблетках (кстати, почему весь сыр-бор не подняли тогда? Куда смотрели критики Андроида?) и на Galaxy Nexus /sdcard - это всего лишь директория /data/media, подмаунченная через FUSE. (О, FUSE - это прекрасная вещь, о ней в другой раз, для совсем безнадежных гиков). Выражаясь нормальным языком, можно сказать, что /sdcard стал таким хитрым линком на /data/media. То есть диск Е стал линком на директорию на диске D. Таким образом, пользовательские программы и пользовательский же медиа контент делят общее пространство на диске. И не получается, что места для музыки осталось еще много, но вам нужно место для очередной программки, но вот его уже не осталось. Прямо как на айФоне.

Почему нельзя включить USB Mass Storage Mode для подобной конфигурации? А именно потому, что надо подключать весь "логический диск" сразу. А он у вас ненастоящий, так как он специально сделан так, чтобы он был варьируемого размера. А чтобы иметь возможность подключать, нужно знать какой кусок чипа отведен под нужный логический диск, то есть фиксировать его размер, чего не хочется делать. "А почему тогда не весь чип" простите вы, "подключите весь чип, а я уж там сам разберусь". Хорошо, подключим весь чип. А у вас там не только и /data и /system, а еще вполне вероятно, что boot, recovery, bootloader - довольно сложная система из нескольких разделов (логических дисков), из которых несколько - в мало кому понятной файловой системе ext4. И если все это дело подключить к компьютеру как внешний USB накопитель, любой компьютер предложит вам это безобразие отформатировать. Думаю, что обьяснять не надо, что бывает, когда на вашем компьютере вдруг оказывается отформатированным диск С.

В качестве замены нам предлагается протокол MTP (Media Transfer Protocol), при использовании которого ваш компьютер видит телефон как MP3 плеер. В Windows такой протокол понимает Windows Media Player (да и сам Windows понимает, начиная с Vista), позволяя переливать на телефон медиа контент из вашей медиатеки (из того же Media Player). Решение менее демократичное, чем USB Mass Storage, но более демократичное, чем тот же iTunes. Решение спорное и не всем понравится, но давайте учтем следующее:

Galaxy Nexus, хоть и является флагманским устройством для Android Ice Cream Sandwich, создан для демонстрации не всех возможностей ОС, а лишь их части. И ни в коем случае возможности ОС не ограничены возможностями данного телефона.

Nexus устройства являются некой "игровой площадкой" Гугла, платформой для тестирования новых возможностей и идей. Вполне вероятно, что какие-то из них куда-то пойдут, а какие-то - нет. Но опробовать их по любому надо.

Nexus устройства другим производителям не указ. Гугл не накладывает ограничений на конфиграцию телефонов. Даже если Андроид не поддерживает какое-то определенное "железо", производителю ничего не стоит добавит поддержку самому - исходники-то открыты, и это делалось не раз. Так что даже если поддержка USB Mass Storage вдруг пропала бы из ICS по воле Гугла, ее быстро добавили бы обратно (это несложно, поверьте мне).

Телефоны на ICS со сьемными SD card и USB Mass Storage будут. Для рынков, где 3G связь медленна или имеет плохое покрытие (например, Индия), наличие в телефоне SD card - один из основных факторов при покупке. И, поверьте мне, производители телефонов прекрасно это знают. И знают, что это востребовано не только в Индии.

Если вы настоящий гик, вы всегда найдете способ перебросить любые (не только медиа) файлы на телефон. Подсказка: adb push file /sdcard/

P.S. Любителям конспирологических теорий: а как вам идея, что Гугл избрала такую конфигурацию, чтобы избежать использования VFAT (обязательный при использовании SD card), опасаясь судебного иска от Майкрософта на основе патента 17-летней давности на использование длинных имен файлов в файловой системе FAT?