Properti HAL pengguna

Banyak arsitektur kendaraan saat ini yang berisi beberapa unit kontrol elektronik (ECU) di luar sistem infotainmen yang mengontrol ergonomi, seperti kursi dan penyesuaian pencerminan. Berdasarkan hardware dan daya saat ini banyak ECU aktif sebelum sistem infotainmen berbasis Android dinyalakan. ECU ini dapat berinteraksi dengan infotainmen berbasis Android sistem melalui Kendaraan hardware abstraction layer (VHAL).

Mulai Android 11, Android Automotive OS (AAOS) memperkenalkan serangkaian properti pada VHAL untuk membuat, mengalihkan, menghapus, dan mengaitkan aksesori eksternal untuk mengidentifikasi Pengguna. Misalnya, properti baru ini memungkinkan pengemudi untuk menyambungkan aksesori eksternal, seperti fob kunci, ke Pengguna Android mereka. Kemudian, saat pengemudi mendekati kendaraan, ECU akan aktif dan mendeteksi fob kunci. ECU ini menunjukkan kepada HAL yang mana Pengguna Android harus infotainmen memulai booting, yang mengurangi waktu tunggu pengemudi untuk Android Pengguna yang akan dimuat.

Mengaktifkan HAL Pengguna

Properti HAL Pengguna harus diaktifkan secara eksplisit dengan memastikan bahwa properti android.car.user_hal_enabled disetel ke true. (Hal ini juga dapat dilakukan di file car.mk, sehingga tidak perlu diatur secara manual.) Pastikan user_hal_enabled=true diaktifkan oleh 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 hal berikut ditampilkan saat system_server dimulai:

I CarServiceHelper: Not using User HAL

Untuk mengaktifkan user_hal_enabled secara manual, setel atribut 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 akan muncul seperti 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 proses pengguna

Properti berikut memberikan informasi HAL untuk Siklus proses pengguna status, yang memungkinkan sinkronisasi siklus proses Pengguna antara sistem Android dan ECU eksternal. Properti ini menggunakan protokol permintaan dan respons, pada sistem Android membuat permintaan dengan menyetel nilai properti dan HAL merespons dengan mengeluarkan peristiwa perubahan properti.

Catatan: Saat User HAL didukung, semua hal berikut properti harus diterapkan.

Properti HAL Deskripsi
INITIAL_USER_INFO
(BACA/TULIS)
Properti ini dipanggil oleh sistem Android untuk menentukan Android mana Pengguna, sistem dimulai ketika perangkat melakukan booting atau melanjutkan dari Suspend-to-RAM (STR). Ketika dipanggil, HAL harus merespons dengan salah satu opsi berikut:
  • Perilaku default yang disetel oleh Android (beralih ke perilaku default yang terakhir digunakan atau membuat Pengguna baru jika ini adalah booting pertama).
  • Beralih ke Pengguna yang sudah ada.
  • Buat Pengguna baru (dengan properti opsional berupa nama, tanda, sistem lokal, dan sebagainya) dan beralih ke Pengguna baru.

Catatan: Jika HAL tidak merespons, perilaku defaultnya adalah mengeksekusi setelah periode waktu tunggu (lima detik secara {i>default<i}), yang menunda {i>booting<i}. Jika HAL membalas, tetapi sistem Android gagal mengeksekusi tindakan tersebut (misalnya, jika jumlah maksimum Pengguna telah tercapai), perilaku default akan digunakan.

Contoh: Secara default, sistem Android dimulai dalam {i>active user<i} pada saat {i>booting<i}. Jika fob kunci untuk Pengguna yang berbeda terdeteksi, ECU mengganti properti HAL dan, selama startup, sistem Android beralih untuk pengguna tertentu.

SWITCH_USER
(BACA/TULIS)
Properti ini dipanggil saat mengalihkan Pengguna Android latar depan yang aktif. Properti bisa dipanggil baik oleh sistem Android atau oleh HAL untuk meminta pengalihan Pengguna. Tiga alur kerja tersebut adalah:
  • Modern. Pengalihan dimulai dari CarUserManager.
  • Lama. Pengalihan dimulai dari ActivityManager.
  • Kendaraan. Dipanggil oleh HAL untuk meminta pengalihan Pengguna.

Alur kerja Modern menggunakan pendekatan commit dua fase untuk memastikan Sistem Android dan ECU eksternal disinkronkan. Saat Android memulai pengalihan:

  1. Periksa HAL untuk menentukan apakah Pengguna dapat dialihkan.

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

  2. Selesaikan peralihan Pengguna Android.

    Android mengirim respons ANDROID_POST_SWITCH ke HAL untuk menunjukkan keberhasilan atau kegagalan switch.

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

Contoh: Saat bergerak, pengemudi mencoba mengalihkan Pengguna Android di UI infotainmen. Namun, karena kursi mobil setelan dikaitkan dengan Pengguna Android, kursi akan bergerak selama Peralihan pengguna. Jadi, ECU yang mengendalikan kursi tidak mengonfirmasi saklar, HAL merespons dengan kegagalan, dan Pengguna Android tidak dialihkan.

Alur kerja Lama adalah panggilan satu arah yang dikirim setelah Pengguna dialihkan (sehingga HAL tidak bisa memblokir switch). Fungsi ini hanya dipanggil saat {i>booting<i} (setelah peralihan pengguna awal) atau untuk aplikasi yang memanggil ActivityManager.switchUser(), bukan CarUserManager.switchUser(). Referensi Aplikasi Settings dan SystemUI sudah menggunakan tetapi jika OEM menyediakan aplikasi Setelannya sendiri untuk mengalihkan Pengguna, Penggunaannya harus diubah oleh OEM.

Contoh: Jika aplikasi menggunakan ActivityManager.switchUser() ke {i>switch<i}, maka panggilan satu arah dikirim ke HAL untuk menginformasikan bahwa {i>switch<i} telah dilakukan.

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

  1. HAL meminta pengalihan Pengguna.
  2. Sistem menyelesaikan peralihan Pengguna Android.
  3. Android mengirimkan respons ANDROID_POST_SWITCH ke HAL untuk menunjukkan berhasil atau gagal saat peralihan.

Contoh: Bob menggunakan fob kunci Alia untuk membuka mobil dan HAL membalas permintaan INITIAL_USER_INFO dengan ID Pengguna Alice. Selanjutnya, ECU sensor biometrik mengidentifikasi pengemudi sebagai Bob, jadi HAL Pengguna mengirim permintaan SWITCH_USER untuk mengalihkan pengguna.

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

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

Contoh: Pengemudi mengetuk ikon UI infotainmen untuk membuat Pengguna Android baru. Ini mengirimkan permintaan ke HAL dan sisanya dari subsistem kendaraan. ECU diberi tahu tentang Pengguna yang baru dibuat. Yang lain subsistem dan ECU kemudian mengaitkan ID pengguna internalnya dengan sistem User-ID.

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

Ini adalah panggilan satu arah — tidak ada respons yang diharapkan dari HAL.

Contoh: Pengemudi mengetuk untuk menghapus kendaraan yang ada Pengguna Android di UI infotainmen. HAL diberi tahu dan hal lainnya subsistem kendaraan dan ECU diinformasikan tentang penghapusan Pengguna sehingga mereka dapat menghapus ID pengguna internalnya.

Properti tambahan

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

Properti HAL Deskripsi
USER_IDENTIFICATION_ASSOCIATION
(BACA/TULIS)
Gunakan properti ini untuk mengaitkan Pengguna Android dengan identifikasi mekanisme, seperti fob kunci atau ponsel. Gunakan properti yang sama ini untuk Pengaitan get atau set.

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

Library helper

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

Contoh

Info IniTIAL_USER_INFO

Contoh permintaan (saat booting 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
}

BERALIH_PENGGUNA

Nama sebenarnya dari class dan properti sedikit berbeda tetapi 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 saat pengalihan 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 saat kegagalan switch 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)
}

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 pascaperalihan alur kerja lama

Respons ini biasanya terjadi saat pengalihan 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)
}

CREATE_USER

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_PENGGUNA

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

Contoh yang ditetapkan (fob kunci 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
}