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