خصائص HAL للمستخدم

تحتوي العديد من هياكل المركبات الحالية على العديد من وحدات التحكم الإلكترونية (ECUs) خارج نظام المعلومات والترفيه الذي يتحكم في بيئة العمل ، مثل إعدادات المقعد وتعديلات المرآة. استنادًا إلى هياكل الأجهزة والطاقة الحالية ، يتم تشغيل العديد من وحدات التحكم الإلكترونية قبل تشغيل نظام المعلومات والترفيه المستند إلى Android. ويمكن لهذه وحدة نقدية أوروبية التفاعل مع نظام المعلومات والترفيه الروبوت القائم من خلال طبقة تجريد الأجهزة سيارة (VHAL) .

بدءًا من Android 11 ، قدم نظام التشغيل Android Automotive OS (AAOS) مجموعة جديدة من الخصائص على VHAL لإنشاء الملحقات الخارجية وتبديلها وإزالتها وربطها لتحديد المستخدمين. على سبيل المثال، هذه الخصائص الجديدة تمكن سائق لزوج-ربط ملحق خارجي، مثل مفتاح فوب، إلى العضو الذي يعمل بنظام Android. ثم ، عندما يقترب السائق من السيارة ، تستيقظ وحدة التحكم الإلكترونية وتكتشف مفتاح التشغيل. تشير وحدة التحكم الإلكترونية هذه إلى HAL إلى مستخدم Android الذي يجب أن يبدأ نظام المعلومات والترفيه تشغيله ، مما يقلل من الوقت الذي ينتظره السائق حتى يتم تحميل مستخدم Android الخاص به.

قم بتمكين HAL للمستخدم

خصائص HAL العضو يجب تمكين بوضوح من خلال ضمان نظام الملكية android.car.user_hal_enabled ومن المقرر أن true . (يمكن أيضا أن يتم ذلك في car.mk الملف، بحيث لا يلزم أن يكون تعيين يدويا.) تأكد من أن user_hal_enabled=true تمكين من إلقاء UserHalService :

$ adb shell dumpsys car_service --hal UserHalService|grep enabled
user_hal_enabled=true

يمكنك أيضا التحقق من user_hal_enabled باستخدام بنك التنمية الاسيوى قذيفة getprop android.car.user_hal_enabled أو adb logcat CarServiceHelper *:s . إذا تم تعطيل خاصية، يتم عرض رسالة كما يلي عندما system_server يبدأ:

I CarServiceHelper: Not using User HAL

يدويا تمكين user_hal_enabled ، تعيين android.car.user_hal_enabled نظام الملكية وإعادة تشغيل system_server :

$ adb shell setprop android.car.user_hal_enabled true
$ adb shell stop && adb shell start

و logcat يبدو الإخراج على النحو التالي:

I CarServiceHelper: User HAL enabled with timeout of 5000ms
D CarServiceHelper: Got result from HAL: OK
I CarServiceHelper: User HAL returned DEFAULT behavior

خصائص HAL للمستخدم

خصائص دورة حياة المستخدم

توفر الخصائص التالية معلومات HAL لحالات دورة حياة المستخدم ، والتي تتيح مزامنة دورة حياة المستخدم بين نظام Android ووحدة التحكم الإلكترونية الخارجية. تستخدم هذه الخصائص بروتوكول طلب واستجابة ، حيث يقوم نظام Android بتقديم طلب عن طريق تعيين قيمة خاصية ويستجيب HAL عن طريق إصدار حدث تغيير الخاصية.

ملاحظة: عندما يتم دعم HAL المستخدم، يجب أن تنفذ كافة الخصائص التالية.

خاصية HAL وصف
INITIAL_USER_INFO
(قراءة و كتابة)
يتم استدعاء هذه الخاصية بواسطة نظام Android لتحديد مستخدم Android الذي سيبدأ النظام عند تشغيل الجهاز أو استئنافه من Suspend-to-RAM (STR). عند الاتصال ، يجب أن يستجيب HAL بأحد هذه الخيارات:
  • السلوك الافتراضي الذي حدده Android (التبديل إلى آخر مستخدم مستخدم أو إنشاء مستخدم جديد إذا كان هذا هو التمهيد الأول).
  • قم بالتبديل إلى مستخدم موجود.
  • قم بإنشاء مستخدم جديد (مع الخصائص الاختيارية للاسم والعلامات ولغة النظام وما إلى ذلك) وانتقل إلى هذا المستخدم الجديد.

ملاحظة: إذا لم HAL الاستجابة، السلوك الافتراضي لتنفيذ بعد فترة المهلة (خمس (5) ثانية افتراضيا)، والذي يؤخر التمهيد. إذا ردت طبقة تجريد الأجهزة ، ولكن فشل نظام Android في تنفيذ الإجراء (على سبيل المثال ، إذا تم الوصول إلى الحد الأقصى لعدد المستخدمين) ، فسيتم استخدام السلوك الافتراضي.

على سبيل المثال، افتراضيا، يبدأ نظام أندرويد في العضو النشط الماضي على التمهيد. إذا تم اكتشاف مفتاح فوب لمستخدم مختلف ، فإن وحدة التحكم الإلكترونية تتجاوز خاصية HAL ، وأثناء بدء التشغيل ، يتحول نظام Android ليبدأ في ذلك المستخدم المحدد.

SWITCH_USER
(قراءة و كتابة)
يتم استدعاء هذه الخاصية عند تبديل مستخدم Android الأمامي النشط. يمكن استدعاء الخاصية إما عن طريق نظام Android أو HAL لطلب تبديل المستخدم. تدفقات العمل الثلاثة هي:
  • عصري. التبديل التي من CarUserManager .
  • ميراث. التبديل التي من ActivityManager .
  • مركبة. تم استدعاؤه بواسطة HAL لطلب تبديل مستخدم.

يستخدم سير العمل الحديث نهج الالتزام على مرحلتين لضمان مزامنة نظام Android ووحدة التحكم الإلكترونية الخارجية. عندما يبدأ Android التبديل:

  1. تحقق من HAL لتحديد ما إذا كان يمكن تبديل المستخدم.

    وHAL يستجيب مع SUCCESS أو FAILURE ، بحيث الروبوت يعرف ما إذا كان المضي قدما أم لا.

  2. أكمل مفتاح تبديل مستخدم Android.

    الروبوت يرسل ANDROID_POST_SWITCH ردا على HAL للإشارة إلى نجاح أو فشل التبديل.

ينبغي أن HAL الانتظار حتى بعد ANDROID_POST_SWITCH استجابة لتحديث حالته لمزامنة وحدة نقدية أوروبية أو تحديث خصائص HAL أخرى.

على سبيل المثال، بينما في الحركة، ومحاولات سائق للتبديل المستخدمين الروبوت في واجهة المستخدم والإعلام. ومع ذلك ، نظرًا لأن إعدادات مقعد السيارة مرتبطة بمستخدم Android ، فسوف يتحرك المقعد أثناء تبديل المستخدم. وبالتالي ، فإن وحدة التحكم الإلكترونية التي تتحكم في المقاعد لا تؤكد التبديل ، ويستجيب HAL بفشل ، ولا يتم تبديل مستخدم Android.

سير العمل القديم عبارة عن مكالمة أحادية الاتجاه يتم إرسالها بعد تبديل المستخدم (لذلك لا يمكن لـ HAL حظر المحول). انه دعا فقط في التمهيد (بعد التبديل المستخدم الأولي) أو التطبيقات التي تدعو ActivityManager.switchUser() بدلا من CarUserManager.switchUser() . المرجع Settings و SystemUI تطبيقات بالفعل استخدام هذا الأخير، ولكن إذا توفر OEM إعدادات التطبيقات الخاصة بها لتبديل المستخدمين، يجب أن مصنعي المعدات الأصلية تغيير الاستخدام.

على سبيل المثال، إذا كان التطبيق يستخدم ActivityManager.switchUser() للتبديل المستخدمين، ثم يتم إرسال الدعوة في اتجاه واحد إلى HAL أن نعلمكم بأن التحول العضو قد حدثت.

ينشأ سير عمل السيارة من HAL ، وليس من نظام Android:

  1. يطلب HAL تبديل المستخدم.
  2. يكمل النظام تبديل مستخدم Android.
  3. الروبوت يرسل ANDROID_POST_SWITCH ردا على HAL للإشارة إلى نجاح أو فشل التبديل.

على سبيل المثال، يستخدم بوب مفتاح فوب أليس لفتح السيارة وأجاب HAL إلى INITIAL_USER_INFO الطلب مع أليس هوية المستخدم. بعد ذلك، حدد جهاز استشعار ECU البيومترية السائق وبوب، وبالتالي فإن العضو أرسلت HAL ل SWITCH_USER طلب للمستخدمين التبديل.

CREATE_USER
(قراءة و كتابة)
وتسمى هذه الخاصية عن طريق نظام الروبوت عندما يتم إنشاء العضو الروبوت الجديد (باستخدام CarUserManager.createUser() API).

وHAL يستجيب مع SUCCESS أو FAILURE . إذا استجاب HAL بفشل ، يقوم نظام Android بإزالة المستخدم.

على سبيل المثال، وهو سائق الصنابير رمز والإعلام UI لخلق العضو الروبوت الجديد. يؤدي هذا إلى إرسال طلب إلى HAL وبقية الأنظمة الفرعية للمركبة. يتم إبلاغ وحدات التحكم الإلكترونية بالمستخدم الذي تم إنشاؤه حديثًا. ثم تقوم الأنظمة الفرعية ووحدات التحكم الإلكترونية الأخرى بربط معرف المستخدم الداخلي الخاص بها بمعرف مستخدم Android.

REMOVE_USER
(اكتب فقط)
ويدعو نظام أندرويد هذه الخاصية بعد إزالة على العضو الروبوت (مع CarUserManager.removeUser() API).

هذه مكالمة أحادية الاتجاه - لا يتوقع استجابة من HAL.

على سبيل المثال، وهو سائق الصنابير لإزالة العضو الروبوت الموجودة في واجهة المستخدم والإعلام. يتم إبلاغ HAL ويتم إبلاغ الأنظمة الفرعية للمركبة ووحدات التحكم الإلكترونية الأخرى بإزالة المستخدم حتى يتمكنوا من إزالة معرف المستخدم الداخلي الخاص بهم.

خصائص إضافية

فيما يلي خصائص إضافية غير مرتبطة بحالات دورة حياة المستخدم. يمكن تنفيذ كل منها بدون دعم HAL للمستخدم.

خاصية HAL وصف
USER_IDENTIFICATION_ASSOCIATION
(قراءة و كتابة)
استخدم هذه الخاصية لربط أي مستخدم Android بآلية تعريف ، مثل مفتاح فوب أو هاتف. استخدام هذه الخاصية نفسها إلى get أو set الجمعيات.

على سبيل المثال، وهو سائق الصنابير رمز والإعلام UI لربط سلسلة المفاتيح المستخدمة لفتح السيارة (KEY_123) إلى العضو الروبوت النشط الحالي (USER_11).

مكتبات المساعد

كل الأشياء المستخدمة في الطلب والاستجابة الرسائل (مثل UserInfo ، InitialUserInfoRequest ، InitialUSerInfoResponse ، وهلم جرا) لديها تمثيل على مستوى عال باستخدام C ++ struct ، ولكن يجب بالارض إزالة في القياسية VehiclePropValue الأجسام (انظر الأمثلة أدناه). لسهولة التنمية، و مكتبة المساعد C ++ يتم توفيرها في AOSP لتحويل تلقائيا HAL العضو structs إلى VehiclePropValue (والعكس بالعكس).

أمثلة

INITIAL_USER_INFO

طلب مثال (في التمهيد الأول)

VehiclePropValue { // flattened from InitialUserInfoRequest
prop: 299896583 // INITIAL_USER_INFO
prop.values.int32Values:
 [0] = 1 // Request ID
 [1] = 1 // InitialUserInfoRequestType.FIRST_BOOT
 [2] = 0 // user id of current user
 [3] = 1 // flags of current user (SYSTEM)
 [4] = 1 // number of existing users
 [5] = 0 // existingUser[0].id
 [6] = 1 // existingUser[0].flags
}

مثال على الاستجابة (إنشاء مستخدم مسؤول)

VehiclePropValue { // flattened from InitialUserInfoResponse
prop: 299896583 // INITIAL_USER_INFO
prop.values.int32Values:
  [0] = 1      // Request ID (must match request)
  [1] = 2      // InitialUserInfoResponseAction.CREATE
  [2] = -10000 // user id (not used on CREATE)
  [3] = 8      // user flags (ADMIN)
prop.values.stringValue: "en-US||Car Owner" // User locale and User name
}

تغير المستخدم

يختلف الاسم الفعلي للفئات والخصائص قليلاً ولكن سير العمل الكلي هو نفسه ، كما هو موضح أدناه:

سير العمل

الشكل 1. العضو HAL خصائص سير العمل

مثال طلب سير العمل الحديث

VehiclePropValue { // flattened from SwitchUserRequest
prop: 299896585 // SWITCH_USER
prop.values.int32Values:
 [0]     = 42    // Request ID
 [1]     = 2     // SwitchUserMessageType::ANDROID_SWITCH ("modern")
 [2,3]   = 11,0  // target user id (11) and flags (none in this case)
 [4,5]   = 10,8  // current user id (10) and flags (ADMIN)
 [6]     = 3     // number of existing users (0, 10, 11)
 [7,8]   = 0,1   // existingUser[0] (id=0, flags=SYSTEM)
 [9,10]  = 10,8  // existingUser[1] (id=10, flags=ADMIN)
 [11,12] = 11,0  // existingUser[2] (id=11, flags=NONE)
}

مثال على استجابة سير العمل الحديثة

VehiclePropValue { // flattened from SwitchUserResponse
prop: 299896584 // SWITCH_USER
prop.values.int32Values:
 [0] = 42        // Request ID (must match request)
 [1] = 3         // SwitchUserMessageType::VEHICLE_RESPONSE
 [2] = 1         // SwitchUserStatus::SUCCESS
}

مثال على استجابة ما بعد التبديل لسير العمل الحديث

تحدث هذه الاستجابة عادةً عندما ينجح مفتاح Android:

VehiclePropValue { // flattened from SwitchUserRequest
prop: 299896584 // SWITCH_USER
prop.values.int32Values:
 [0]     = 42    // Request ID (must match "pre"-SWITCH_USER request )
 [1]     = 5     // SwitchUserMessageType::ANDROID_POST_SWITCH
 [2,3]   = 11,0  // target user id (11) and flags (none in this case)
 [4,5]   = 11,0  // current user id (11) and flags (none in this case)
 [6]     = 3     // number of existing users (0, 10, 11)
 [7,8]   = 0,1   // existingUser[0] (id=0, flags=SYSTEM)
 [9,10]  = 10,8  // existingUser[1] (id=10, flags=ADMIN)
 [11,12] = 11,0  // existingUser[2] (id=11, flags=NONE)
}

استجابة ما بعد التبديل الحديثة لسير العمل

تحدث هذه الاستجابة عادةً عندما يفشل مفتاح Android:

VehiclePropValue { // flattened from SwitchUserRequest
prop: 299896584 // SWITCH_USER
prop.values.int32Values:
 [0]     = 42    // Request ID (must match "pre"-SWITCH_USER request )
 [1]     = 5     // SwitchUserMessageType::ANDROID_POST_SWITCH
 [2,3]   = 11,0  // target user id (11) and flags (none in this case)
 [4,5]   = 10,8  // current user id (10) and flags (ADMIN)
 [6]     = 3     // number of existing users (0, 10, 11)
 [7,8]   = 0,1   // existingUser[0] (id=0, flags=SYSTEM)
 [9,10]  = 10,8  // existingUser[1] (id=10, flags=ADMIN)
 [11,12] = 11,0  // existingUser[2] (id=11, flags=NONE)
}

مثال على طلب سير العمل القديم

VehiclePropValue { // flattened from SwitchUserRequest
prop: 299896584 // SWITCH_USER
prop.values.int32Values:
 [0]     = 2     // Request ID
 [1]     = 1     // SwitchUserMessageType::LEGACY_ANDROID_SWITCH
 [2,3]   = 10,8  // target user id (10) and flags (ADMIN)
 [4,5]   = 0,1   // current user id (0) and flags (SYSTEM)
 [6]     = 3     // number of existing users (0, 10, 11)
 [7,8]   = 0,1   // existingUser[0] (id=0, flags=SYSTEM)
 [9,10]  = 10,8  // existingUser[1] (id=10, flags=ADMIN)
 [11,12] = 11,0  // existingUser[2] (id=11, flags=NONE)
}

مثال على طلب سير عمل السيارة

VehiclePropValue { // flattened from SwitchUserRequest
prop: 299896584 // SWITCH_USER
prop.values.int32Values:
 [0]     = -108  // Request ID (must be negative)
 [1]     = 4     // SwitchUserMessageType::VEHICLE_REQUEST
 [2]     = 11    // target user id
}

استجابة ما بعد التبديل القديمة لسير العمل

تحدث هذه الاستجابة عادةً عندما ينجح مفتاح Android:

VehiclePropValue { // flattened from SwitchUserRequest
prop: 299896584 // SWITCH_USER
prop.values.int32Values:
 [0]     = -108  // Request ID (must match from vehicle request )
 [1]     = 5     // SwitchUserMessageType::ANDROID_POST_SWITCH
 [2,3]   = 11,0  // target user id (11) and flags (none in this case)
 [4,5]   = 11,0  // current user id (11) and flags (none in this case)
 [6]     = 3     // number of existing users (0, 10, 11)
 [7,8]   = 0,1   // existingUser[0] (id=0, flags=SYSTEM)
 [9,10]  = 10,8  // existingUser[1] (id=10, flags=ADMIN)
 [11,12] = 11,0  // existingUser[2] (id=11, flags=NONE)
}

CREATE_USER

طلب مثال

VehiclePropValue { // flattened from CreateUserRequest
prop: 299896585 // CREATE_USER
prop.values.int32Values:
 [0]      = 42  // Request ID
 [1,2]    = 11,6     // Android id of the created user and flags (id=11, flags=GUEST, EPHEMERAL)
 [3,4]    = 10,0  // current user id (10) and flags (none in this case)
 [5]      = 3  // number of existing users (0, 10, 11)
 [6,7]    = 0,1   // existingUser[0] (id=0, flags=SYSTEM)
 [8,9]    = 10,8  // existingUser[1] (id=10, flags=ADMIN)
 [10,11] = 11,6 // newUser[2] (id=11, flags=GUEST,EPHEMERAL)
}

مثال على الاستجابة

VehiclePropValue { // flattened from CreateUserResponse
prop: 299896585 // CREATE_USER
prop.values.int32Values:
 [0] = 42        // Request ID (must match request)
 [1] = 3         // CreateUserStatus::SUCCESS
}

REMOVE_USER

طلب مثال

VehiclePropValue { // flattened from RemoveUserRequest
prop: 299896586 // REMOVE_USER
prop.values.int32Values:
 [0]      = 42  // Request ID
 [1,2]    = 11,0     // Android id of the removed user and flags (none in this case)
 [3,4]    = 10,0  // current user id (10) and flags (none in this case)
 [5]      = 2  // number of existing users (0, 10)
 [6,7]    = 0,1   // existingUser[0] (id=0, flags=SYSTEM)
 [8,9]    = 10,8  // existingUser[1] (id=10, flags=ADMIN)
}

USER_IDENTIFICATION_ASSOCIATION

تعيين مثال (مفتاح فوب مرتبط بالمستخدم 10)

VehiclePropValue { // flattened from UserIdentificationSetRequest
prop: 299896587 // USER_IDENTIFICATION_ASSOCIATION
prop.values.int32Values:
 [0]      = 43  // Request ID
 [1,2]    = 10,0     // Android id (10) and flags (none in this case)
 [3]    = 1  // number of associations being set
 [4]      = 1  // 1st type: UserIdentificationAssociationType::KEY_FOB
 [5]    = 1   // 1st value: UserIdentificationAssociationSetValue::ASSOCIATE_CURRENT_USER
}