Properti HAL pengguna

Banyak arsitektur kendaraan saat ini berisi beberapa unit kontrol elektronik (ECU) di luar sistem infotainment yang mengontrol ergonomi, seperti pengaturan kursi dan penyesuaian kaca spion. Berdasarkan arsitektur perangkat keras dan daya saat ini, banyak ECU yang menyala sebelum sistem infotainment berbasis Android menyala. ECU ini dapat berinteraksi dengan sistem infotainment berbasis Android melalui lapisan abstraksi perangkat keras Kendaraan (VHAL) .

Mulai Android 11, Android Automotive OS (AAOS) memperkenalkan serangkaian properti baru di VHAL untuk membuat, mengganti, menghapus, dan mengaitkan aksesori eksternal untuk mengidentifikasi Pengguna. Misalnya, properti baru ini memungkinkan pengemudi untuk memasangkan aksesori eksternal, seperti key fob, ke Pengguna Android mereka. Kemudian, ketika pengemudi mendekati kendaraan, ECU akan aktif dan mendeteksi key fob. ECU ini menunjukkan kepada HAL Pengguna Android mana yang harus memulai booting infotainmen, sehingga mengurangi waktu pengemudi menunggu Pengguna Android mereka memuat.

Aktifkan Pengguna HAL

Properti User HAL harus diaktifkan secara eksplisit dengan memastikan properti sistem android.car.user_hal_enabled disetel ke true . (Hal ini juga dapat dilakukan pada file car.mk , sehingga tidak perlu diatur secara manual.) Periksa apakah user_hal_enabled=true diaktifkan dengan membuang UserHalService :

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

Anda juga dapat memeriksa user_hal_enabled dengan menggunakan adb shell getprop android.car.user_hal_enabled atau adb logcat CarServiceHelper *:s . Jika properti dinonaktifkan, pesan seperti berikut ini ditampilkan ketika system_server dimulai:

I CarServiceHelper: Not using User HAL

Untuk mengaktifkan user_hal_enabled secara manual, setel properti sistem android.car.user_hal_enabled dan mulai ulang system_server :

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

Output logcat muncul sebagai berikut:

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

Properti HAL pengguna

Properti siklus hidup pengguna

Properti berikut menyediakan informasi HAL untuk status siklus hidup Pengguna, yang memungkinkan sinkronisasi siklus hidup Pengguna antara sistem Android dan ECU eksternal. Properti ini menggunakan protokol permintaan dan respons, yang mana sistem Android membuat permintaan dengan menetapkan nilai properti dan HAL merespons dengan mengeluarkan peristiwa perubahan properti.

Catatan: Jika HAL Pengguna didukung, semua properti berikut harus diterapkan.

properti HAL Keterangan
INITIAL_USER_INFO
(BACA TULIS)
Properti ini dipanggil oleh sistem Android untuk menentukan Pengguna Android mana yang memulai sistem saat perangkat melakukan booting atau melanjutkan dari Suspend-to-RAM (STR). Saat dipanggil, HAL harus merespons dengan salah satu opsi berikut:
  • Perilaku default yang ditetapkan oleh Android (beralih ke Pengguna yang terakhir digunakan atau membuat Pengguna baru jika ini adalah boot pertama).
  • Beralih ke Pengguna yang sudah ada.
  • Buat Pengguna baru (dengan properti opsional berupa nama, bendera, lokal sistem, dan sebagainya) dan beralih ke Pengguna baru tersebut.

Catatan: Jika HAL tidak merespons, perilaku defaultnya adalah mengeksekusi setelah periode waktu habis (secara default lima detik), yang akan menunda booting. Jika HAL membalas, namun sistem Android gagal menjalankan tindakan (misalnya, jika jumlah maksimum Pengguna telah tercapai), perilaku default akan digunakan.

Contoh: Secara default, sistem Android dimulai pada Pengguna aktif terakhir saat boot. Jika key fob untuk Pengguna berbeda terdeteksi, ECU akan mengambil alih properti HAL dan, selama start-up, sistem Android beralih untuk memulai pada Pengguna yang ditentukan tersebut.

SWITCH_USER
(BACA TULIS)
Properti ini dipanggil saat mengganti Pengguna Android latar depan yang aktif. Properti dapat dipanggil oleh sistem Android atau HAL untuk meminta peralihan Pengguna. Ketiga alur kerja tersebut adalah:
  • Modern. Peralihan dimulai dari CarUserManager .
  • Warisan. Peralihan dimulai dari ActivityManager .
  • Kendaraan. Dipanggil oleh HAL untuk meminta peralihan Pengguna.

Alur kerja Modern menggunakan pendekatan penerapan dua fase untuk memastikan sistem Android dan ECU eksternal disinkronkan. Saat Android memulai peralihan:

  1. Periksa HAL untuk menentukan apakah Pengguna dapat dialihkan.

    HAL merespon dengan SUCCESS atau FAILURE , sehingga Android tahu apakah akan melanjutkan atau tidak.

  2. Selesaikan sakelar Pengguna Android.

    Android mengirimkan respons ANDROID_POST_SWITCH ke HAL untuk menunjukkan keberhasilan atau kegagalan peralihan.

HAL harus menunggu hingga respons ANDROID_POST_SWITCH memperbarui statusnya untuk menyinkronkan ECU atau memperbarui properti HAL lainnya.

Contoh: Saat sedang bergerak, pengemudi mencoba mengganti Pengguna Android di UI infotainmen. Namun, karena pengaturan kursi mobil terikat pada Pengguna Android, kursi tersebut berpindah selama peralihan Pengguna. Oleh karena itu, ECU yang mengontrol kursi tidak mengkonfirmasi peralihan, HAL merespons dengan kegagalan, dan Pengguna Android tidak beralih.

Alur kerja Warisan adalah panggilan satu arah yang dikirim setelah Pengguna dialihkan (sehingga HAL tidak dapat memblokir peralihan). Ini hanya dipanggil saat boot (setelah peralihan pengguna awal) atau untuk aplikasi yang memanggil ActivityManager.switchUser() alih-alih CarUserManager.switchUser() . Referensi Settings dan aplikasi SystemUI sudah menggunakan yang terakhir, tetapi jika OEM menyediakan aplikasi Pengaturan mereka sendiri untuk berpindah Pengguna, OEM harus mengubah penggunaannya.

Contoh: Jika aplikasi menggunakan ActivityManager.switchUser() untuk mengganti Pengguna, maka panggilan satu arah akan dikirim ke HAL untuk menginformasikan bahwa peralihan Pengguna telah terjadi.

Alur kerja Kendaraan berasal dari HAL, bukan dari sistem Android:

  1. HAL meminta saklar Pengguna.
  2. Sistem menyelesaikan peralihan Pengguna Android.
  3. Android mengirimkan respons ANDROID_POST_SWITCH ke HAL untuk menunjukkan keberhasilan atau kegagalan peralihan.

Contoh: Bob menggunakan key fob Alice untuk membuka mobil dan HAL membalas permintaan INITIAL_USER_INFO dengan ID Pengguna Alice. Selanjutnya, ECU sensor biometrik mengidentifikasi pengemudi sebagai Bob, sehingga Pengguna HAL mengirimkan permintaan SWITCH_USER untuk berpindah pengguna.

CREATE_USER
(BACA TULIS)
Properti ini dipanggil oleh sistem Android ketika Pengguna Android baru dibuat (menggunakan API CarUserManager.createUser() ).

HAL merespons dengan SUCCESS atau FAILURE . Jika HAL merespons dengan kegagalan, sistem Android menghapus Pengguna.

Contoh: Pengemudi mengetuk ikon UI infotainment untuk membuat Pengguna Android baru. Ini mengirimkan permintaan ke HAL dan subsistem kendaraan lainnya. ECU diberitahu tentang Pengguna yang baru dibuat. Subsistem dan ECU lain kemudian mengaitkan ID pengguna internalnya dengan ID Pengguna Android.

REMOVE_USER
(hanya TULIS)
Sistem Android memanggil properti ini setelah Pengguna Android dihapus (dengan metode CarUserManager.removeUser() ).

Ini adalah panggilan satu arah – tidak ada tanggapan yang diharapkan dari HAL.

Contoh: Pengemudi mengetuk untuk menghapus Pengguna Android yang ada di UI infotainmen. HAL diberitahu dan subsistem kendaraan lain serta ECU diberitahu tentang penghapusan Pengguna sehingga mereka dapat menghapus ID pengguna internal mereka.

Properti tambahan

Berikut ini adalah properti tambahan, yang tidak terkait dengan status siklus hidup Pengguna. Masing-masing dapat diimplementasikan tanpa mendukung Pengguna HAL.

Properti HAL Keterangan
USER_IDENTIFICATION_ASSOCIATION
(BACA TULIS)
Gunakan properti ini untuk mengaitkan Pengguna Android mana pun dengan mekanisme identifikasi, seperti key fob atau telepon. Gunakan properti yang sama untuk get atau set pengaitan.

Contoh: Pengemudi mengetuk ikon UI infotainment untuk mengaitkan key fob yang digunakan untuk membuka kendaraan ( KEY_123 ) dengan Pengguna Android yang aktif saat ini ( USER_11 ).

Perpustakaan pembantu

Semua objek yang digunakan dalam pesan permintaan dan respons (seperti UserInfo , InitialUserInfoRequest , InitialUSerInfoResponse , dan seterusnya) memiliki representasi tingkat tinggi menggunakan struct C++, namun penghapusan harus diratakan ke dalam objek VehiclePropValue standar (lihat contoh di bawah). Untuk kemudahan pengembangan, pustaka pembantu C++ disediakan di AOSP untuk secara otomatis mengubah structs HAL Pengguna menjadi VehiclePropValue (dan sebaliknya).

Contoh

INITIAL_USER_INFO

Contoh permintaan (pada boot pertama)

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
}

Contoh respons (buat pengguna Admin)

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
}

SWITCH_USER

Nama sebenarnya dari kelas dan properti sedikit berbeda tetapi alur kerjanya secara keseluruhan sama, seperti yang diilustrasikan di bawah ini:

Alur kerja

Gambar 1. Alur Kerja Properti HAL Pengguna

Contoh permintaan alur kerja modern

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)
}

Contoh respons alur kerja modern

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
}

Contoh respons pasca-peralihan alur kerja modern

Respons ini biasanya terjadi ketika peralihan Android berhasil:

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)
}

Respons pasca-peralihan alur kerja modern

Respons ini biasanya terjadi ketika saklar Android gagal:

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)
}

Contoh permintaan alur kerja lama

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)
}

Contoh permintaan alur kerja kendaraan

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
}

Respons pasca-peralihan alur kerja lama

Respons ini biasanya terjadi ketika peralihan Android berhasil:

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)
}

BUAT PENGGUNA

Contoh permintaan

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)
}

Contoh respons

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

HAPUS_USER

Contoh permintaan

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

Tetapkan contoh (key fob yang terkait dengan Pengguna 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
}