2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
停止モード
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
SoC の電源状態
システム オン チップ(SoC)の電源状態には、オン、アイドル、停止があります。「オン」は SoC が実行されているときです。「アイドル」は、SoC に電力が供給されているが、タスクを実行しない中電力モードです。「停止」は、SoC に電力が供給されていない低電力モードです。このモードでのデバイスの消費電力は、通常、「オン」モードの場合の 100 分の 1 です。
非ウェイクアップ センサー
非ウェイクアップ センサーは、SoC が停止モードに入るのを妨げず、データを報告するために SoC を復帰させないセンサーです。特に、ドライバが wake lock を保持することは許可されていません。画面がオフのときに非ウェイク アップセンサーからイベントを受信する必要がある場合、部分的な wake lock を保持するのはアプリの役割です。SoC が停止モードにある間、センサーは機能し続け、イベントを生成する必要があります。イベントはハードウェア FIFO に入れられます(詳しくは、バッチ処理をご覧ください)。FIFO のイベントは、SoC が復帰したときにアプリに配信されます。FIFO が小さすぎてすべてのイベントを格納できない場合、古いイベントは失われます。つまり、最新のデータを収容するために、最も古いデータが破棄されます。FIFO が存在しない極端な場合、SoC が停止モードになっている間に生成されたすべてのイベントが失われます。ただし、変更中の各センサーからの最新のイベントは例外です。最新のイベントは、失われないように FIFO の外部に保存する必要があります。
SoC が停止モードを終了するとすぐに、FIFO からのすべてのイベントが報告され、通常どおりオペレーションが再開されます。
非ウェイクアップ センサーを使用するアプリは、システムが停止しないように wake lock を保持するか、センサーが不要な場合はセンサーの登録を解除するか、SoC の停止モード時にイベントが失われることを予期する必要があります。
ウェイクアップ センサー
非ウェイクアップ センサーとは対照的に、ウェイクアップ センサーは、SoC の状態に関係なくデータが配信されることを保証します。SoC が起動している間、ウェイクアップ センサーは非ウェイクアップ センサーのように動作します。SoC がスリープ状態のとき、ウェイクアップ センサーはイベントを配信するために SoC を復帰させる必要があります。ウェイクアップ センサーは SoC を停止モードにする必要があるとともに、イベントの報告が必要な場合に SoC を復帰させなければなりません。つまり、最大レポート レイテンシが経過する前、またはハードウェア FIFO がいっぱいになる前に、SoC を復帰させてイベントを配信する必要があります。
詳細については、バッチ処理をご覧ください。
SoC がスリープ状態に戻る前にアプリがイベントを受信する時間を確保するには、イベントが報告されるたびにドライバが「タイムアウト wake lock」を 200 ミリ秒保持する必要があります。つまり、SoC がウェイクアップ割り込み後 200 ミリ秒以内にスリープに戻ることを許可するべきではありません。この要件は将来の Android リリースでなくなる予定ですが、それまではこのタイムアウト wake lock が必要です。
ウェイクアップ センサーと非ウェイクアップ センサーの定義方法
KitKat までは、センサーがウェイクアップ センサーであるか非ウェイクアップ センサーであるかは、センサーの種類によって決まりました。近接センサーと重要なモーション検出器を除いて、ほとんどが非ウェイクアップ センサーでした。
L 以降、特定のセンサーがウェイクアップ センサーであるかどうかは、センサー定義のフラグによって指定されます。ほとんどのセンサーは、同じセンサーのウェイクアップ バリアントと非ウェイクアップ バリアントのペアで定義できます。この場合、互いに相互作用するのではなく、2 つの独立したセンサーとして動作する必要があります。詳しくは、インタラクションをご覧ください。
センサータイプの定義で特に指定されていない限り、センサータイプにリストされているセンサータイプごとに、ウェイクアップ センサーと非ウェイクアップ センサーを 1 つずつ実装することをおすすめします。各センサータイプの定義で、SensorManager.getDefaultSensor(sensorType)
によって返されるセンサー(ウェイクアップまたは非ウェイクアップ)を確認します。ほとんどのアプリでそのセンサーが使用されます。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-07-27 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-07-27 UTC。"],[],[],null,["# Suspend mode\n\nSoC power states\n----------------\n\nThe power states of the system on a chip (SoC) are: on, idle, and suspend. \"On\" is when the\nSoC is running. \"Idle\" is a medium power mode where the SoC is powered but\ndoesn't perform any tasks. \"Suspend\" is a low-power mode where the SoC is not\npowered. The power consumption of the device in this mode is usually 100 times\nless than in the \"On\" mode.\n\nNon-wake-up sensors\n-------------------\n\nNon-wake-up sensors are sensors that do not prevent the SoC\nfrom going into suspend mode and do not wake the SoC up to report data. In\nparticular, the drivers are not allowed to hold wake-locks. It is the\nresponsibility of applications to keep a partial wake lock should they wish to\nreceive events from non-wake-up sensors while the screen is off. While the SoC\nis in suspend mode, the sensors must continue to function and generate events,\nwhich are put in a hardware FIFO. (See [Batching](/docs/core/interaction/sensors/batching) for more details.) The events in the\nFIFO are delivered to the applications when the SoC wakes up. If the FIFO is\ntoo small to store all events, the older events are lost; the oldest data is dropped to accommodate\nthe latest data. In the extreme case where the FIFO is nonexistent, all events\ngenerated while the SoC is in suspend mode are lost. One exception is the\nlatest event from each on-change sensor: the last event [must be saved](/docs/core/interaction/sensors/batching#precautions_to_take_when_batching_non-wake-up_on-change_sensors)outside of the FIFO so it cannot be lost.\n\nAs soon as the SoC gets out of suspend mode, all events from the FIFO are\nreported and operations resume as normal.\n\nApplications using non-wake-up sensors should either hold a wake lock to ensure\nthe system doesn't go to suspend, unregister from the sensors when they do\nnot need them, or expect to lose events while the SoC is in suspend mode.\n\nWake-up sensors\n---------------\n\nIn opposition to non-wake-up sensors, wake-up sensors ensure that their data is\ndelivered independently of the state of the SoC. While the SoC is awake, the\nwake-up sensors behave like non-wake-up-sensors. When the SoC is asleep,\nwake-up sensors must wake up the SoC to deliver events. They must still let the\nSoC go into suspend mode, but must also wake it up when an event needs to be\nreported. That is, the sensor must wake the SoC up and deliver the events\nbefore the maximum reporting latency has elapsed or the hardware FIFO gets full.\nSee [Batching](/docs/core/interaction/sensors/batching) for more details.\n\nTo ensure the applications have the time to receive the event before the SoC\ngoes back to sleep, the driver must hold a \"timeout wake lock\" for 200\nmilliseconds each time an event is being reported. *That is, the SoC should not\nbe allowed to go back to sleep in the 200 milliseconds following a wake-up\ninterrupt.* This requirement will disappear in a future Android release, and we\nneed this timeout wake lock until then.\n\nHow to define wake-up and non-wake-up sensors?\n----------------------------------------------\n\nUp to KitKat, whether a sensor was a wake-up or a non-wake-up sensor was\ndictated by the sensor type: most were non-wake-up sensors, with the exception\nof the [proximity](/docs/core/interaction/sensors/sensor-types#proximity) sensor and the [significant motion detector](/docs/core/interaction/sensors/sensor-types#significant_motion).\n\nStarting in L, whether a given sensor is a wake-up sensor or not is specified\nby a flag in the sensor definition. Most sensors can be defined by pairs of\nwake-up and non-wake-up variants of the same sensor, in which case they must\nbehave as two independent sensors, not interacting with one another. See\n[Interaction](/docs/core/interaction/sensors/interaction) for more details.\n\nUnless specified otherwise in the sensor type definition, it is recommended to\nimplement one wake-up sensor and one non-wake-up sensor for each sensor type\nlisted in [Sensor types](/docs/core/interaction/sensors/sensor-types). In each sensor type\ndefinition, see what sensor (wake-up or non-wake-up) will be returned by\n`SensorManager.getDefaultSensor(sensorType)`. It is the sensor\nthat most applications will use."]]