اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
وضع التعليق
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
حالات الطاقة في منظومة على رقاقة (SoC)
حالات الطاقة في المنظومة على رقاقة (SoC) هي: التشغيل ووضع السكون والتعليق. "مفعّل": عندما يكون معالج SoCقيد التشغيل "الخمول" هو وضع متوسط الطاقة يتم فيه تشغيل شريحة المعالجة المركزية (SoC) ولكنه
لا يؤدي أي مهام. "تعليق" هو وضع للطاقة المنخفضة لا يتم فيه
تشغيل شريحة المعالجة المركزية. وعادةً ما يكون استهلاك الطاقة في هذا الوضع أقل بـ 100 مرة مقارنةً بالوضع "قيد التشغيل".
أجهزة الاستشعار التي لا تؤدي إلى تشغيل الكاميرا
إنّ أجهزة الاستشعار التي لا تُوقِظ الجهاز هي أجهزة استشعار لا تمنع منظومة SoC
من الدخول في وضع التعليق ولا توقِظ منظومة SoC لتسجيل البيانات. على وجه الخصوص، لا يُسمح لبرامج التشغيل بالاحتفاظ بقفل التنشيط. تقع على عاتق التطبيقات مهمة الاحتفاظ بقفل تنشيط جزئي إذا أرادت تلقّي أحداث من أجهزة الاستشعار التي لا تؤدي إلى تنشيط الشاشة عندما تكون مطفأة. وعندما يكون المعالج SoC في وضع التعليق، يجب أن تستمر أجهزة الاستشعار في العمل وإنشاء الأحداث التي يتم وضعها في ذاكرة وصول عشوائي (RAM) ذات أولوية عكسية للأجهزة. (اطّلِع على المعالجة المجمّعة لمزيد من التفاصيل). يتم إرسال الأحداث في ملف FIFO إلى التطبيقات عند تنشيط وحدة المعالجة المركزية (SoC). إذا كان حجم "الذاكرة المؤقتة للقراءة أولاً"
صغيرًا جدًا لتخزين جميع الأحداث، يتم فقدان الأحداث الأقدم، ويتم حذف البيانات الأقدم لإتاحة
أحدث البيانات. في الحالة القصوى التي لا يتوفّر فيها جدول "الأول بالدخول أولاً بالخروج"، يتم فقدان جميع الأحداث
التي تم إنشاؤها عندما يكون المعالج الدقيق في وضع التعليق. هناك استثناء واحد وهو
آخر حدث من كلّ أداة استشعار تعمل عند حدوث تغيير: يجب حفظ الحدث الأخير خارج "الذاكرة بأولوية الوصول إلى العنصر الأخير" لكي لا يتم فقدانه.
بعد خروج وحدة المعالجة المركزية من وضع التعليق، يتم تسجيل جميع الأحداث من "قائمة الانتظار للأولوية القصوى" ويعود العمل كالمعتاد.
يجب أن تحافظ التطبيقات التي تستخدم أدوات الاستشعار غير المخصّصة للتنشيط على قفل التنشيط لضمان عدم دخول النظام إلى وضع التعليق، أو إلغاء التسجيل من أدوات الاستشعار عندما لا تحتاج إليها، أو توقّع فقدان الأحداث عندما يكون المعالج الدقيق في وضع التعليق.
أجهزة الاستشعار لتشغيل الكاميرا
على عكس أجهزة الاستشعار غير المخصّصة لتنشيط الجهاز، تضمن أجهزة الاستشعار المخصّصة لتنشيط الجهاز إرسال بياناتها
بشكل مستقل عن حالة وحدة المعالجة المركزية (SoC). وعندما تكون وحدة المعالجة المركزية مفعّلة، تتصرف
أجهزة الاستشعار المخصّصة لتنشيط الجهاز مثل أجهزة الاستشعار غير المخصّصة لتنشيط الجهاز. عندما تكون شريحة المعالجة المركزية في وضع السكون،
يجب أن تُوقِظ أدوات الاستشعار الشريحة لعرض الأحداث. يجب أن يسمحوا لوحدة المعالجة المركزية بالانتقال إلى وضع التعليق، ولكن يجب أيضًا تنشيطها عند الحاجة إلى الإبلاغ عن حدث. وهذا يعني أنّه على أداة الاستشعار تنشيط وحدة المعالجة المركزية (SoC) وإرسال الأحداث
قبل انقضاء الحد الأقصى لمُدد الاستجابة في إعداد التقارير أو قبل امتلاء ذاكرة التخزين المؤقت للأجهزة للبيانات التي يتم نقلها من نظام إلى آخر.
يمكنك الاطّلاع على المعالجة المجمّعة لمزيد من التفاصيل.
لضمان أن تتلقّى التطبيقات الحدث قبل أن يعود المعالج المركزي (SoC)
إلى وضع السكون، يجب أن يحتفظ برنامج التشغيل بـ "قفل الاستيقاظ عند انتهاء مهلة" لمدة 200
مللي ثانية في كل مرة يتم فيها الإبلاغ عن حدث. أي أنّه يجب عدم السماح لوحدة المعالجة المركزية (SoC) بالرجوع إلى وضع السكون خلال فترة 200 ملي ثانية بعد انقطاع عملية التنشيط. سينتهي هذا الشرط في إصدار Android مستقبلي، وسنحتاج
إلى قفل التنشيط هذا إلى حين ذلك.
كيف يمكن تحديد أدوات الاستشعار التي تُنشئ إشعارات وتلك التي لا تُنشئ إشعارات؟
حتى نظام التشغيل KitKat، كان نوع أداة الاستشعار هو الذي يحدّد ما إذا كانت أداة الاستشعار مخصّصة للتنشيط أو غير مخصّصة للتنشيط: كان معظمها غير مخصّص للتنشيط، باستثناء أداة استشعار التقارب وكاشف الحركة المهمة.
بدءًا من الإصدار L، يتم تحديد ما إذا كان جهاز استشعار معيّن هو جهاز استشعار للتنشيط أم لا
باستخدام علامة في تعريف جهاز الاستشعار. يمكن تعريف معظم أجهزة الاستشعار من خلال أزواج من
الصيغ التي تعمل على تنشيط الجهاز وغير النشطة للجهاز نفسه، وفي هذه الحالة يجب أن
تعمل كجهازَي استشعار مستقلَّين لا يتفاعلان مع بعضهما. اطّلِع على التفاعل للحصول على مزيد من التفاصيل.
ما لم يتم تحديد خلاف ذلك في تعريف نوع أداة الاستشعار، ننصح ب
استخدام أداة استشعار واحدة للتنشيط وأداة استشعار واحدة غير مخصّصة للتنشيط لكل نوع من أنواع أدوات الاستشعار
المدرَجة في أنواع أدوات الاستشعار. في كل تعريف لنوع المستشعر
، يمكنك الاطّلاع على المستشعر (المستشعر الذي يوقّع الجهاز أو لا يوقّعه) الذي سيعرضه
SensorManager.getDefaultSensor(sensorType). وهو أداة الاستشعار التي ستستخدمها معظم التطبيقات.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","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 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],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."]]
