Layanan plugin OEM mobil baru di Android 14 memungkinkan beberapa komponen mobil untuk dikonfigurasi. Khusus untuk audio, tiga dan layanan plugin akan diperkenalkan, yang memungkinkan OEM pengelolaan audio di perangkat AAOS:
- Kontrol fokus audio
- Volume audio dan kontrol bisukan
- Kontrol Pengecilan volume Audio
Arsitektur layanan plugin mobil
Gambar di bawah memberikan ringkasan layanan mobil dan hubungannya ke layanan mobil OEM. Mirip dengan proses aplikasi dan proses servis mobil, proses servis mobil OEM menggunakan ruang prosesnya sendiri.
Servis mobil memulai servis mobil OEM dengan mencari komponen yang ditentukan di
config_oemCarService. Jika konfigurasi kosong, berarti layanan OEM tidak ada
dan tidak ada layanan yang dimulai. Komponen harus memperluas
OemCarService.
Layanan audio mobil harus menimpa API untuk mendapatkan OEM audio mobil
layanan:
public final class OemCarServiceImp extends OemCarService {
@Override
public OemCarAudioFocusService getOemAudioFocusService();
@Override
public OemCarAudioDuckingService getOemAudioDuckingService();
@Override
public OemCarAudioVolumeService getOemAudioVolumeService();
}
Sebagai
example, lihat
aplikasi pengujian referensi yang ditentukan dalam
packages/services/Car/tests/OemCarServiceTestApp.
Meskipun dimulai oleh servis mobil, layanan ini tidak otomatis
mewarisi izin akses yang
tersedia untuk layanan audio mobil. Dengan demikian, setiap
izin yang diperlukan oleh layanan OEM harus diperoleh dengan
mekanisme atensi. Misalnya, lihat
packages/services/Car/data/etc/com.android.car.oemcarservice.testapp.xml.
Layanan audio mobil dengan arsitektur layanan OEM
Di AAOS, layanan audio mobil mengelola tindakan berikut:
- Pemilihan rute audio
- Fokus audio
- Pengecilan volume audio
- Volume dan bisukan
Sebelum Android 14, perilaku ini sebagian besar bersifat statis dan hanya dapat dimodifikasi melalui pengaturan, meskipun untuk serangkaian kasus yang sangat terbatas. Android 14 memperkenalkan mekanisme untuk audio mobil layanan untuk berkomunikasi dengan komponen yang ditentukan OEM yang mengelola:
- Fokus audio
- Pengecilan volume audio
- Volume dan bisukan
Gambar di bawah ini menunjukkan arsitektur yang disederhanakan untuk layanan audio mobil dan layanan OEM mobil. Layanan audio mobil menentukan berbagai hook yang dapat memanggil layanan audio OEM mobil untuk mengelola perilaku audio. Yang kedua hanya terjadi jika komponen layanan audio mobil OEM yang sesuai ditentukan. Jika tidak, layanan audio mobil menggunakan perilaku default.
Untuk memastikan bahwa layanan audio mobil dan layanan audio OEM mobil selalu aktif untuk setiap panggilan, layanan audio mobil meneruskan bagian yang diperlukan dari status stack audio saat ini ke layanan audio OEM mobil. Misalnya, ketika layanan audio mobil mencegat permintaan untuk mengevaluasi fokus audio, lalu meneruskan status stack saat ini ke layanan audio OEM mobil. Status saat ini mencakup holder fokus saat ini dan yang kehilangan fokus saat ini. Pecundang fokus adalah permintaan fokus yang masih menjadi bagian dari tumpukan tetapi hilang untuk sementara fokus.
Layanan audio mobil harus mengelola semua aktivitas audio di mobil. Jika mobil layanan audio tidak mengelola beberapa bagian perilaku audio, maka informasi yang terekspos ke layanan audio OEM mobil tidak lengkap. Misalnya, jika OEM menimpa penanganan fokus audio di servis mobil dengan mendaftarkan kebijakan fokus audio mereka sendiri, maka layanan audio mobil tidak dapat memberikan informasi ke layanan audio OEM mobil. Hal ini dapat memengaruhi kemampuan mobil Layanan audio OEM untuk membuat keputusan karena mungkin tidak ada informasi yang terlihat ke layanan audio mobil.
Untuk mengambil tindakan, layanan audio mobil memanggil layanan mobil OEM. Panggilan ini dibuat lintas proses, yang membutuhkan komunikasi antarproses (IPC). IPC menambahkan latensi ke setiap panggilan. Anda sebaiknya meminimalkan latensi dalam Layanan OEM.
Karena panggilan layanan audio mobil ke layanan OEM diblokir, layanan OEM tidak boleh memanggil layanan audio mobil pada evaluasi API langsung. Sebagai gantinya, layanan audio mobil menyediakan informasi yang diperlukan sehingga panggilan antara dua proses hanya perlu berpindah dalam satu arah.
Definisi layanan audio mobil OEM
Layanan fokus audio mobil OEM
Layanan audio mobil mengelola permintaan fokus audio dari aplikasi dengan mendaftar pemroses fokus kebijakan audio. Layanan audio mobil memiliki mekanisme untuk mengelola perilaku fokus berdasarkan Matriks interaksi. Matriks tersebut mendefinisikan tiga jenis interaksi yang berbeda:
Interaksi serentak. Holder fokus dapat mempertahankan fokus pada saat yang sama baik.
Interaksi eksklusif. Permintaan fokus yang masuk mengambil fokus dari holder fokus saat ini.
Tolak interaksi. Permintaan fokus masuk ditolak berdasarkan holder fokus saat ini.
Meskipun ini cukup untuk beberapa kasus penggunaan otomotif, hal ini tidak memenuhi semua
kebutuhan interaksi yang mungkin berbeda karena persyaratan OEM. Untuk itu, kita
memperkenalkan OemCarAudioFocusService:
public interface OEmCarAudioFocusService {
OemCarAuddioFocusResults evaluateAudioFocusRequest(
OemCarAudioFocusEvaluationRequest request);
void notifyAudioFocusChange(
List<AudioFocusEntry> holder,
List<AudioFocusEntry> losers, int zoneId);
}
API evaluateAudioFocusRequest dipanggil dari layanan audio mobil kapan saja
ada permintaan untuk fokus audio yang perlu dievaluasi, ini adalah dua cara
API yang memblokir hasil yang ditampilkan. Permintaan berisi informasi
tentang status tumpukan audio saat ini:
Informasi ini dapat digunakan untuk mengevaluasi newFocusRequest dibandingkan dengan
pemegang fokus saat ini di focusHolders dan penurunan fokus saat ini di
focusLosers. API akan menampilkan hasil:
class OemCarAudioFocusResult {
int audioZoneId;
int audioFocusEvaluationResults;
AudioFocusEntry focusResult;
List<AudioFocusEntry> newLosers;
List<AudioFocusEntry> newlyBlocked;
}
Ini berisi informasi tentang hasil evaluasi
yang sebenarnya pada
audioFocusEvaluationResults, yang menunjukkan apakah permintaan saat ini memiliki
diberikan, ditunda, atau gagal. Semua perubahan pada stack fokus saat ini
harus ditetapkan dalam entri newLosers dan newlyBlocked, bergantung pada sifat
dari perubahan {i>stack<i}.
Di mana newLosers berisi entri yang sebelumnya memiliki fokus, tetapi
sekarang akan kehilangan fokus, baik secara permanen maupun sementara. Kehilangan fokus permanen
akan dihapus lebih lanjut dari stack fokus audio, dan kehilangan fokus sementara
akan dipindahkan ke stack pecundang fokus saat ini sampai mereka kembali fokus atau
diabaikan dari pemohon fokus awal. Apa pun itu, pemroses fokus untuk
permintaan akan kehilangan fokus yang sesuai.
Daftar newlyBlocked berisi entri yang sebelumnya berada dalam pecundang fokus
daftar tetapi sekarang diblokir oleh entri baru tersebut. Pemblokiran bisa bersifat permanen atau
sementara, untuk fokus permanen yang diblokir, entri akan dihapus dari stack
dan kehilangan fokus akan dikirim ke pemroses fokus. Untuk kehilangan fokus sementara,
entri akan tetap berada di stack
fokus kehilangan, tetapi ada pemblokir fokus baru yang akan
ditambahkan ke daftar pemblokirnya, tidak ada kehilangan fokus yang akan dikirim seperti sebelumnya
yang dikirim saat pertama kali diblokir. Permintaan akan dibatalkan pemblokirannya saat semua
pemblokir saat ini dihapus, atau akan dihapus dari tumpukan jika fokus
diabaikan.
API kedua, notifyAudioFocusChange, adalah satu cara yang dipanggil di setiap
permintaan fokus audio atau pengabaian. API ini sebagian besar digunakan untuk memberi tahu layanan OEM
perubahan fokus, yang dapat memengaruhi perilaku layanan audio mobil OEM.
Panduan untuk evaluasi fokus
Dalam AAOS, fokus audio digunakan untuk mengelola pemutaran audio dan menentukan aplikasi Anda harus mematuhi kebijakan untuk memberikan pengalaman yang optimal bagi pengguna. Dengan demikian, layanan plugin OEM harus mempertimbangkan hal berikut saat mengelola permintaan fokus audio:
Tanpa fokus audio prioritas tinggi yang sedang berdiri (seperti panggilan telepon, darurat, atau keselamatan) harus bisa mendapatkan fokus audio untuk sementara atau permanen.
Saat fokus media aktif, aplikasi yang meminta:
Fokus penggunaan panggilan, harus dapat menerima fokus secara bersamaan atau secara eksklusif.
Fokus penggunaan navigasi, harus dapat menerima fokus secara serentak atau eksklusif.
Fokus penggunaan Asisten, seharusnya bisa menerima fokus secara serentak atau eksklusif.
Saat berdiri, fokus audio prioritas tinggi (seperti panggilan telepon, keadaan darurat) aplikasi notifikasi, atau notifikasi keamanan) aktif, fokus audio masuk yang tertunda permintaan harus diberikan atau ditunda sesuai kebutuhan.
Meskipun saran di atas tidak lengkap, saran tersebut dapat membantu menjamin bahwa aplikasi yang meminta fokus harus bisa mendapatkan fokus saat tidak ada aktivitas suara prioritas tinggi. Meskipun suara prioritas tinggi aktif, fokus tertunda permintaan data harus tetap dipatuhi dan dapat memperoleh fokus setelah {i>voice stop<i} prioritas tinggi.
Layanan volume mobil OEM
Layanan audio mobil mengelola peristiwa tombol volume dengan cara mendengarkan volume penyesuaian dari sistem audio atau dengan mendengarkan peristiwa tombol volume secara langsung dari layanan input mobil. Dalam setiap kasus, perilaku default mobil layanan audio adalah menentukan grup volume mana yang akan diubah berdasarkan pemutar audio, dan daftar prioritas konteks audio.
Kami memberikan dua daftar prioritas volume. Daftar pertama mempertimbangkan semua aspek konteks tambahan dalam urutan ini. Daftar ini disajikan dalam urutan menurun, yang tertinggi prioritas di bagian atas dan prioritas terendah di bagian bawah. Misalnya, jika audio navigasi dan audio musik keduanya aktif pada saat yang sama, maka volume navigasi berubah selama peristiwa tombol volume.
- Navigasi
- Telepon
- Musik
- Pengumuman
- Perintah suara
- Dering panggilan
- Suara sistem
- Keamanan
- Alarm
- Notifikasi
- Status kendaraan
- Keadaan Darurat
Agar pengelolaan peristiwa kunci volume tidak terlalu rumit, layanan audio mobil memiliki daftar prioritas kedua konteks audio:
- Telepon
- Media
- Pengumuman
- Perintah suara
Daftar ini juga disajikan dalam urutan menurun. Tujuan dari daftar secon ini adalah untuk memungkinkan suara yang lebih umum diubah melalui peristiwa utama. Jarang, mungkin suara dengan durasi lebih pendek, dapat dikelola melalui setelan audio Khusus UI.
Versi volume sebenarnya dapat diatur dengan
Konfigurasi audioVolumeAdjustmentContextsVersion. Konfigurasinya dapat berupa
ditetapkan ke 1 atau 2 (2 adalah default).
Untuk memberikan fleksibilitas yang lebih besar pada pengelolaan volume,
OemCarAudioVolumeService diperkenalkan di Android 14:
public interface OemCarAudioVolumeService {
OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}
Layanan volume audio mobil OEM memiliki satu metode yang menggunakan
volumeAdjustment dan OemCarAudioVolumeRequest:
class OemCarAudioVolumeRequest {
int audioZoneId;
int callState;
List<AudioAttributes> activePlaybackAttributes;
List<AudioAttributes> duckedAttributes;
List<CarVolumeGroupInfo> volumeGroupState;
}
activePlaybackAttributes permintaan memiliki atribut audio yang aktif. Tujuan
duckedAttributes saat ini adalah atribut audio yang saat ini diperkecil. Tujuan
volumeGroupState memiliki status grup volume saat ini. Permintaan
mewakili keadaan tumpukan audio saat ini dan dapat digunakan untuk menentukan
kelompok volume mana yang
harus diubah. Hasilnya harus ditampilkan dalam
OemCarVolumeChangeInfo:
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
Boolean change menunjukkan apakah volume telah berubah, true menunjukkan bahwa
ada perubahan dan grup volume harus diperbarui. Tujuan
volumeGroupChanged adalah grup volume sebenarnya yang harus diubah. Ini
grup harus diubah sesuai dengan parameter volumeAdjustment asli
yang diteruskan ke API. Misalnya, jika hasilnya menunjukkan bahwa navigasi
grup volume harus dibisukan, maka boolean akan menjadi true dan nilai yang ditampilkan
kelompok volume seharusnya seperti itu
untuk navigasi.
Layanan pengecilan volume mobil OEM
Layanan audio mobil mengelola pengecilan volume audio dengan memantau perubahan fokus audio dan
mengirimkan sinyal ke HAL AudioControl tentang perangkat audio mana yang harus dikecilkan.
Saat fokus berubah, semua pemegang fokus aktif dievaluasi untuk menentukan
yang harus diturunkan berdasarkan set pengecilan volume statis ini
aturan:
- Suara darurat mengecilkan semuanya kecuali suara panggilan
- Mengutak-atik semuanya kecuali suara darurat
- Navigasi akan mengatur semuanya kecuali suara keselamatan dan darurat
- Panggilan akan mengurangi semuanya kecuali suara keselamatan, keadaan darurat, dan navigasi
- Suara bebek memanggil bunyi dering
- Musik dan pengumuman harus dikurangi oleh semuanya
Aturan ini tidak lengkap dan OEM tetap bertanggung jawab untuk menentukan
bagaimana suara harus dikecilkan berdasarkan pedoman ini. OEM dapat mengontrol
rekomendasi secara lebih aktif berdasarkan persyaratan yang tersedia. Tujuan
OemCarDuckingService diperkenalkan di Android 14:
class OemCarAudioDuckingService {
List<AudioAttributes> evaluateAttributesToDuck(
OemCarAudioVolumeRequest request);
}
API ini dipanggil dari layanan audio mobil saat fokus audio berubah. Ia menggunakan kembali
OemCarAudioVolumeRequest yang diperkenalkan di
layanan volume mobil OEM, dan berisi informasi
informasi untuk membuat keputusan tentang atribut mana yang harus bebek. Daftar
atribut audio ke bebek dari API akan dibandingkan dengan status audio saat ini:
Atribut audio saat ini dikecilkan:
- Dalam daftar, terus diperkecil
- Tidak ada dalam daftar, fitur pengecilan volume dinonaktifkan
Atribut audio saat ini tidak dikecilkan:
- Dalam daftar, diperkecil
- Tidak ada dalam daftar, fitur pengecilan volume dinonaktifkan
Layanan audio mobil kemudian menentukan perangkat output audio mana yang dan menambahkannya ke daftar perangkat output audio yang diperkecil atau masing-masing daftar perangkat audio yang tidak dikunci. Hal ini pada akhirnya dikirim ke AudioControl HAL untuk menjalankan perlu pengecilan volume di tingkat hardware.
Gambar di bawah menunjukkan diagram urutan yang disederhanakan untuk pengecilan volume audio untuk permintaan fokus saat layanan pengecilan volume OEM digunakan:
Urutan dimulai saat aplikasi meminta
Mengelola fokus audio
melalui API pengelola audio publik. Permintaan diteruskan ke audio mobil
untuk menentukan hasilnya. Saat fokus audio ditentukan, pengecilan volume audio
dievaluasi oleh layanan audio mobil yang memanggil OemCarAudioDuckingService ke
mengevaluasi atribut audio mana yang harus dikecilkan. Setelah hasilnya ditampilkan
dari API evaluateAttributesToDuck, perangkat audio hingga bebek akan dikomputasi,
dan akhirnya informasi dikirim ke AudioControl untuk menerapkan pengecilan volume
ke hardware audio.
Penerapan referensi layanan audio mobil OEM
AAOS menyediakan penerapan referensi layanan mobil OEM dalam
packages/services/Car/tests/OemCarServiceTestApp, yang mengimplementasikan
OemCarService, bersama OemCarAudioFocusService,
OemCarAudioDuckingService, dan OemCarAudioVolumeService. Untuk yang kedua,
yang digunakan setiap layanan, dan file XML untuk memuat perilaku statis. Misalnya,
OemCarAudioFocusServiceImp memuat oem_focus_config.xml, yang
berisi sebuah matriks interaksi. Matriks digunakan untuk mengevaluasi permintaan fokus
saat evaluateAudioFocusRequest dipanggil.
Mereferensikan proses debug aplikasi pengujian
Aplikasi pengujian layanan mobil OEM adalah bagian dari kode sumber AOSP. OEM dapat membuat
berubah sesuai dengan kebutuhan mereka. Untuk proses debug, gunakan config_oemCarService
untuk mengaktifkan aplikasi pengujian.
<!-- This is the component name for the OEM customization service. OEM can choose to implement
this service to customize car service behavior for different policies. If OEMs choose to
implement it, they have to implement a service extending OemCarService exposed by car-lib,
and implement the required component services.
If the component name is invalid, CarService would not connect to any OEM service.
Component name can not be a third party package. It should be pre-installed -->
<string name="config_oemCarService" translatable="false">
com.android.car.oemcarservice.testapp/.OemCarServiceImpl
</string>
Untuk memverifikasi layanan mobil OEM, gunakan perintah dump layanan mobil untuk
Layanan OEM:
adb shell dumpsys car_service --oem-service
Hasilnya dapat mirip dengan output di bawah ini:
***CarOemProxyService dump***
mIsFeatureEnabled: true
mIsOemServiceBound: true
mIsOemServiceReady: true
mIsOemServiceConnected: true
mInitComplete: true
OEM_CAR_SERVICE_CONNECTED_TIMEOUT_MS: 5000
OEM_CAR_SERVICE_READY_TIMEOUT_MS: 5000
mComponentName: com.android.car.oemcarservice.testapp/.OemCarServiceImpl
Setiap boolean di setiap batch info dump menentukan status fitur
dan layanan. Misalnya, info dump mIsOemServiceReady menentukan apakah
layanan siap digunakan, dengan true menunjukkan bahwa layanan sudah siap dan false
menunjukkan bahwa
fungsi tersebut belum siap.