في أجهزة Android الجوّالة، يتيح إتاحة استخدام التطبيق من قِبل مستخدمين متعدّدين تشغيله في الخلفية (عندما يكون مستخدم آخر نشطًا) وفي المقدّمة (المعروفة أيضًا باسم المستخدم الحالي). يدير النظام عملية إيقاف المستخدمين للمحافظة على الموارد عندما يكون ذلك مناسبًا. يجب دائمًا توفُّر مستخدم واحد في المقدّمة.
بدءًا من Android 10، يتضمّن نظام Android Automotive إعدادًا أساسيًا
للسماح بتشغيل ثلاثة مستخدمين فقط في المرة الواحدة
(config_multiuserMaxRunningUsers
). لذلك، بالإضافة إلى مستخدم النظام
غير المرئي (المستخدم 0)، يمكن ضبط مستخدم واحد فقط في المقدّمة ومستخدم واحد في الخلفية.
- في الحالات العادية، يتم تشغيل المستخدم الحالي في المقدّمة
وتشغيل مستخدم النظام بدون شاشة (المستخدم 0) في الخلفية. عند نقل مستخدم
إلى الخلفية، يتم إيقافه ولكن لا يتم قفله. عند بلوغ الحد الأقصى
لعدد المستخدمين، يتم إيقاف مستخدم الخلفية الأقل استخدامًا في الآونة الأخيرة
وقفله (
config_multiuserDelayUserDataLocking
). - تتم إعادة تشغيل المستخدمين المتوقفين والمُستخدَمين في الخلفية الذين تم فتح قفلهم أثناء وضع المرآب.
تكون جلسات المستخدمين الضيوف مؤقتة ولا يمكن تشغيلها إلا في المقدّمة. عندما يخرج مستخدم من وضع الضيف، يتم إيقاف حساب الضيف ولا يمكن تشغيله في الخلفية.
عمليات المستخدم في الخلفية
عند تبديل المستخدم من المقدّمة إلى الخلفية (والعكس)، يتم إنهاء جميع الأنشطة والخدمات التي تعمل في المقدّمة لهذا المستخدم. يؤدي ذلك إلى إيقاف جميع الخدمات المرتبطة بهذه الخدمات. ومع ذلك، لا يزال هناك بعض الخطوات التي يجب إكمالها. تستمر خدمات التشغيل المستمر من تطبيقات الطرف الأول وتطبيقات نظام المصنّع الأصلي للجهاز في العمل طالما لم يتم إيقاف المستخدم (الذي يعمل الآن في الخلفية).
إنّ الخدمات الثابتة هي أكثر المشاكل تعقيدًا، لأنّه يتم تضمين هذه الخدمات في حزمة ذات أولوية عالية في نظام إدارة "الذاكرة غير المتوفرة" (OOM) في Android. حتى إذا كانت التطبيقات المخصّصة للمستخدم في المقدّمة تتطلّب المزيد من الذاكرة، لن يتم إنهاء هذه العمليات المستمرة في الخلفية. ونتيجةً لذلك، من وجهة نظر مستخدم التطبيقات التي تعمل في المقدّمة، تستهلك الخدمات الدائمة بشكل دائم قدرًا من الذاكرة ولا يتم إرجاع هذه الذاكرة إلا عندما يعيد المستخدم تشغيل السيارة ويتم إيقاف أي مستخدمين في الخلفية.
حالة المستخدم
يكون المستخدم في حالة إيقاف (STATE_SHUTDOWN
) إلى أن يتم بدء
المستخدم. في حال ضبط بيانات اعتماد المستخدم (مثل رقم التعريف الشخصي)، يتم تشغيل حساب مستخدم Android ولكنه
يظل مقفلاً (STATE_RUNNING_LOCKED
) إلى أن يفتح شخص ما شاشة القفل
لهذا المستخدم. عند فتح قفل الجهاز، يتم فك تشفير مساحة التخزين المشفَّرة للمصادقة
وتصبح أدلة البيانات لهذا المستخدم متاحة. في عمليات تبديل المستخدمين المعتادة،
لا يتم إيقاف المستخدم في الخلفية ويظل قيد التشغيل ومفتوحًا
(STATE_RUNNING_UNLOCKED
)، بعد فتح قفله.
وضع Garage Mode وJobScheduler وتعديلات التطبيقات للمستخدمين
إنّ الطريقة المقترَحة لتطبيقات السيارات لتعديل البيانات هي استخدام JobScheduler
لتحديد موعد تنفيذ المهام عندما يكون الجهاز في حالة السكون، وذلك من خلال وضع المرآب (على سبيل المثال، تنزيل
تحديثات التطبيقات من Google Play). بعد أن تسجِّل التطبيقات المهام باستخدام JobScheduler
و
JobSchedulerService
،
يتم تنفيذ المهام كلما أمكن ذلك.
تُرسِل CarService إشارة إلى JobSchedulerService
لبدء المهام التي تم ضبطها لتعمل
عندما يكون جهاز Automotive في وضع السكون
من خلال وضع Garage Mode. لكي يتمكّن JobSchedulerService
من تنفيذ مهام لمستخدم في الخلفية، يجب أن يكون
هذا المستخدم في الحالة STATE_RUNNING_UNLOCKED
. إنّ المهام التي يتم وضعها في "قائمة الانتظار"
في JobSchedulerService
تبقى محفوظة وتستمر في جميع دورات الطاقة.
لا يمكن لـ JobScheduler
تشغيل مهام لمستخدم معيّن إذا لم يتم
فتح قفل الجهاز للمستخدم مطلقًا بعد دورة طاقة. ومع ذلك، عند فتح قفل المستخدم، وإذا ظلّ المستخدم في
STATE_RUNNING_UNLOCKED
، يمكن تنفيذ المهام الخاصة بالمستخدم.