Ice Cream SandwichでのUSB大容量ストレージのサポートについて

Android 4.0の新バージョン(別名ICS、別名「冷凍サンドイッチ」)でのデバイス(つまりGalaxy Nexus)の初期レビューから、USB Mass Storageなどのすばらしい機能をサポートしていないことが判明しました。 電話をフラッシュドライブとして使用します。 バージョン3.0までのAndroidデバイス(「ハニカム」)のユーザー(およびこのバージョンで変更が行われたことが判明しました)は、携帯電話との間でファイルを転送するには、何が動作しているかに関係なくコンピューターに貼り付けるだけで十分であることを知っていますシステムまたはソフトウェアがインストールされています。 新しいバージョンでのこのオプションの消失に関するニュースは、Androidユーザーの間で熱狂を引き起こさず、多くの人が問題や欠陥の存在について考えさえしたことは論理的です。 幸いなことに、Googleのエンジニアの1人であるダンモリルはredditでの怒った投稿に対するコメントで、状況を明確にし、実際に何が起こったのか、そしてその理由を詳しく説明しました。 私の意見では、これは非常に興味深いので、彼のコメントの翻訳を以下に翻訳します。





ICS自体はUSB大容量記憶装置(UMS)をサポートしています。 しかし、Galaxy Nexusはそうではありません。 これはHoneycombと同じ話です。HCはUMSをサポートしますが、Xoomタブレットはサポートしません。 特定のデバイスに外部SDカードがある場合、UMSを介したアクセスがサポートされます。 組み込みメモリのみが使用可能な場合(XoomやGalaxy Nexusなど)、デバイスのメモリへのアクセスはMTP *(メディア転送プロトコル)およびPTP *(画像転送プロトコル)を介してのみサポートされます。 物理的には、情報を保存するための専用パーティションがないデバイス(たとえば、Nexus Sのような外部SDカードや別のパーティション)でUMSをサポートすることはできません。 その理由は、USMは、ホストマシンがメディアの物理ブロックに直接アクセスできるようにする低レベルのブロックプロトコルであり、Androidに同時にマウントされることを防ぐためです。 Honeycombで導入した情報を保存するための新しい統合モデルでは、すべての32GB(まあ、またはすべて16GB、またはすべてN ...)がアプリケーションとメディアファイルの両方を完全に共有しています。 Nexus Sの無料の5GBで悲しむ必要はもうありません。アプリケーションの内部セクションは眼球に詰まっています。これが1つの大きな、楽しいセクションです。 残念なことに、このために支払わなければならなかった代償は、AndroidがPCへの直接アクセスを提供する余裕がなくなり、USBストレージデバイスに免責を与えることができなくなることです。 代わりに、MTPを使用します。 Windows(ほとんどのユーザーが持っています)では、エクスプローラーにMTPの組み込みサポートがあり、デバイスは通常のディスクとまったく同じに見えます。 LinuxとMacでは、残念なことに、すべてがそれほど単純ではありませんが、すぐに状況が改善されると確信しています。 一般に、これにより電話の使用がはるかに便利になります。




Nexus Sに内部メモリのみがあるかどうかを尋ねられた場合、ファイルマネージャーなどのプログラムはルートなしでどのように機能するのか、Danは説明しました。



魔法。 ;)



まず、「SDカード」となる内部メモリのディレクトリを選択します。 次に、FUSEファイルシステムを使用します。FUSEファイルシステムは、アクセス制御をオフにしてこのディレクトリを/ sdcardとして再マウントするだけです。 FUSEは、アクセスに加えて、ディレクトリとの間で直接読み書きを転送するエンドツーエンドのシェルです。 つまり、FUSE lindenファイルシステムを使用して、SDカードになりすます特定のディレクトリを再マウントします。 これは、ディスクに直接アクセスしていないことを知らないアプリケーションに対して完全に透過的です。





さらに、sdcardディレクトリのアクセス制御がないかどうかを尋ねられたとき、それは思い出します:



はい 実際には、定義により、FAT32で動作する/ sdcardフォルダー(またはAPIで「外部ストレージメディアフォルダー」と呼ばれる)は差別化されたアクセスをサポートしていません。別の。 もともとは、共有アクセスで内部メモリにあるアプリケーションの個人用ストレージに「保存」されるプライベートデータではなく、音楽や写真などのために考案されました。

SDカードのないデバイスでは、物理的なファイルシステムは個人データストレージアプリケーションのみです。 したがって、ディレクトリを選択し、ファイルトラッシュとして宣言し、FAT32で無視されるのと同じように、アクセス権を無視する別のFUSEファイルシステムとしてマウントします。




これらすべての変更の理由について、ダンは説明しました:



(...)ext3に切り替えたかったため、これを行いませんでしたが、これは副作用として勝ちました。 これは、情報(音楽や写真など)を保存するためのパブリックスペースとアプリケーション用の内部ストレージを組み合わせたいためです。 電話メーカーが音楽用にギガバイトのメモリをどのように搭載しているかを見るのにうんざりしており、ユーザーはアプリケーションや情報のためのスペースを使い果たしています。 このアプローチにより、すべてを1つのセクションにまとめることができます。




別の人は、メモリスロットがかなりのスペースを占有するため、両方のアプローチを使用できない理由を尋ねました。 それに、Androidのイデオロギーについて少し話されました:



技術的には、鉄では両方を入れても問題はありません。 問題は、便利なインターフェースではこれができないことです。

Androidの基本原則の1つは、ユーザーがファイルマネージャーを必要としないことです。 決して。 他のOSでよくあるように、ファイル選択ダイアログがすべてのユーザーに対してポップアップするときの症候群を回避したかったのです。 アプリケーションが使用できる内部情報は、単に「魔法で」利用できるようにするか、クラウドに保存する必要があります。 SDカード上のファイルを検索して、ユーザーに洞窟探検を強制することはできません。



問題は、内部メモリと外部SDカードの両方をサポートすることにより、この原則に従うことが突然難しくなることです。 特定のショットの場合、カメラは内部の16GBに保存する必要がありますか、それともSDカードに保存する必要がありますか? 市場からのアプリケーション-内部メモリまたはSDに配置しますか? などなど。 はい、ユーザーに設定の選択または設定を強制することでこれを解決できます。 しかし、最終的にこれはファイル選択ダイアログ、またはそれに似たもので、あまり気に入らないものです。



さらに、APIに影響があります-写真にSDカードを貼り付けた場合、システムメディアコンテンツプロバイダーはそれらにインデックスを付ける必要がありますか? 。

ある時点で、おそらくプラグ可能メディアからのインポート/エクスポートの概念を追加します。 その後、カメラは常に内部16GBに写真を保存します。SDカードを差し込む(またはUSBフラッシュドライブを差し込む)と、移行を開始したり、インポート/エクスポートウィンドウを取得したりできます。 しかし、その瞬間まで、ほとんどのデバイスにはSDカードまたは大容量の内部メモリがありますが、両方はありません。 多くの人がSDカードを好むこと、そして私自身はUSB大容量記憶装置を欠いていることを理解していますが、だからこそ選択できるデバイスが非常に多いのでとてもクールです:)

一般的に、もちろん、これは問題のもつれです。 将来のバージョンについては、すでに妥協を検討しています。




これが少し状況を明らかにするのに役立つことを願っており、Android開発者の内部キッチンを見るのは興味深いことでした:)



All Articles