のらぬこの日常を描く

ノージャンルのお役立ち情報やアニメとゲームの話、ソフトウェア開発に関する話などを中心としたブログです。

android:年を追う毎に複雑怪奇化する端末内ファイルアクセスAPI

どうものらぬこです。

今回は、androidアプリから端末内のファイルの扱いについての記事です。

端末内のファイルの扱いは、OS更新ごとに仕様が複雑怪奇化、API機能の制約増加等により、以前(Kitkat以前)と比べると格段にめんどくさくなっています。

今回は、その変革の軌跡をたどりながら、googleマジいい加減にしろよ●すぞ!っていう感じに殺意が沸いてくる感情を書いてきます。

Kitkat以前(~4.3)

アプリにPermissonさえ付与しておけば、内蔵ストレージ内のファイルもSDカード内のファイルは自由に読み書きできた時代。あの頃は良かった。

Kitkat(4.4)

一般アプリからの外部ストレージ(SDカード)への書き込みが大きく制限される /sdcard/Android/<自アプリのパッケージ名> 以外のディレクトリへの書き込みが不可能になる。 AndroidManifest.xmlに Permissionの設定を書いていようと、アプリから外部SDカードに書き込もうとするとSecurityExceptionが発生する。なお、内蔵ストレージは従来のバージョンと同等の方法で読み書き可能。

システムアプリ(端末標準搭載の削除できないアプリ)からはSDカード内のファイルも自由に書き込みが可能だった。 Kitkat搭載端末には、ESファイルエクスプローラ等の優秀なファイル管理アプリより遥かに使いづらいアプリが標準添付されていたり。

ちなみに、root権限で /etc配下に置かれているPermission関連の設定ファイルを手動で書き換えることで、この制限は回避可能。 制限を回避するためにroot化した人も結構いたみたい。 セキュリティーを向上するためとかいう大義名分を嘲笑うかのよう。

昔、恒久的にroot化することなく、この制限を回避するためのツールを公開してた(消えてなければファイルも残っていると思う)。

noranuk0.hatenablog.com

Lolipop(5.0)

Lolipopで新たに実装された SAF(Storage Access Framework) というAPIを利用することで、SDカード内のファイルも、ユーザの許可したディレクトリ以下のファイルは自由に読み書きできるようになる。 ただし、新しく実装されたAPIは、従来のAPIとは全く互換性がなく、対応するにはアプリの再実装が必要だった。

private DocumentFile getTargetDocumentFile(String path, String treeUri) {
    String[] parts = path.replaceFirst("^/", "").split("/");
    DocumentFile target = DocumentFile.fromTreeUri(context, Uri.parse(treeUri));
    for (String part : parts) {
        target = target.findFile(part);
        if (target == null) {
            return null;
        }
    }
    return target;
}

さらに、SAFにはファイルの移動APIが存在しなかったため、ファイルの移動はコピーして元ファイルを削除という MS-DOS 3.3 みたいなことをやらないといけない。 どう考えても仕様バグみたいなこの制限は、Android7.0でようやく解消される。

// android7.0以上でのみ動作する
DocumentsContract.moveDocument(
                        contentResolver,
                        documentFile.getUri(),
                        oldPathDocument.getUri(),
                        newPathDocument.getUri());

書き込みが行える範囲(このディレクトリ以下全部みたいな指定)はエンドユーザが設定することが可能。 例えば、「SDカードの音楽ディレクトリ以下のファイルのみ書き換え可能」みたいなことが出来るようになっているんだけど、そんなこと想定してるアプリとか見たことない。

M(6.0)

Runtime Permission といって、インストール時にアプリが使う可能性のあるすべてン権限をユーザに強制承認させるのではなく、アプリインストール後、必要になったときにユーザに承認を求めるという方式に変更される。 AndroidManifest.xmlに Permission設定を書いておくだけではだめで、権限が必要な操作の実行前に権限を使用するためのリクエストをエンドユーザに承認してもらうためのダイアログを表示する必要があり、この部分はアプリ側で追加の実装が必要。

内蔵ストレージ・SDカード内のファイル読み書きもRuntime Permission の対象のため、ひと手間かけて、そのための処理を追加実装する必要がある。

private void requestExternalSDCardPermission() {
    if (IntentUtil.checkSelfPermission(this)) {
        new AlertDialog.Builder(this).
                setTitle(
                        getResources().getString(R.string.app_name)).
                setMessage(
                        getResources().getString(R.string.external_storage_permission_message,
                                getResources().getString(R.string.app_name))).
                setPositiveButton(android.R.string.ok, new DialogInterface.OnClickListener() {
                    @Override
                    public void onClick(DialogInterface dialog, int which) {
                        if (shouldShowRequestPermissionRationale() ||  !Config.instance().requestSdCardPermission()) {
                            ActivityCompat.requestPermissions(LaunchActivity.this,
                                    new String[]{
                                            Manifest.permission.READ_EXTERNAL_STORAGE},
                                    REQUEST_PERMISSIONS_EDITING);
                        } else {
                            Intent intent = new Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS);
                            Uri uri = Uri.fromParts(
                                    "package",
                                    LaunchActivity.this.getPackageName(),
                                    null); //Fragmentの場合はgetContext().getPackageName()
                            intent.setData(uri);
                            LaunchActivity.this.startActivity(intent);
                        }
                    }
                }).show();
    }
}

エンドユーザにとっては、カメラや音声の録音、通話の発信等の悪用さえるとちょっと危険な香りのする権限を、アプリごとに個別に拒否することが出来るようになるというメリットがあり、世間的には割と歓迎された。

N(7.0)

端末内のファイルを選択し、それを他のアプリで開くような操作に対応する場合(例えば、ファイル管理アプリで動画ファイルを選択して、それを動画再生アプリを開くときなど)、対象ファイルのパス名を指定することがこのバージョンから不可能になった。 Intentの data として、file:// スキーマを設定して、他のアプリに渡そうとすると SecurityException が発生する。

代わりに、呼び出し元アプリでContentProviderを実装して、そいつのスキーマを使えという事になっている。

エンドユーザにとってもいいことは一つもない、場合によってはデメリットしかない気がするのだけど、なんでこんなことしたのか理解不能

デメリットとしては、例えば以下のようなことが考えられる。

ContentProviderで指定するパス名は呼び出し元アプリが自由に決められるようになっていて、ファイルシステム上同一のファイルに、毎回別のパスを割り当てることも、逆にファイルシステム上は別のファイルに、同一のパスを割り当てることも可能になっている。

したがって、呼び出し元アプリの実装方法にもよるが、例えば、アプリから動画ファイルを開く場合、動画アプリ側のレジューム再生機能などに支障をきたす場合もある。

アプリ独自にContentProvider実装しなくても、今のところはcontent:// スキーマが利用可能なのが唯一の救い。

MediaScannerConnection.scanFile(LaunchActivity.this,
        new String[]{uri.substring("file://".length())}, null,
        new MediaScannerConnection.OnScanCompletedListener() {
            @Override
            public void onScanCompleted(String path, Uri uri) {
                if (uri == null) {
                    uri = Uri.fromFile(new File(path));
                }
                Intent intent = new Intent(Intent.ACTION_VIEW);
                intent.setData(uri);
                context.startActivity(intent);
            }
        });

今回の話はここでおしまいだが、android 8.0がリリースされていて、その次は android 9.0 とかが待ち構えている。

最近はandroidの最新情報を追いかけていないので、8.0でまた仕様が変わったとか9.0でさらに制約が増えるとかいうことがあるのかないのかとかは分からない。

が、これ以上中途半端な仕様・制約の追加変更はやらんでいただきたいとは切に願う。

最後にひとつ。記事内に埋め込まれたコードは、過去実装したアプリコードの一部をそのまま貼り付けているため、掲載したコード単独では不完全な部分が多くあり、そのままではおそらく動作しません。

参考にされる場合は、不足していると思われる部分を各自補ってください。

というわけで、今回の記事は以上となります。

お読みいただいてありがとうございました。

はじめてのAndroidプログラミング 第3版

はじめてのAndroidプログラミング 第3版