2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main 대신 android-latest-release를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
정지 모드
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
SoC 전원 상태
SoC(단일 칩 시스템)의 전원 상태는 켜짐, 유휴 및 정지입니다. '켜짐'은 SoC가 실행 중인 상태입니다. '유휴'는 SoC에 전원이 공급되지만, 작업은 실행하지 않는 중간 전력 모드입니다. '정지'는 SoC에 전원이 공급되지 않는 저전력 모드입니다. 이 모드에서는 일반적으로 기기의 전력 소모량이 '켜짐' 모드보다 100배 적습니다.
Non-wake-up 센서
Non-wake-up 센서는 SoC가 정지 모드로 전환되지 않도록 예방하고 데이터 보고를 위해 SoC를 절전 모드를 해제하지 않는 센서입니다. 특히, 드라이버에서 wake lock을 유지하는 것이 허용되지 않습니다. 애플리케이션은 화면이 꺼진 상태에서 non-wake-up 센서의 이벤트를 수신하고 싶은 경우 부분적 wake lock을 유지해야 합니다. SoC가 정지 모드인 상태에서 센서는 계속해서 작동하고 이벤트를 생성해야 하며, 이러한 이벤트는 하드웨어 FIFO에 배치됩니다. 자세한 내용은 일괄 처리를 참고하세요. FIFO의 이벤트는 SoC의 절전 모드가 해제되면 애플리케이션으로 전달됩니다. 모든 이벤트를 저장하기에 FIFO가 너무 작다면 기존 이벤트가 사라지며, 최신 데이터를 저장할 수 있도록 가장 오래된 데이터가 삭제됩니다. FIFO가 존재하지 않는 극단적인 경우에는 SoC가 정지 모드인 상태에서 생성된 모든 이벤트가 사라집니다. 한 가지 예외는 각 on-change 센서의 최근 이벤트입니다. 마지막 이벤트는 사라지지 않도록 FIFO 외부에 저장되어야 합니다.
SoC의 정지 모드가 해제되는 즉시, FIFO의 모든 이벤트가 보고되고 작업이 평상시처럼 계속됩니다.
Non-wake-up 센서를 사용하는 애플리케이션은 wake lock을 유지하여 시스템이 정지 상태로 전환되지 않도록 하거나 필요 없는 센서에서 등록 해제하거나 SoC가 정지 모드를 유지하는 동안 이벤트가 사라진다는 점을 예상해야 합니다.
Wake-up 센서
Non-wake-up 센서와 달리, wake-up 센서는 SoC 상태와 상관없이 데이터가 제공되도록 합니다. Soc가 활성화된 동안에는 wake-up 센서가 non-wake-up 센서처럼 동작합니다. SoC가 절전 모드로 전환되면 wake-up 센서가 SoC를 활성화하여 이벤트를 전달해야 합니다. 계속해서 SoC가 정지 모드로 전환되도록 해야 하지만 이벤트를 보고해야 하는 경우에는 SoC를 활성화해야 합니다. 즉, 센서는 최대 보고 지연 시간이 지나거나 하드웨어 FIFO가 가득 차기 전에 SoC를 활성화하여 이벤트를 전달해야 합니다.
자세한 내용은 일괄 처리를 참고하세요.
SoC가 다시 절전 모드로 전환되기 전에 애플리케이션이 이벤트를 수신할 수 있는 시간을 확보할 수 있도록 하려면 이벤트가 보고될 때마다 드라이버가 '시간 제한 wake lock'을 200밀리초 동안 유지해야 합니다. 즉, SoC는 wake-up 개입이 있은 후 200밀리초 동안 절전 모드로 전환되면 안 됩니다. 이 요구사항은 향후 Android 버전에서 사라질 예정이며, 그때까지는 이러한 시간 제한 wake lock이 필요합니다.
Wake-up 및 non-wake-up 센서는 어떻게 정의해야 하나요?
KitKat까지는 센서 유형에 따라 센서가 wake-up인지 non-wake-up인지 결정되었으며, 근접 센서 및 중요한 움직임 감지기를 제외하면 대부분이 non-wake-up 센서였습니다.
L부터는 센서 정의의 플래그에서 지정된 센서의 wake-up 센서 여부를 지정합니다. 대부분의 센서는 같은 센서의 wake-up 및 non-wake-up 변형 쌍으로 정의할 수 있으며, 여기서 센서는 서로 간에 상호작용하는 것이 아니라 두 개의 독립적인 센서로 동작해야 합니다. 자세한 내용은 상호작용을 참고하세요.
센서 유형 정의에 달리 명시되지 않은 이상 센서 유형에 나열된 센서 유형마다 wake-up 센서와 non-wake-up 센서를 하나씩 구현하는 것이 좋습니다. 각 센서 유형 정의에서 SensorManager.getDefaultSensor(sensorType)이 반환하는 센서(wake-up 또는 non-wake-up)가 무엇인지 확인하세요. 이 센서가 대부분의 애플리케이션에서 사용하게 될 센서입니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 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."]]
