Android Kindle SDカード化・その2

 前回さっさと続きを書く筈だったんですが、気付けばいつもの月末でして。
 ぶっちゃけたところ、前回触れた話が全てでそれ以上の進展は何もなかったもんで、腰も重くてですね。
 まぁ、初期の混乱もあって曖昧な情報が流れていて困るからという正義感めいた動機なのか、あるいは単に自分は嘘はつきたくはないという「誠実さの徳」の強迫観念に捕らわれた者故の行動原理と申しますか(ぉ)。

 あれやこれやと経緯を書いた試行錯誤編と、要点について語った解説(モドキ)編みたいな2章構成で準備を始めていたんですが、途中で先に要点をまとめた後に、試行錯誤の詳しい裏を取ろうとしたところでまた「あれ?」みたいになりまして。
 「あ、これアカンやつや」と三度延期コースが垣間見えてしまったところで、一旦要点パートのみを出しますよ。
(※あれ?と思ったのは関連項目での話なので、Android6のSDカード内部ストレージ化の話としては今回で終了です)

 結局前回まとめた通り、ことAndroid Kindleの大量のDLデータをSDカードに移すという点においては、 /sdcard/Android/data/com.amazon.kindle/ を外部SDカード上に載せる必要があり、
 ・内部ストレージとしてフォーマット(メニューのformat as internal storage)
 ・フォーマット後にデータのエクスポート(あるいはメニューからmigrate data)
 重要なのは後者で、これで /storage/emulated/0/ 即ち /sdcard/ 以下をSDカード上のパーティションにマウントさせる。
(※日本の端末はメニュー封印されてるかも。自分は非JPのromを焼いているためか出てきていますが、メニュー名が日本語化されていない時点でお察し下さい。手動手順は割愛。)

 思いっきり英語ですが、以下に一通りの手順説明があるので参考までに。(複数ケースが書かれてるので、最初の”The Android Marshmallow Method” がそれ。)
https://www.howtogeek.com/114667/how-to-install-android-apps-to-the-sd-card-by-default-move-almost-any-app-to-the-sd-card/

■動作概要
 今回の機能を具体的な内部動作の面で見てみると、そもそも、
○従来
・internal(内部メモリ)
アプリ本体 :/data/app/
アプリデータ:/data/data/ (※セーブデータ等、一般ユーザに触らせないもの)
ユーザデータ:/sdcard/ (-> /storage/emurate/0/)
(例:
 写真データ :/sdcard/DCIM/
 アプリワーク:/sdcard/Android/data/
 ... 等々)

・external(外部SDカード)
ユーザデータ:/storage/emurate/***/ 以下に、本体の/sdcard/と同様の構成
(/DCIM/
 /Android/data/
 ... 等々)
 アプリの基本的なファイルは/data/内(一般アクセス権限なし)に置かれていて、これはOSメニューで外部SDカードに移すこともできる(アプリで許可している場合のみ)。尚、移動した場合は、SDカード領域(/storage/emurate/***/)のルート直下に .android_secure として暗号化した形で置かれる。(app2sd等と言われている機能)
 一方、それ以外のユーザデータ・ワークデータ領域(/sdcard/以下) は、元々internal、externalそれぞれに用意されていて、どちらを使うかは個々のアプリ側で切り分ける。でまぁ良心的でないアプリ、あるいは手抜きのアプリはinternal限定になってることが多い。

 問題は、前者(アプリ本体)がOSの機能に委ねられる一方、後者(ユーザデータ)はあくまで各アプリの実装に委ねられるという、管理方針に大きな違いがあること。そりゃあ開発側が一々実装なんてしませんよね(苦笑)。
 で、「アプリ側がサボる(/sdcard/以下しか使わない)んならじゃあ、最初っから/sdcard/を外部SDに当ててやんよ」、ってのが今回のgoogleの対応。
○適用後
・internal(内部メモリ)
アプリ本体 :/data/app/
アプリデータ:/data/data/ (※セーブデータ等、一般ユーザに触らせないもの)

・adoptable storage (外部SDカードパーティション)
ユーザデータ:/sdcard/ (-> /storage/emurate/0/)
 このようにマウントする、つまりは従来内部メモリ内に持っていたユーザデータ領域(/storage/emulate/0/)を直接、外部SDカード上のパーティションにすげ替えることで、内部メモリにしか対応してないアプリでもそのまま使えるよね、ってな発想。
 つまりあくまで後者のユーザデータに関しての扱いの問題なので、従来のアプリのSD移動とは別の話(※)。だけれどもユーザ目線では「SDに移動する」の一言で語られてしまうので話としても分かり辛くなっている。
※ただinternal化した場合にのみSD移動できるようになるアプリもあるのかな? Kindleは元々通常SDにも移動出来てるし(galaxyS7のandroid7でしか確認してませんが)、如何にも動かせなさそうなゲーム系アプリは使ってないので分からんです。

 しかも更に分かり辛いのは、当然ながらアプリ本体は従来通りinternal(内部メモリ)に置くか、SDカード上パーティションに置くかという機能はそのまま変わらないので、アプリケーションメニューでの「(アプリ本体を)外部SDに移動」という機能(app2sd)はメニュー名称含めてそのまま。内部ストレージと見立てたんじゃないのか、結局外部なのかという、言葉の上でのややこしさ。
 そしてこの機能で移動するのは当然アプリ本体のみ。だからこれをKindleでやって「出来ました」「やっぱ駄目だったよ~」は筋違いもいいところ。

 また問題の一つとして、「format as internal storage」で行われるのはフォーマットまでで、/sdcard/ (ストレージ0番)へのすげ替えマウントは「データのエクスポート/migrate data」の時に同時に行われる感じ?
 メニューを封印しているメーカーも多かったようなので、adbで手作業でフォーマットする手法が説明されているけど、これだけだとすげ替えマウントはされないからちっとも本来の意味を成さない(app2sdは機能する)。(自分はメニューで既に操作できたのでちょっと対処法までは調べていないけど、mount/unmountを駆使すれば何とかなるのかな。不明)

 あと表示上の問題として、元々/data/も/sdcard/も内部である大前提で長らくシステムを組んでいるものだから、OS設定メニューの使用容量の表示もその区分けしかされていない感が満々でしてね。「ストレージ」のメニューに表示されるアプリケーションの使用容量がもう無茶苦茶。上記の通り/data/が内部メモリ、/sdcard/が外部SDになる筈なのに一緒くたに計算しちゃうものだから、アプリケーションの使用容量と本体メモリ使用量がまるで食い違ったり、アプリ本体の移動だけでワークデータもSDに移動したように誤解したり。
 少なくともストレージ全体の使用量・残量は正しく出ているのであくまでそれを目安に。とはいっても更にAndroid6最初期はこの残量表示も出鱈目だったようですがね(苦笑)。その辺のサイトで「移動できました」「駄目でした」と勘違いしているのはこういった事情にも依る所が大きいのではと思う。(またこの辺は、OSバージョンやメーカーのUI変更具合にも依るところかと。galaxyS7のandroid7版なんかはまたちょっと変えてる。)

 まぁ言ってしまえば、ロクに洗練されていない実験的な機能であって。
 過去よくある「作ったので採用してみたけど、すぐに消される」機能の一つになってしまう可能性もなきにしもあらず。

 正直、こういうややこしい事情を乗り越えて使うよりも、素直に本体メモリの多い端末を買う方が早いとは思いましたよ。
 そもそも外部SDカードってのは、
 ・Android4.4で一般アプリの書き込み権限をシャットアウト(5で直す)
 ・google謹製の端末では採用例が無い
というgoogle自身が切り捨てる気満々の機能なので、お察し下さいというところ。

 うちは16GBでバッテリ初期不良という残念な端末を抱えているので、駄目元の実験として行ってみたわけで。今のご時世、32GBくらいから積んでおけばKindleを使う分には問題ないんじゃないかというところ。

 そんな訳で、こんな機能で足掻くのも一時的な話に過ぎないよねと。
 そもそも正直、別にローカルに何でもかんでも溜め込んでおくまでのものもなくて、ネット接続が前提でクラウド上でストリーミング表示すりゃいいんじゃないのという物も多い。

 Kindle Cloud Readerが正にそれなんですけども。残念!、Kindle for PC同様、いつまで経っても「コレクション」機能に対応しないので論外。
 所有書籍を一覧でどばーっと表示するだけの手抜きUI一本、というのは今の時代の趨勢とでも申しますか。漫画タイトルごとにまとめたいという需要はこと日本国内の事情というのもあるとはいえ、せめて作家別にまとめるくらいしろとは言いたい。仕方ないのでコレクション機能で手動で振り分けないとお話にもならない。
 このコレクション機能不在というのもあって、未だにAndroid版は外せない。
 ついでにいうとスマホ(Android)端末からはアクセスさせてくれません。UserAgentで弾いているだけなんじゃないかとは思いますが。

 で、一方アプリ版Kindleも、最近は一括DLではなく、ストリーミング的なロードを行うように改修してるみたいだし。もうね、手元に置いておきたいもの(お気に入り)と、ネット経由で都度ロードすればいい(キャッシュ運用)ものとを分けてもいいんじゃないかと思う。キャッシュ最大量を決めて、古いものから勝手に消していってくれるとか(お気に入りは消さない)。まぁそんな便利機能をamazonが以下略、ってなことにはなりますが(苦笑)。
 ソフトウェアなんて今時「出来るか」よりも「やるか」どうかの問題なんで、手を掛けるべきところに手を掛けない(予算をつぎ込まない)、ソフトの軽視っぷりが疑問でならない。まぁここの話は、、、いいか(長くなる)。
 APIか何かで公開して3rdにUI作らせてくれりゃなぁとつくづく思いますよ。あるのかな、ないよね。。

 まぁ今は長い長い目で見ていくしかないのだろう、ということで。

コメントを残す

メールアドレスが公開されることはありません。