ウェイクロックのユースケースを特定して最適化する

このドキュメントは、アプリでのウェイクロックのユースケースを特定して最適化するのに役立ちます。また、このユースケースに関連付けられた他のライブラリやシステム API によって取得されたウェイクロックがある場合は、それもハイライト表示します。これらのウェイクロックはアプリに起因するため、問題のあるウェイクロックの発生源を特定するのは困難です。API の使用方法が正しくないと、明示的にウェイクロックを取得していなくても、アプリが過剰なウェイクロックの使用でフラグ付けされる可能性があります。

このドキュメントでは、ウェイクロック デバッグツールの使用時や、バイタルのレポートで発生する可能性のある一般的なウェイクロック名をいくつか紹介します。これらの名前は、ライブラリまたはシステム API から取得されることも、難読化されることもあります。デバッグツールを使用して動作不良のウェイクロックを特定し、このドキュメントでウェイクロック名を検索することで、どの API が問題の原因となっているかを特定し、その使用を最適化する方法に関する推奨事項を見つけることができます。

このドキュメントでは、ウェイクロックの取得に関する一般的なユースケースの概要、さまざまな API やライブラリで使用されるウェイクロック名の詳細、ウェイクロックの使用を最適化して削減するための推奨事項とベスト プラクティスについて説明します。

• AlarmManager
• 音声とメディア
• Bluetooth
• デバイス センサー
• Firebase Cloud Message（FCM）
• JobScheduler
• 位置情報
• リモート メッセージ
• WorkManager
• _UNKNOWN: ウェイクロック名が個人を特定できる情報（PII）を使用していると思われる場合に、デバッグツールによって表示されます。

AlarmManager

AlarmManager は wake lock を取得し、呼び出し元のアプリに割り当てます。AlarmManager は、アラームが鳴ると wake lock を取得し、アラーム ブロードキャストの onReceive() メソッドの実行が完了するとロックを解除します。

wake lock 名

AlarmManager は *alarm* という名前のウェイクロックを作成します。（アスタリスクはウェイクロック名の一部であり、ワイルドカードを表すものではありません）。

推奨事項

アラームの動作を最適化するには、次の方法をおすすめします。

• 不正確なアラームと正確なアラームのどちらにするかを決めるには、アラームタイプを選択するを参照してください。アラームの精度がそれほど重要でない場合は、不正確なアラームを使用すると、システムがスケジュールをより柔軟に設定できるようになり、バッテリーの寿命を延ばすことができます。
• システムによって課せられるアラームの割り当てを認識し、それを尊重するようにアプリを設計します。
• onReceive() メソッドで長時間かかる作業を行わないようにし、アラームの後に追加の処理が必要な場合はワーカーをスケジュールします。

音声とメディア

メディア API は、音声の録音または再生時にウェイクロックを取得できます。ウェイクロックは呼び出し元のアプリに割り当てられます。

wake lock 名

メディア API は、Audio で始まるさまざまな名前のウェイクロックを取得します。

• AudioBitPerfect: ロスレス USB オーディオ再生に使用されます。
• AudioDirectOut: テレビや特殊なデバイスでのロスレス音声再生に使用されます。
• AudioDup: Bluetooth または USB で接続しているときに通知を再生するために使用されます。
• AudioIn: マイクが有効な状態でビデオカメラ モードの場合に、音声キャプチャに使用されます。
• AudioMix: 共通デバイスへの音声再生に使用されます。
• AudioOffload: このモードをサポートするアプリで、音楽のみの長期再生に使用されます。
• AudioSpatial: 空間オーディオをサポートするデバイスでマルチチャンネルの映画や音楽の音声を再生するために使用されます。
• AudioUnknown: 他の状況に当てはまらない場合に使用します。
• MmapCapture: 低レイテンシの音声キャプチャに使用されます。
• MmapPlayback: ゲームやプロフェッショナル オーディオ アプリケーションなど、低レイテンシの再生に使用されます。

推奨事項

次の方法をおすすめします。

• Audio で始まる wake lock 名を宣言しないでください。
• メディア API を使用している場合、ウェイクロックを直接取得する必要はありません。API が必要なウェイクロックを自動的に取得します。
• メディア API を使用する場合は、不要になった時点でメディア セッションと関連するフォアグラウンド サービスを終了します。

Bluetooth

プラットフォームの Bluetooth API は、主に Bluetooth アクションの発生中にカーネル ウェイクロックを保持します。これはアプリケーションに起因するものではありません。

推奨事項

• コンパニオン デバイスのペア設定を使用して Bluetooth デバイスをペア設定し、Bluetooth のペア設定中に手動ウェイクロックを取得しないようにします。
• バックグラウンドでの Bluetooth 通信を行う方法については、バックグラウンドでの通信のガイダンスを参照してください。
• 遅延したコミュニケーションがユーザーに影響しない場合は、WorkManager を使用すれば十分なことがよくあります。手動ウェイクロックが必要と判断された場合は、Bluetooth アクティビティまたはアクティビティ データの処理の期間のみウェイクロックを保持します。

デバイスのセンサー

歩数、加速度計、ジャイロスコープのデータなど、デバイスのセンサーデータをトラッキングする方法はいくつかあります。

Wear OS では、Wear ヘルスサービスを使用して、標高、心拍数、移動距離などのデバイスデータを取得します。

他のアプリによってデータが収集される場合は、WorkManager と組み合わせて ヘルスコネクトを使用し、データを定期的に取得できます。

歩数や移動距離の差分をトラッキングするなどのシナリオでは、モバイルの Recording API と WorkManager を組み合わせて使用して、データを定期的に取得できます。過去の歩数データ（1 日の合計歩数や過去 6 時間の歩数など）にアクセスするために、ヘルスコネクトは Android 14 以降を搭載したデバイスのデバイス上の歩数トラッキングもサポートしています。

状況によっては、SensorManager を使用してカスタム デバイス センサー トラッキングが必要になることがあります。SensorManager は、センサーがウェイクアップ センサーでない限り、アプリに代わってウェイクロックを取得しません。ウェイクアップ センサーは isWakeUpSensor API を使用して識別できます。

推奨事項

センサーを使用して高いサンプリング レートで記録すると、バッテリーが大幅に消耗する可能性があります。バッテリーの消耗とウェイクロックの使用を減らすための推奨事項は次のとおりです。

• 歩数や移動距離をトラッキングする場合は、Recording API を使用して、バッテリー効率の良い方法でデータを記録します。Android 14 以降を搭載したデバイスの場合、過去のデバイスデータや歩数の合計にアクセスするには、ヘルスコネクトの使用を検討してください。
• Wear OS でパッシブ センサー トラッキングを行う場合は、Wear ヘルスサービスを使用してバッテリー使用量を最適化します。
• SensorManager でセンサーを登録する際は、30 秒を超える maxReportLatencyUs を定義して、センサー バッチ処理ロジックを使用し、アプリが受け取る割り込みの数を減らします。その後、デバイスがユーザー操作、位置情報の取得、スケジュールされたジョブなどの別のトリガーによって起動されると、システムはキャッシュに保存されたセンサーデータを直ちにディスパッチします。
• アプリで位置情報とセンサーデータの両方が必要な場合は、イベントの取得と処理を同期します。センサーの読み取り値を、位置情報の更新のためにシステムが保持する短いウェイクロックに統合することで、CPU を起動状態に保つためのウェイクロックが不要になります。ワーカーまたは短時間のウェイクロックを使用して、この結合データのアップロードと処理を処理します。

Firebase Cloud Message（FCM）

Firebase Cloud Message（FCM）ブロードキャストをアプリに配信している間、ウェイクロックが取得されます。FCM ブロードキャストの onMessageReceived() メソッドの実行が終了すると、ウェイクロックは解放されます。

wake lock 名

デバイスで FCM メッセージを受信すると、GOOGLE_C2DM という名前の短いウェイクロックが保持されます。Android 16 以降では、ウェイクロックの名前は GCM_MESSAGE です。

推奨事項

FCM の動作を最適化するには、次の方法をおすすめします。

• FCM 配信の頻度を最適化します。
• メッセージをすぐに配信する必要がある場合を除き、優先度の高い FCM は使用しないでください。
• onMessageReceived() メソッドをできるだけ早く完了させるか、追加の処理が必要な場合はタスクを続行するワーカーをスケジュールします。詳細については、Firebase のガイダンスをご覧ください。

JobScheduler

JobScheduler ジョブは、バックグラウンドでタスクを実行している間、wake lock を取得します。ウェイクロックは、ワーカーを作成したアプリに帰属します。

wake lock 名

JobScheduler によって取得されるウェイクロックの名前は、実行されている Android システムのバージョンとジョブの目的によって異なります。

不等号記号で囲まれた項目は変数です。たとえば、"<package_name>" は、リテラル テキスト <package name> ではなく、アプリのパッケージの名前です。ただし、*job* はアスタリスクを含む文字シーケンス *job* であり、アスタリスクはワイルドカードとして使用されていません。

Android 15 以前

ユーザーが開始したジョブは、次のパターンに従った名前のウェイクロックを作成します。

*job*u/@<name_space>@/<package_name>/<classname>

他のジョブでは、このパターンが使用されています。

*job*/@<name_space>@/<package_name>/<classname>

Android 16.1 以降

ユーザーが開始したジョブは、次のパターンに従った名前のウェイクロックを作成します。

*job*u/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

優先ジョブでは次のパターンが使用されます。

*job*e/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

通常のジョブでは、次のパターンを使用します。

*job*r/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

例

Namespace backup とトレースタグ started を持つ優先ジョブがあるとします。パッケージ名は com.example.app で、ジョブを作成したクラスは com.backup.BackupFileService です。

Android 15 以下を搭載するデバイスでは、ウェイクロックの名前は次のようになります。

*job*/@backup@/com.example.app/com.backup.BackupFileService

Android 16.1 以降を搭載したデバイスでは、ウェイクロックの名前は次のようになります。

*job*e/@backup@/#started#/com.example.app/com.backup.BackupFileService

推奨事項

• ユーザーが開始したダウンロード/ アップロードのユースケースでは、手動の wake lock を取得しないでください。代わりに、ユーザーが開始したデータ転送（UIDT）API を使用してください。これは、ユーザーが開始した長時間実行されるデータ転送タスクの指定パスです。
• JobScheduler によって作成されたウェイクロックでウェイクロックの使用率が高いことが判明した場合は、特定のシナリオでジョブが完了しないように誤って構成されている可能性があります。STOP_REASON_TIMEOUT の発生頻度が高い場合は、ジョブの停止理由の分析を検討してください。
• JobScheduler タスクの使用状況を監査します。特に、タスク スケジューリング API のバッテリー使用量を最適化するためのガイダンスに沿って対応してください。

場所

LocationManager と FusedLocationProviderClient は、ウェイクロックを使用してデバイスの位置情報を取得し、配信します。ウェイクロックは、これらの API を呼び出したアプリに帰属します。

wake lock 名

位置情報サービスでは次の名前が使用されます。

• CollectionLib-SigCollector
• NetworkLocationLocator
• NetworkLocationScanner
• NlpCollectorWakeLock
• NlpWakeLock
• *location*

推奨事項

• 位置情報の使用を最適化するためのガイダンスをご覧ください。タイムアウトの実装、位置情報リクエストのバッチ処理の活用、パッシブな位置情報の更新の利用を検討してください。
• 位置情報のキャッシュ保存のために個別の継続的なウェイクロックを取得することは避けてください。これは冗長であり、削除されるべきです。FusedLocationProvider または LocationManager API を使用して位置情報の更新をリクエストすると、位置情報イベント コールバック中にデバイスの起動が自動的にトリガーされます。代わりに、位置情報イベントをメモリまたはストレージに保存し、WorkManager を使用して位置情報イベントを定期的に処理します。

リモート メッセージ

このセクションでは、アプリが接続を維持したり、他のデバイスからのイベントに反応したりする必要があるリモート メッセージングに関連するシナリオについて説明します。このシナリオでは、ウェイクロックの使用に影響を与える可能性があります。一般的なユースケースは次のとおりです。

• ローカル ネットワーク経由で接続された外部デバイスで発生するイベントをモニタリングする必要がある、動画または音声モニタリング コンパニオン アプリ。
• デスクトップ バリアントとのネットワーク ソケット接続を維持するメッセージ アプリ。

これらのリモート メッセージング シナリオでのウェイクアップのほとんどは、カーネル ウェイクロックです。カーネル ウェイクロックはアプリに帰属しないため、ここにリストする関連するウェイクロック名はありません。

推奨事項

• ネットワーク イベントをサーバーサイドで処理できる場合は、FCM を使用してクライアントで情報を受信します。FCM データの追加処理が必要な場合は、高速ワーカーをスケジュールできます。
• ソケット接続を使用してクライアント側でイベントを処理する必要がある場合、イベント割り込みをリッスンするためにウェイクロックは必要ありません。データ パケットが Wi-Fi または携帯通信会社の無線に到達すると、無線ハードウェアがカーネル ウェイクロックの形式で割り込みをトリガーします。その後、ワーカーのスケジュールを設定するか、ウェイクロックを取得してデータを処理するかを選択できます。
• たとえば、ktor-network を使用してネットワーク ソケット上のデータ パケットをリッスンしている場合、パケットがクライアントに配信されたときにのみウェイクロックを取得する必要があります。

WorkManager

WorkManager ワーカーは、バックグラウンドでタスクを実行する際にウェイクロックを取得します。ウェイクロックは、ワーカーを作成したアプリに帰属します。

wake lock 名

WorkManager が取得するウェイクロックの名前は、実行されている Android システムのバージョンによって異なります。

Android 15 以前

WorkManager タスクは、次のパターンに従った名前のウェイクロックを作成します。

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

Android 16.1 以降

優先タスクは、次のパターンに従った名前のウェイクロックを作成します。

*job*e/#<trace_tag>#/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

通常のタスクは次のパターンに従います。

*job*r/#<trace_tag>#/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

デフォルトでは、<trace_tag> がワーカー名です。

例

BackupFileWorker という名前の迅速処理ワーカーがあるとします。パッケージ名は com.example.app です。

Android 15 以下を搭載するデバイスでは、ウェイクロックの名前は次のようになります。

*job*/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

Android 16 以降を搭載し、WorkManager 2.10.0+ を使用するデバイスでは、ウェイクロックの名前は次のようになります。

*job*e/#BackupFileWorker#/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

推奨事項

• WorkManager のバージョンを最新の安定版にアップグレードすると、Android 16.1 以降でウェイクロック タグがより詳細になります。
• WorkManager ワーカーの使用状況を監査します。特に、タスク スケジューリング API のバッテリー使用量を最適化するためのガイダンスに準拠していることを確認します。Android 16.1 以降でウェイクロック タグをより詳細にするには、ワーカーの setTraceTag メソッドを使用して、どのクラスがワーカーをスケジュールしたかなどのデバッグ情報を追加します。
• WorkManager によって作成されたウェイクロックでウェイクロックの使用率が高いことが判明した場合は、特定のシナリオで完了しないようにワーカーが誤って構成されている可能性があります。特に STOP_REASON_TIMEOUT の発生頻度が高い場合は、ワーカーの停止理由の分析を検討してください。
• ワーカーの停止理由のロギングに加えて、ワーカーのデバッグに関するドキュメントもご覧ください。また、ウェイクロックが取得および解放されたタイミングを把握するために、システム トレースの収集と分析も検討してください。

_UNKNOWN

デバッグツールが wake lock 名に個人情報（PII）が含まれていると判断した場合、実際の wake lock 名は表示されません。代わりに、ウェイクロックに _UNKNOWN というラベルを付けます。たとえば、ウェイクロック名にメールアドレスが含まれている場合、ツールがこれを行うことがあります。

推奨事項

wake lock の命名に関するベスト プラクティスに従い、wake lock 名に PII を使用しないでください。アプリに起因する _UNKNOWN という名前のウェイクロックが見つかった場合は、どのウェイクロックであるかを特定し、別の名前を付けてください。