Monday, August 21, 2023

AOSPマルチユーザー環境におけるシステムアプリのデータ連携
  /   No comments   

Android Open Source Project (AOSP) は、今日のモバイルエコシステムの根幹をなす、非常に柔軟で強力なプラットフォームです。その数ある機能の中でも、一台のデバイスを複数の人間が安全かつ独立して使用できるようにする「マルチユーザー機能」は、特に重要な位置を占めています。タブレットを家族で共有したり、企業用デバイスで業務用プロファイルと個人用プロファイルを分離したりと、その応用範囲は多岐にわたります。この機能の中核をなすのは、各ユーザーのデータを厳格に分離するサンドボックス化の仕組みです。しかし、システム全体の状態を管理したり、全ユーザーに影響する機能を提供したりする必要がある「システムアプリ」にとっては、このデータ分離が特有の課題を生み出します。

通常のサードパーティ製アプリケーションは、自身が実行されているユーザー空間内のデータにのみアクセスできれば十分です。しかし、例えばデバイスのストレージ管理アプリ、ユーザーアカウントを管理する設定アプリ、あるいはデバイス全体のポリシーを適用するMDM（Mobile Device Management）エージェントのようなシステムアプリは、現在フォアグラウンドで操作しているアクティブなユーザーのデータにアクセスしたり、特定のユーザーのコンテキストで処理を実行したりする必要に迫られることがあります。この要求は、Androidの厳格なセキュリティモデルと真っ向から対立するように見えますが、AOSPは特権を持つシステムアプリのために、この壁を乗り越えるための正規のAPIとメカニズムを提供しています。

本稿では、AOSPをベースとしたシステムアプリ開発において、マルチユーザー環境下で現在アクティブなユーザーを正確に特定し、そのユーザー固有のデータ領域に安全にアクセスするための技術的な手法を深く掘り下げていきます。単にコードスニペットを提示するだけでなく、その背後にあるAndroidのアーキテクチャ、関連するクラスやパーミッションの役割、そしてセキュリティ上の注意点までを網羅的に解説します。これにより、開発者はマルチユーザー対応の堅牢で信頼性の高いシステムアプリを構築するための知識を習得できるでしょう。

Androidマルチユーザーアーキテクチャの探求

具体的な実装方法に入る前に、Androidがマルチユーザー環境をどのように構築し、管理しているのかを理解することが不可欠です。このアーキテクチャの根底には、Linuxカーネルのユーザー管理機能があり、Androidフレームワークがそれを抽象化して、より高レベルな概念を提供しています。

ユーザーID (UserId) と UserHandle

Androidシステムは、内部的に各ユーザーをユニークな整数ID、すなわち「ユーザーID（UserId）」で識別します。このIDは、ユーザーごとのデータディレクトリの命名規則（例: /data/user/0, /data/user/10）や、プロセス管理、パーミッション制御など、システムのあらゆる側面で利用されます。

  • システムユーザー (User 0): デバイス上で最初に作成される、最も基本的なユーザーです。常に存在し、「オーナー」や「プライマリーユーザー」とも呼ばれます。ユーザーIDは常に 0 です。多くのシステムサービスはこのユーザーのコンテキストで初期化され、デバイス管理の根幹を担います。
  • セカンダリーユーザー: オーナーによって追加される通常のユーザーです。それぞれが一意のユーザーID（通常は10, 11, ...と続く）を持ち、独立したアプリケーションデータ、設定、壁紙などを保持します。
  • ゲストユーザー: 一時的な利用を目的としたユーザーです。セッションが終了すると、そのユーザーが生成したデータは通常、消去されます。
  • 管理対象プロファイル（仕事用プロファイル）: Android for Work（現Android Enterprise）で導入された特殊なプロファイルです。プライマリーユーザー内に存在し、仕事用のアプリとデータを個人用のものから安全に分離します。独自のユーザーIDを持ちますが、ランチャー上ではプライマリーユーザーのアプリと統合して表示されます。

APIレベルでは、このユーザーIDは android.os.UserHandle オブジェクトとしてラップされることが多く、これによりタイプセーフな操作が可能になります。

データストレージの分離

マルチユーザー機能の核心は、ストレージの分離です。Androidは各ユーザーに対して、独立したデータ領域を割り当てます。

  • 内部ストレージ: 各アプリケーションのプライベートなデータは、ユーザーごとに分離されたディレクトリに保存されます。例えば、パッケージ名が com.example.app のアプリの場合、ユーザー0のデータは /data/user/0/com.example.app/ に、ユーザー10のデータは /data/user/10/com.example.app/ に格納されます。これにより、あるユーザーのアプリが他のユーザーのアプリのデータにアクセスすることは原理的に不可能です。
  • 外部ストレージ（エミュレート）: 写真やダウンロードファイルなどが保存される共有ストレージ領域も、ユーザーごとに論理的に分割されています。物理的には同じストレージデバイス上にありますが、ファイルシステムレベルでのパーミッションやマウントポイントの切り替えによって、各ユーザーには自分専用の外部ストレージ（/storage/emulated/USER_ID/）が見えるようになっています。

システムアプリが他のユーザーのデータにアクセスするということは、この厳格な分離の壁を、正当な権限とAPIを用いて越えることを意味します。

現在フォアグラウンドでアクティブなユーザーの特定

他のユーザーのデータにアクセスする最初のステップは、「どのユーザーが現在デバイスを操作しているか」を特定することです。Androidフレームワークは、この目的のために複数のAPIを提供しており、状況に応じて使い分ける必要があります。

ActivityManagerによるフォアグラウンドユーザーの取得

ユーザーが画面上で直接操作している、すなわち「フォアグラウンド」にいるユーザーを特定するには、ActivityManager クラスを使用するのが最も確実です。システムサービスであるActivityManagerは、現在のアクティビティスタックやプロセスの状態を管理しており、どのユーザーが最前面にいるかを常に把握しています。


import android.app.ActivityManager;
import android.content.Context;
import android.os.UserHandle;
import android.util.Log;

// ...

public int getForegroundUserId(Context context) {
    ActivityManager am = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE);
    if (am == null) {
        Log.e(TAG, "ActivityManager not available");
        return UserHandle.USER_NULL; // エラーを示す値
    }

    // ActivityManager.getCurrentUser() は現在のフォアグラウンドユーザーのIDを返す
    // このAPIを呼び出すには INTERACT_ACROSS_USERS パーミッションが必要
    try {
        int currentUserId = ActivityManager.getCurrentUser();
        Log.d(TAG, "Current foreground user ID: " + currentUserId);
        return currentUserId;
    } catch (SecurityException e) {
        Log.e(TAG, "Missing INTERACT_ACROSS_USERS permission", e);
        return UserHandle.USER_NULL;
    }
}

この ActivityManager.getCurrentUser() メソッドは、まさに現在画面に表示されているユーザーのIDを返します。このメソッドを呼び出すためには、アプリケーションのマニフェストファイル (AndroidManifest.xml) に android.permission.INTERACT_ACROSS_USERS パーミッションを宣言する必要があります。このパーミッションは protection level が "signature|signatureOrSystem" であるため、通常のサードパーティアプリは使用できず、プラットフォームのキーで署名されたシステムアプリ、または特権アプリとして /system/priv-app にインストールされたアプリのみが利用可能です。

UserManagerによるユーザー情報の管理

一方、UserManager クラスは、デバイス上のユーザープロファイル全般を管理するためのAPIを提供します。フォアグラウンドユーザーを直接特定する機能はありませんが、デバイスに存在する全ユーザーのリストを取得したり、各ユーザーのプロパティ（名前、シリアル番号、制限など）を照会したりするのに役立ちます。


import android.os.UserManager;
import android.os.UserHandle;
import java.util.List;

// ...

public void listAllUsers(Context context) {
    UserManager um = (UserManager) context.getSystemService(Context.USER_SERVICE);
    if (um == null) {
        Log.e(TAG, "UserManager not available");
        return;
    }

    // MANAGE_USERS または QUERY_USERS パーミッションが必要
    try {
        List<UserHandle> users = um.getUserProfiles();
        for (UserHandle user : users) {
            int userId = user.getIdentifier();
            long serialNumber = um.getSerialNumberForUser(user);
            String userName = um.getUserName(); // これは呼び出し元のユーザーの名前を返す点に注意
            Log.d(TAG, "Found user: ID=" + userId + ", Serial=" + serialNumber);
        }
    } catch (SecurityException e) {
        Log.e(TAG, "Permission denied to list users", e);
    }
}

重要なのは、ActivityManager と UserManager の役割の違いを理解することです。「今、誰がデバイスを使っているか？」を知りたい場合は ActivityManager を、「デバイス上にどのようなユーザーが存在するか？」を知りたい場合は UserManager を使用します。

ユーザーコンテキストを介した安全なデータアクセス

ターゲットとなるユーザーIDを特定したら、次はそのユーザーのデータ領域にアクセスします。ここで最もやってはいけない間違いは、ファイルパスを自前で構築することです。例えば、"/data/user/" + userId + "/com.example.app/files/..." のような文字列操作は、将来のAndroidバージョンでのディレクトリ構造の変更に対応できず、非常に脆弱です。

AOSPが提供する、より堅牢で正しいアプローチは、「ユーザー固有のContextオブジェクト」を生成し、それを通じてファイルシステムやその他のリソースにアクセスする方法です。

createPackageContextAsUser メソッドの活用

Context クラスには createPackageContextAsUser という強力なメソッドが用意されています。これは、指定したパッケージ名とユーザーIDに対応する、新しい Context オブジェクトを生成します。この新しい Context オブジェクトは、あたかもそのアプリが指定されたユーザーのプロセスとして実行されているかのように振る舞います。


import android.content.Context;
import android.content.pm.PackageManager;
import android.os.UserHandle;
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;

// ...

public boolean saveDataForUser(Context context, int targetUserId, String fileName, String data) {
    try {
        // ターゲットユーザーと自パッケージ名のコンテキストを生成
        // このメソッドは INTERACT_ACROSS_USERS パーミッションを必要とする
        Context userContext = context.createPackageContextAsUser(
            context.getPackageName(), 
            0, // flags
            UserHandle.of(targetUserId)
        );

        // userContext を使えば、通常のファイルI/O APIが
        // 自動的にターゲットユーザーのデータディレクトリを指すようになる
        File userFile = new File(userContext.getFilesDir(), fileName);
        
        try (FileOutputStream fos = new FileOutputStream(userFile)) {
            fos.write(data.getBytes());
            Log.d(TAG, "Successfully saved data to: " + userFile.getAbsolutePath());
            return true;
        } catch (IOException e) {
            Log.e(TAG, "Failed to write to user file", e);
            return false;
        }

    } catch (PackageManager.NameNotFoundException | SecurityException e) {
        // NameNotFoundException: 自分のパッケージ名なので通常は発生しない
        // SecurityException: パーミッション不足
        Log.e(TAG, "Failed to create user context", e);
        return false;
    }
}

上記の例では、context.createPackageContextAsUser() を使って userContext を生成しています。その後の userContext.getFilesDir() の呼び出しは、自動的に /data/user/<targetUserId>/com.example.app/files/ という正しいパスを返します。この方法の利点は計り知れません。

  • 抽象化: 実際のファイルシステムのパス構造を意識する必要がなくなります。
  • 将来性: Androidの将来のバージョンでストレージの仕組みが変更されても、APIの振る舞いが維持される限りコードは動作し続けます。
  • 一貫性: ファイルアクセスだけでなく、SharedPreferences、データベース、キャッシュディレクトリなど、Context を通じてアクセスするすべてのリソースが、自動的にターゲットユーザーのものになります。(例: userContext.getSharedPreferences("prefs", Context.MODE_PRIVATE))

このメソッドも同様に INTERACT_ACROSS_USERS パーミッションを要求します。

ユーザー固有のContentProviderへのアクセス

ファイルシステム上の非構造化データへのアクセスだけでなく、システム設定や連絡先のような構造化データにアクセスする必要もしばしばあります。これらのデータは通常、ContentProvider を介して提供されます。システムアプリは、特定のユーザーの ContentProvider に対してクエリや更新を行うことも可能です。

これを実現するには、ContentResolver のオーバーロードされたメソッドを使用します。これらのメソッドは、操作対象のユーザーIDを明示的に引数として受け取ります。

例: ターゲットユーザーの画面タイムアウト設定の読み取り

以下の例は、指定されたユーザーの「画面のタイムアウト時間」を Settings.System プロバイダーから読み取る方法を示しています。


import android.content.ContentResolver;
import android.content.Context;
import android.provider.Settings;
import android.util.Log;

// ...

public int getScreenTimeoutForUser(Context context, int targetUserId) {
    ContentResolver resolver = context.getContentResolver();
    int timeout = -1; // デフォルト値

    try {
        // ContentResolver.getUriFor() でユーザー固有のURIを取得し、
        // Settings.System.getIntForUser() で直接値を取得する
        // このAPIは READ_DEVICE_CONFIG や MANAGE_USERS などの高レベルな権限を要求することがある
        timeout = Settings.System.getIntForUser(resolver, Settings.System.SCREEN_OFF_TIMEOUT, targetUserId);
        Log.d(TAG, "Screen timeout for user " + targetUserId + " is " + timeout + "ms");
    } catch (Settings.SettingNotFoundException e) {
        Log.w(TAG, "Screen timeout setting not found for user " + targetUserId, e);
    } catch (SecurityException e) {
        Log.e(TAG, "Permission denied to read settings for user " + targetUserId, e);
    }
    return timeout;
}

// 同様に設定を書き込むことも可能
public boolean setScreenTimeoutForUser(Context context, int targetUserId, int timeoutMillis) {
    ContentResolver resolver = context.getContentResolver();
    try {
        // 書き込みには WRITE_SETTINGS または WRITE_SECURE_SETTINGS パーミッションが必要
        boolean success = Settings.System.putIntForUser(resolver, Settings.System.SCREEN_OFF_TIMEOUT, timeoutMillis, targetUserId);
        if (success) {
            Log.d(TAG, "Successfully set screen timeout for user " + targetUserId);
        } else {
            Log.w(TAG, "Failed to set screen timeout for user " + targetUserId);
        }
        return success;
    } catch (SecurityException e) {
        Log.e(TAG, "Permission denied to write settings for user " + targetUserId, e);
        return false;
    }
}

このアプローチは、Settings プロバイダーだけでなく、ContactsContract や Telephony など、マルチユーザー対応で設計されている他の多くのシステムプロバイダーにも適用できます。どのAPIがどのパーミッションを要求するかは、公式ドキュメントで慎重に確認する必要があります。特に設定の書き込みには android.permission.WRITE_SECURE_SETTINGS のような強力な権限が必要になる場合があります。

高度なトピックと実践的なユースケース

基本的なデータアクセスに加えて、システムアプリはユーザー間のより複雑なインタラクションを必要とすることがあります。

ユーザー切り替えイベントの監視

フォアグラウンドユーザーが変更されたことをリアルタイムで検知したい場合、ACTION_USER_SWITCHED ブロードキャストインテントをリッスンします。これにより、アプリは新しいユーザー環境に合わせて状態を更新したり、必要な初期化処理を実行したりできます。


// AndroidManifest.xml にレシーバーを登録
<receiver android:name=".UserSwitchReceiver">
    <intent-filter>
        <action android:name="android.intent.action.USER_SWITCHED" />
    </intent-filter>
</receiver>

// BroadcastReceiver の実装
public class UserSwitchReceiver extends BroadcastReceiver {
    @Override
    public void onReceive(Context context, Intent intent) {
        if (Intent.ACTION_USER_SWITCHED.equals(intent.getAction())) {
            int newUserId = intent.getIntExtra(Intent.EXTRA_USER_HANDLE, UserHandle.USER_NULL);
            if (newUserId != UserHandle.USER_NULL) {
                Log.d("UserSwitchReceiver", "User switched to: " + newUserId);
                // ここで新しいユーザー向けの処理を開始する
            }
        }
    }
}

特定ユーザーのコンテキストでのコンポーネント起動

システムアプリは、特定のユーザーとしてActivityやServiceを起動することもできます。例えば、あるユーザーに通知を表示するために、そのユーザーのセッションでServiceを起動する、といったケースです。

  • Context.startActivityAsUser(Intent, UserHandle): 指定したユーザーとしてActivityを起動します。
  • Context.startServiceAsUser(Intent, UserHandle): 指定したユーザーとしてServiceを起動します。
  • Context.sendBroadcastAsUser(Intent, UserHandle): 指定したユーザーにのみブロードキャストを送信します。

これらのメソッドも、すべて INTERACT_ACROSS_USERS パーミッションを必要とし、システムアプリがユーザー空間の境界を越えて能動的にアクションを起こすための重要なツールとなります。

結論とセキュリティ上の考慮事項

本稿では、AOSPのマルチユーザー環境において、システムアプリが現在アクティブなユーザーのデータにアクセスするための体系的なアプローチを解説しました。重要なポイントを再度まとめます。

  1. アーキテクチャの理解: ユーザーIDとデータ分離の仕組みを理解することが、すべての基本です。
  2. 適切なAPIの選択: フォアグラウンドユーザーの特定には ActivityManager.getCurrentUser() を、ユーザー全般の管理には UserManager を使用します。
  3. パスのハードコーディングの回避: ユーザー固有の Context を createPackageContextAsUser() で生成し、それを通じてリソースにアクセスすることで、堅牢で将来にわたって互換性のあるコードを記述できます。
  4. ContentProviderの活用: 構造化データには、ユーザーIDを引数に取る ContentResolver のメソッドを使用します。
  5. パーミッションの厳格な管理: INTERACT_ACROSS_USERS をはじめとする必要なパーミッションをマニフェストに正しく宣言し、それらの権限がもたらすセキュリティリスクを十分に認識する必要があります。

ユーザーデータを横断的に扱う機能は非常に強力ですが、それだけに大きな責任が伴います。あるユーザーのデータが意図せず他のユーザーに漏洩するようなことがあれば、深刻なプライバシー侵害につながります。開発者は、常に最小権限の原則を念頭に置き、本当に必要な場合にのみこれらのAPIを使用し、データの取り扱いには細心の注意を払わなければなりません。本稿で紹介した技術と原則を正しく適用することで、Androidのマルチユーザー機能を最大限に活用し、安全で高機能なシステムアプリケーションを開発することが可能になるでしょう。


0 개의 댓글:

Post a Comment