Android QのScoped Storage、旧APIをターゲットにしたアプリでは必須化されない 41
ストーリー by headless
延期 部門より
延期 部門より
Android Qではアプリ別とメディア別のストレージ「Scoped Storage」が導入され、外部ストレージへのアクセスは制限されるが、必須化は来年のメジャープラットフォームリリース(Android R)へ先送りとなるそうだ(Android Developers Blogの記事、
Android Policeの記事)。
アプリが現行のストレージに関するベストプラクティスに従っていればScoped Storageの影響は小さいものの、アプリによっては複雑な変更が必要になるとのフィードバックも届いているという。そのため、アプリ開発者がScoped Storageの影響を評価する十分な時間が取れるよう方針を変更したそうだ。
Android Q Beta 2では新規インストールアプリでScoped Storageが有効となっているが、今後提供されるBeta 3ではAndroid 9 Pie(API 28)以前をターゲットにしたアプリであれば従来のAndroidバージョンと同様にストレージが利用できるようになる。既存アプリをScoped Storageに対応させた場合はAPI 28以下をターゲットにしたアプリであっても、Android QデバイスでScoped Storageを使用するようマニフェストで指定できるようになるとのこと。
ただし、来年のAndroid RではアプリのターゲットSDKレベルにかかわらず、外部ストレージの利用にはScoped Storageへの対応が必須となるため、なるべく早い準備が推奨されている。
アプリが現行のストレージに関するベストプラクティスに従っていればScoped Storageの影響は小さいものの、アプリによっては複雑な変更が必要になるとのフィードバックも届いているという。そのため、アプリ開発者がScoped Storageの影響を評価する十分な時間が取れるよう方針を変更したそうだ。
Android Q Beta 2では新規インストールアプリでScoped Storageが有効となっているが、今後提供されるBeta 3ではAndroid 9 Pie(API 28)以前をターゲットにしたアプリであれば従来のAndroidバージョンと同様にストレージが利用できるようになる。既存アプリをScoped Storageに対応させた場合はAPI 28以下をターゲットにしたアプリであっても、Android QデバイスでScoped Storageを使用するようマニフェストで指定できるようになるとのこと。
ただし、来年のAndroid RではアプリのターゲットSDKレベルにかかわらず、外部ストレージの利用にはScoped Storageへの対応が必須となるため、なるべく早い準備が推奨されている。
セキュリティ向上のために (スコア:1)
最近のAndroidでは外部ストレージのPathはUUIDになっているので、
SD差し替えたりフォーマットしたりすると各アプリから全部Path指定し直しになるよね。
さすがGoogle、素晴らしいセキュリティ対策だと思いますわ。
Re: (スコア:0)
UUIDでマウントする機能はLinuxに随分昔からあるよね。
その利点をいち早く見出して下衆に周知してくれるとは、
それも、漏れなく恩恵を受けるためにできるだけ早く必須にするとは、
さすが天才集団は違うな。と思いますよね。
Re: (スコア:0)
また皮肉を解さないアホが湧くぞ
Re: (スコア:0)
データの場所を外部ストレージにすす設定を有効にすればそのへんの手間は不要なのだが。
結局オーエスのルールを守らないから面倒なことになってるだけだよ。
もうちょっと (スコア:0)
Androidのフォルダ構造設計はもうちょっと何とかならんかったのか？
SDカードにフォルダ直置きで、ドキュメントやら画像やらの標準的な場所が曖昧だとかめちゃくちゃすぎでしょ。
大抵のOSならフォントを置く場所くらいは決めておくもんだぞ。
それを考えるとDCIMという分かりやすくはないが確実なフォルダ構造を定めた古のDCFとやらは偉大だ。
Re: (スコア:0)
外部ストレージにフォントを置くリスク考えれば外部ストレージ上のフォントの置き場所が決まっていないのは妥当。
Re: (スコア:0)
後学のために教えて欲しいのだけれども、
外部ストレージにフォントを置くことに
何のリスクがあるの？
そして、置き場所をあいまいにすることで、
どうしてリスクが回避できるの？
Re:もうちょっと (スコア:2, 参考になる)
ツリー元 [srad.jp]のACだけど、
と言ったリスクだと思うよ。
1. についてはWebフォントの方が容易で必要な権限も少ない。
2. については確かにシステムフォントを外部ストレージに置くというのは愚策。
普通のOSは書き込み権限が管理されるシステムディスク(内部ストレージ)に入れて対処している。
少なくとも重要なシステムアプリが使用するフォントは権限なしに書き換えられるのは危険だし、そうでないアプリも外部ストレージにフォントを置くことは一定のリスクがある。
署名を確認したり追加したフォントのハッシュを持っていたりが対処方法かな。
3. については特定フォントに依存しているアプリが意図した動作をしなくなるというのは、悪意の有無に関わらずあり得る。
ただ外部ストレージにアプリが使うフォントを置くというのは現状でも行われている。
置き場所を曖昧にしている事は特にメリットになっていないどころか、特定アプリを狙った攻撃はむしろ容易になっている(ただしそういうフォントを使うアプリは大抵セキュリティに関わらない事をしている)。
でもフォントファイルを用意に変更できる外部ストレージに置くなっていう指摘ならもっともだと思う。
現状のフォント管理は各アプリが好き勝手な場所に重複して持っているなんていう現状がある(普通は標準フォントをそのまま使う)。
加えてUI全般で使うフォントを変えられないというのはかなり不便。
通常は読み取り権限のみ与えられる内部ストレージの特定の場所に置いて、フォントの依存関係はストアなりが管理するってのがスマートだっただろうね。
Re: (スコア:0)
あとは物理的なアンマウントやいろんな意味での破壊耐性かな。
内部ストレージなら揺れで接触不良とかいう事はないし、ハード自身の寿命に関してもある程度のコントロール下に置くことはできる。
Re: (スコア:0)
そもそもスマホで自由にフォントが変えれないの本当に不思議なんだよね。
具体的に言うと絵文字をスライム君にしたい。
windows phoneは出来たんだろうか？
＞フォントエンジンの脆弱性を突いて攻撃できる。
画像や動画ビューアは脆弱性が突かれない保証ってどこにあんの？
＞ユーザーに表示される文字を書き換える。
システムが出す重要なダイアログ(課金とか権限)ではデフォルトのフォントに戻せばいい
＞単純にフォントファイルを削除する。
フォールバックすればいいだけ
設定アプリからフォントを選んだ時にシステムの管理領域にコピーしてそこから表示するようにするとか
いくらでもやり方はあるだろう。
Re: (スコア:0)
>画像や動画ビューアは脆弱性が突かれない保証ってどこにあんの
だれもそんな事を言っていない。
>設定アプリからフォントを選んだ時にシステムの管理領域にコピーしてそこから表示するようにするとか
脆弱性対処にかすりもしない
フォントは描画に時間がかかるから最終段に近い方が速度的に有利だし、ラスターフォントでもない限り構造的に複雑だから高速化と相俟って脆弱性が生じやすい。
Re: (スコア:0)
Windows Mobile 時代なら、パソコン用のフォントを専用ソフト経由で転送できたけどね。
Re: (スコア:0)
ああ、つまり、だれでも触れる場所(≒外部ストレージ)に
動作にかかわるファイルを置くことがそもそもの誤りで、
フォントを配置するフォルダ構成があいまいなほうが～云々は、
上記の問題に対してはアンチパターンでしかないということなのね。
そして、#3608516で書かれていることをふまえると、
Androidはフォントを安全に管理する方法がないから、
アプリが好き勝手なフォルダに配置しているという現状なのですね。
Re: (スコア:0)
それでだいたい合ってると思う。
Re: (スコア:0)
そもそもGoogleは外部ストレージの利用を推奨してないから。
非推奨のモノをいつまでも使ってるのはリスクだし、利用してる側が悪いわ。
Re: (スコア:0)
あー、OSとして外部ストレージの利用を推奨していないのだから、
外部ストレージ上のフォントの置き場所が決まっているのは不整合だということね。
配置場所をあいまいにすることによって回避できる(セキュリティ的な)リスクがあるのだと誤読してたわ。
Re: (スコア:0)
ファイルのパスが決まっているなら、
外部ストレージに事前に不正なファイルを設置しておいて、OSやアプリに読み込ませて不正なコード実行に使えるんじゃないの？
（フォントを読み込む処理に脆弱性があればだが）
気休めかもしれないが不定な名前だと読み込ませるのに手はかかるかと。
Re: (スコア:0)
リスクそのものについては他の人が書いているから省略。
リスク回避についてはフォントであることを認識させない対処が独自処置なら可能だから。
実際はそこまで考えていない実装だらけで、俺は外部ストレージにフォントを置いて利用しているアプリを避けている。
Re: (スコア:0)
フォントファイルだと外から解らないようにしているならともかく、
ただ置いているだけなら、独自フォルダでも固有のフォルダでも、
それっぽいフォルダ(例えば、fontとか)や、ttfファイルが置かれているフォルダを探されてしまえばリスク回避にならないのでは(書き込み権限はあるけど、読み込み権限はないという状況は一般的ではないと思うし)？
OSでなくアプリ側に独自処置をさせるという発想はどうなの？
Re: (スコア:0)
それっぽい名前にしていれば対策にならないのはその通り。
知識が足りなくて脆弱性を晒しているのはフォントに限らないでしょ。
自由度優先のAndroidだから標準的ではない事をやるならきちんと対策する必要があるし、OSに対策機能を盛り込んでもセキュリティについて考えられない人達は使わないでしょうよ。
Re: (スコア:0)
Windowsだって、My Documents などの既定のフォルダができはじめたのは、Windows95の途中からだったんだから、
発展途上のAndroidがグダグダなのは仕方がない。
しかし、音楽データとか外部SDに置いた方が結局日常的に使いやすいので、SDカードへのアクセスがしづらくなるのは勘弁。
Re: (スコア:0)
さすがにAndoroidは発展途上だからって免罪符はどうかと思うよ
調べたらwindowは95まで5年、Androidは出てからすでに10年だ
Re: (スコア:0)
Windows 1.0は1985年11月20日
Windows 95は1995年8月24日
10年じゃないかな？
Re: (スコア:0)
世代によって方針がころっころ変わるのもな。行き当たりばったり過ぎるんだよ。
仕様もアジャイル開発ですってか？ｗ
Re: (スコア:0)
それ以前にSDカードの扱いの変遷を思うにgoogleにもバカはいるんだなと思うよ。
ディレクトリ構造 (スコア:0)
ユーザーにディレクトリ構造を意識させないapple、
ディレクトリ構造を意識できるgoogle、
パワーユーザーにとっては後者の方が使いやすいな
Re: (スコア:0)
本当のパワーユーザーは個人情報搾取OSなんか使わんだろ
Re: (スコア:0)
ならiOSもAndroidもダメじゃん
Re: (スコア:0)
アンドロイドも意識はさせないんじゃないかな…
Re: (スコア:0)
外部ストレージがある以上意識せざるを得ないですよ。
外部ストレージは出し入れする可能性があるのでAndroidの統制下にない状況で書き込まれた状況を考慮しなければならない。
Re: (スコア:0)
iOSはそのせいでアプリ間のデータの共有が非常にやりにくい。
iPadProでPCライクな使い方を提案するに至って、とうとうファイラーをつけて、
ユーザーにディレクトリ・ファイル構造をある程度意識させる方針に路線変更した。
で、Androidの方はといえば、旧iOSスタイルにすこし近づけるような話になってきていて、
なんか面白いことだｗ
Re: (スコア:0)
隣の芝生は青いんですよ。
来年はRなのか？ (スコア:0)
バージョンアップ早すぎだろ。
8までは7.1, 8.1と間にマイナーバージョンアップ挟んでたのにPの次はQで直ぐRかよ。
早すぎだろ。そりゃデベロッパがぶー垂れるのも無理ない。
Re: (スコア:0)
.xだからといって、マイナーバージョンと思っているデベロッパーはもういないと思うよ。
APIのバージョンが重要なので。
Re: (スコア:0)
日本メーカーみたいに安定してるものをいじらないとかやってたら時代遅れになって競争に勝てないので
テキストファイルとかPDFとかどうなるんだろう (スコア:0)
[写真と動画]、[音楽]、[ダウンロード] 以外の、テキストファイルとかPDFはSDカードに保存できなくなるんだろうか。
ダウンロードフォルダに全部いれておけばいいのかもしれないが。
Re: (スコア:0)
[写真と動画]、[音楽]、[ダウンロード] 以外の、テキストファイルとかPDFはSDカードに保存できなくなるんだろうか。
Kitkat時代の再現なんじゃない？
プリインストールで有料ファイラー入れてストアで金払えって感じでキャリアが実装
んでもって即次期バージョンで撤回
海外モデルでカスタムROMが活発化したようにAOSP対応がもっと活発化してくれるかもね
Re: (スコア:0)
ファイル マネージャー アプリの場合など、外部ストレージ内のディレクトリに対する広範なアクセス権限を取得するには、ACTION_OPEN_DOCUMENT_TREE インテントを使用します。
とあるので、ファイラーは使えそう。
enugh long means forever (スコア:0)
アプリ開発者がScoped Storageの影響を評価する十分な時間が取れるよう方針を変更したそうだ
大丈夫？なんかかつて導入しようとしたあれこれのようにキャンセルされない？