از 27 مارس 2025، توصیه می کنیم از android-latest-release
به جای aosp-main
برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
حالت تعلیق
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
حالت های قدرت SoC
حالت های قدرت سیستم روی یک تراشه (SoC) عبارتند از: روشن، بیکار و معلق. «روشن» زمانی است که SoC در حال اجرا است. "Idle" یک حالت با قدرت متوسط است که در آن SoC تغذیه می شود اما هیچ وظیفه ای را انجام نمی دهد. "Suspend" یک حالت کم مصرف است که در آن SoC روشن نمی شود. مصرف برق دستگاه در این حالت معمولاً 100 برابر کمتر از حالت «روشن» است.
سنسورهای غیر بیدار
سنسورهای غیر بیدار سنسورهایی هستند که از رفتن SoC به حالت تعلیق جلوگیری نمی کنند و SoC را برای گزارش داده ها بیدار نمی کنند. به ویژه، رانندگان مجاز به نگه داشتن ویک-لاک نیستند. اگر برنامهها میخواهند رویدادها را در حالی که صفحه خاموش است، از حسگرهای غیر بیدار دریافت کنند، وظیفه نگه داشتن قفل بیدار شدن جزئی را بر عهده دارند. در حالی که SoC در حالت تعلیق است، حسگرها باید به کار خود ادامه دهند و رویدادهایی را تولید کنند که در یک FIFO سخت افزاری قرار می گیرند. (برای جزئیات بیشتر به Batching مراجعه کنید.) رویدادهای موجود در FIFO زمانی که SoC بیدار می شود به برنامه ها تحویل داده می شود. اگر FIFO برای ذخیره همه رویدادها خیلی کوچک باشد، رویدادهای قدیمیتر از بین میروند. قدیمیترین دادهها حذف میشوند تا آخرین دادهها را در خود جای دهند. در حالت شدید که FIFO وجود ندارد، تمام رویدادهای ایجاد شده در حالی که SoC در حالت تعلیق است از بین می روند. یک استثنا آخرین رویداد از هر حسگر در حال تغییر است: آخرین رویداد باید خارج از FIFO ذخیره شود تا از بین نرود.
به محض اینکه SoC از حالت تعلیق خارج شد، همه رویدادها از FIFO گزارش می شوند و عملیات به حالت عادی از سر گرفته می شود.
برنامههایی که از حسگرهای غیر بیدار استفاده میکنند باید یک wake lock داشته باشند تا مطمئن شوند که سیستم به حالت تعلیق نمیرود، زمانی که حسگرها به آنها نیازی ندارند ثبت نام خود را لغو کنند، یا انتظار داشته باشند که رویدادها را زمانی که SoC در حالت تعلیق است از دست بدهند.
سنسورهای بیداری
در تقابل با حسگرهای غیر بیدار، حسگرهای بیدار اطمینان می دهند که داده های آنها مستقل از وضعیت SoC تحویل داده می شود. در حالی که SoC بیدار است، حسگرهای بیداری مانند حسگرهای غیر بیدار رفتار می کنند. هنگامی که SoC خواب است، حسگرهای بیداری باید SoC را برای ارائه رویدادها بیدار کنند. آنها همچنان باید به SoC اجازه دهند تا به حالت تعلیق برود، اما همچنین باید زمانی که رویدادی باید گزارش شود، آن را بیدار کنند. یعنی سنسور باید SoC را بیدار کند و رویدادها را قبل از سپری شدن حداکثر تاخیر گزارش یا پر شدن FIFO سخت افزاری ارائه دهد. برای جزئیات بیشتر به Batching مراجعه کنید.
برای اطمینان از اینکه برنامهها قبل از اینکه SoC به خواب برود، زمان دریافت رویداد را دارند، راننده باید هر بار که رویدادی گزارش میشود، یک «وقفه بیدار شدن در زمان بازدارنده» را به مدت 200 میلیثانیه نگه دارد. یعنی SoC نباید در 200 میلی ثانیه پس از وقفه بیدار شدن دوباره به خواب برود. این نیاز در نسخههای اندرویدی آینده ناپدید میشود و تا آن زمان به این زمانبندی wake lock نیاز داریم.
چگونه سنسورهای بیدار و غیر بیدار را تعریف کنیم؟
تا کیت کت، سنسور بیدار یا غیر بیدار با نوع سنسور تعیین می شد: بیشتر آنها حسگرهای غیر بیدار بودند، به استثنای سنسور مجاورت و آشکارساز حرکت قابل توجه .
با شروع از L، اینکه آیا یک حسگر معین یک حسگر بیداری است یا نه، با یک پرچم در تعریف سنسور مشخص می شود. اکثر سنسورها را می توان با جفت انواع بیدار و غیر بیدار از یک حسگر تعریف کرد، در این صورت آنها باید به عنوان دو حسگر مستقل رفتار کنند و با یکدیگر تعامل نداشته باشند. برای جزئیات بیشتر به تعامل مراجعه کنید.
به جز مواردی که در تعریف نوع سنسور طور دیگری مشخص شده باشد، توصیه می شود برای هر نوع حسگر فهرست شده در انواع سنسور، یک حسگر بیدار و یک حسگر غیر بیدار اجرا شود. در تعریف هر نوع حسگر، ببینید چه حسگری (بیدار یا غیر بیدار) توسط SensorManager.getDefaultSensor(sensorType)
برگردانده می شود. این سنسوری است که اکثر برنامه ها از آن استفاده خواهند کرد.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],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."]]