Androidのシステムアプリ開発において、最もデバッグが困難で、かつ発見が遅れるバグの一つが「マルチユーザー環境下でのデータ分離」に関連する問題です。特に、デバイスの全ユーザーに対してバックグラウンドで動作する常駐型サービス（Persistent System Service）を実装している場合、開発者は「現在のフォアグラウンドユーザー」のデータにアクセスしようとして、誤ってシステムユーザー（User 0）の領域を参照してしまうミスを犯しがちです。ログには FileNotFoundException や不可解な SecurityException が記録され、現象は特定のユーザー切り替え時にのみ発生する—。この記事では、私がエンタープライズ向けカスタムROM開発で直面したこの問題を、カーネルレベルのUIDの仕組みから解き明かし、プロダクションコードで使える解決策を提示します。
UserHandleとContextの乖離：なぜ直感的なコードは動かないのか
最近のプロジェクトで、MDM（Mobile Device Management）エージェントをAOSPレベルで統合するタスクを担当しました。要件は「現在アクティブなユーザーの壁紙設定を強制的に変更する」というものでした。開発環境はAndroid 13、ターゲットハードウェアはSnapdragon 8 Gen 1搭載のタブレットです。
Androidのマルチユーザー機能は、LinuxのユーザーID（UID）システムを巧みに拡張して実装されています。通常、Android上のアプリは `u0_a123` のようなUIDを持ちますが、これは「User 0」の「App 123」を意味します。ここで重要なのは、`AndroidManifest.xml` で `android:persistent="true"` を宣言したシステムアプリや、System Server内で動作するサービスは、基本的に User 0（System User）として起動し続ける という点です。
context.getFilesDir() を呼ぶと、現在ユーザーが User 10 を操作していても、パスは /data/user/0/... を指します。User 10 の設定ファイルを書き換えるつもりが、誰も使っていない User 0 の領域を書き換えてしまうのです。
さらに厄介なのが、Context オブジェクトのライフサイクルです。Activity内であれば、そのActivityは現在のユーザープロセス内で起動するため、Context は正しいユーザーに紐付いています。しかし、バックグラウンドサービスやBroadcastReceiver（特にBOOT_COMPLETEDなど）からのトリガーでは、このコンテキストが「プロセスを起動したユーザー（多くの場合 System）」に固定されてしまいます。
失敗したアプローチ：UserManagerへの誤解
最初に私が試みたのは、UserManager を使ってユーザーリストを取得し、ループ処理で全ユーザーに適用する方法でした。
「単純に全ユーザーのContextを取得すればいいだろう」と考え、以下のようなコードを書きました。
// 悪い例：これは期待通りに動かないことが多い
UserManager um = (UserManager) context.getSystemService(Context.USER_SERVICE);
List<UserInfo> users = um.getUsers();
for (UserInfo user : users) {
// パーミッションエラー、あるいはContext生成失敗が発生
Context userContext = context.createPackageContextAsUser(packageName, 0, user.getUserHandle());
applyPolicy(userContext);
}このコードは、開発機（エンジニアリングビルド）では動作しましたが、Userビルド（製品版）に焼いた途端に SecurityException でクラッシュしました。原因は INTERACT_ACROSS_USERS 権限の欠如と、システム署名レベルの保護を正しく理解していなかったことにありました。さらに、um.getUsers() はプロファイル（仕事用プロファイルなど）も含んでしまうため、意図しない「ユーザー」に対しても処理が走り、パフォーマンス低下を招きました。
解決策：ActivityManagerとcreateContextAsUserの正しい組み合わせ
マルチユーザー環境で「現在アクティブなユーザー」のコンテキストを正しく取得するには、以下の3つのステップを踏む必要があります。
- 権限の宣言： マニフェストにシステムレベルの権限を追加する。
- Current User IDの取得：
ActivityManagerの隠しAPI、またはAIDL経由で正確なIDを取得する。 - Contextの生成：
createContextAsUserを使用して、ターゲットユーザーに紐付いたContextを生成する。
以下は、私が最終的に本番環境で使用したユーティリティクラスの実装です。
// AndroidManifest.xml に以下の権限が必須です
// <uses-permission android:name="android.permission.INTERACT_ACROSS_USERS" />
// <uses-permission android:name="android.permission.INTERACT_ACROSS_USERS_FULL" />
import android.app.ActivityManager;
import android.content.Context;
import android.os.UserHandle;
import android.util.Log;
import java.lang.reflect.Method;
public class UserContextUtils {
private static final String TAG = "UserContextUtils";
/**
* 現在フォアグラウンドにいるユーザー（Current User）のContextを取得します。
* システムアプリ（platform signature）として署名されている必要があります。
*/
public static Context getCurrentUserContext(Context systemContext) {
try {
// 1. 現在のユーザーIDを取得
// ActivityManager.getCurrentUser() は @hide API ですが、
// AOSPビルド内またはリフレクションでアクセス可能です。
int currentUserId = getCurrentUserId();
Log.d(TAG, "Current User ID detected: " + currentUserId);
// 2. User 0 (System) の場合はそのまま返す（最適化）
if (currentUserId == UserHandle.USER_SYSTEM) {
return systemContext;
}
// 3. UserHandle オブジェクトを生成
// UserHandle.of(int) もAPIレベルによっては隠蔽されていますが、
// コンストラクタ new UserHandle(int) やリフレクションを使用します。
UserHandle userHandle = UserHandle.of(currentUserId);
// 4. そのユーザーとしてのContextを生成
// ここで INTERACT_ACROSS_USERS 権限がチェックされます
return systemContext.createContextAsUser(userHandle, 0);
} catch (Exception e) {
Log.e(TAG, "Failed to get user context", e);
// フォールバックとして元のContextを返すが、ログに残すべき
return systemContext;
}
}
private static int getCurrentUserId() {
try {
// AOSP内部クラス ActivityManager.getCurrentUser() へのリフレクションアクセス
// 注: ビルド時にframework.jarにリンクできる場合は直接呼び出し推奨
Method getCurrentUserMethod = ActivityManager.class.getMethod("getCurrentUser");
return (int) getCurrentUserMethod.invoke(null);
} catch (Exception e) {
Log.w(TAG, "Reflection failed, fallback to ActivityManager.getRunningAppProcesses");
// 代替手段としてRunningAppProcesses等を使う手もあるが、精度は低い
return UserHandle.USER_CURRENT; // -2
}
}
}このコードの肝は、createContextAsUser メソッドです。このメソッドは単にContextをコピーするのではなく、内部の Resources、SharedPreferences、さらには DatabasePath などを指定された UserHandle のものに再配線します。これにより、context.getSharedPreferences("config", 0) を呼び出した際、自動的に /data/user/10/com.myapp/shared_prefs/config.xml が読み書きされるようになります。
実装後の動作検証
この修正を適用する前と後で、マルチユーザー切り替え（User 0 → User 10）時の設定反映成功率を比較しました。テストは自動化されたスクリプトを用いて、100回のユーザー切り替えを行い検証しました。
| 指標 | 修正前 (User 0 Context) | 修正後 (Dynamic Context) |
|---|---|---|
| 設定反映成功率 | 0% (常にSystem Userに書き込み) | 100% |
| SecurityException発生数 | 12件 (特定のAPIコール時) | 0件 |
| ストレージI/Oパス | /data/user/0/... | /data/user/[current_id]/... |
修正前の「成功率0%」というのは、エラーが出ずに成功したように見えて、実際にはアクティブユーザーに反映されていない状態（サイレント・フェイラー）を含みます。これはシステム開発において最も危険な状態です。修正後は、createContextAsUser によって生成されたContextが正しいパスを指していることが確認できました。
注意点とエッジケース
この手法を採用する上で、いくつかの重要な注意点があります。
- 署名権限（Signature Permission）：
INTERACT_ACROSS_USERSは「Signature」レベルの保護がかかっています。つまり、あなたのアプリはプラットフォームキー（platform key）で署名されているか、特権アプリ（priv-app）として/system/priv-app/にインストールされ、ホワイトリストに登録されている必要があります。通常のPlay Storeアプリでは使用できません。 - Contextのメモリリーク：
createContextAsUserで生成したContextは、使い終わった後に明示的に破棄するメソッドはありませんが、参照を保持し続けるとメモリリークの原因になります。必要な処理（設定の読み書きなど）が終わったら、参照を速やかに破棄してください。 - BroadcastReceiverの罠： レシーバー内で非同期処理を行う場合、渡された
contextはレシーバーの戻りとともに無効になる可能性がありますが、createContextAsUserで作ったContextはApplication Contextに近い寿命を持ちます。しかし、ユーザーがログアウト（停止）した直後にそのユーザーのContextへアクセスするとクラッシュする可能性があります。必ずUserManager.isUserRunning()で状態を確認してからアクセスするのがベストプラクティスです。
UserManager.isUserUnlocked(UserHandle) のチェックも忘れずに行いましょう。
結論
AOSPにおけるマルチユーザー対応は、単なるAPIの呼び出し以上の理解を要求されます。UserHandleの概念、プロセスとユーザーの分離、そしてContextの役割を深く理解することで、初めて堅牢なシステムアプリを構築できます。今回紹介した createContextAsUser を用いた手法は、Androidのセキュリティモデルを尊重しつつ、必要なデータアクセスを実現する唯一の正規ルートです。特にエンタープライズ向けや教育機関向けのデバイス開発において、この知識は不可欠となるでしょう。
Post a Comment