Layanan plugin OEM mobil baru di Android 14 memungkinkan beberapa komponen mobil dikonfigurasi. Khusus untuk audio, tiga layanan plugin baru diperkenalkan, yang memungkinkan OEM mengonfigurasi pengelolaan audio secara fleksibel di perangkat AAOS:
- Kontrol fokus audio
- Kontrol volume dan bisukan audio
- Kontrol Pengecilan Volume Audio
Arsitektur layanan plugin mobil
Gambar di bawah memberikan ringkasan layanan mobil dan hubungannya dengan layanan mobil OEM. Mirip dengan proses aplikasi dan proses layanan mobil, proses layanan mobil OEM menempati ruang prosesnya sendiri.
Layanan mobil memulai layanan mobil OEM dengan menemukan komponen yang ditentukan dalam
config_oemCarService. Jika config kosong, layanan OEM tidak ada
dan tidak ada layanan yang dimulai. Komponen harus memperluas
OemCarService.
Layanan audio mobil harus mengganti API untuk mendapatkan layanan OEM audio mobil:
public final class OemCarServiceImp extends OemCarService {
@Override
public OemCarAudioFocusService getOemAudioFocusService();
@Override
public OemCarAudioDuckingService getOemAudioDuckingService();
@Override
public OemCarAudioVolumeService getOemAudioVolumeService();
}
Sebagai
contoh, lihat
aplikasi pengujian referensi yang ditentukan dalam
packages/services/Car/tests/OemCarServiceTestApp.
Meskipun layanan dimulai oleh layanan mobil, layanan tersebut tidak otomatis
mewarisi izin yang tersedia untuk layanan audio mobil. Oleh karena itu, setiap izin yang diperlukan oleh layanan OEM harus diperoleh dengan mekanisme yang tepat. 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 bisu
Sebelum Android 14, perilaku ini sebagian besar bersifat statis dan hanya dapat diubah melalui setelan, meskipun untuk serangkaian kasus yang sangat terbatas. Android 14 memperkenalkan mekanisme bagi layanan audio mobil untuk berkomunikasi dengan komponen yang ditentukan OEM yang mengelola:
- Fokus audio
- Pengecilan volume audio
- Volume dan bisu
Gambar di bawah 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 terakhir hanya terjadi jika komponen layanan audio mobil OEM yang sesuai ditentukan. Jika tidak, layanan audio mobil akan menggunakan perilaku default.
Untuk memastikan layanan audio mobil dan layanan audio OEM mobil selalu disinkronkan, untuk setiap panggilan, layanan audio mobil meneruskan bagian yang diperlukan dari status stack audio saat ini ke layanan audio OEM mobil. Misalnya, saat layanan audio mobil mencegat permintaan untuk mengevaluasi fokus audio, layanan tersebut akan meneruskan status stack saat ini ke layanan audio OEM mobil. Status saat ini mencakup pemegang fokus saat ini dan elemen yang kehilangan fokus saat ini. Pelepas fokus adalah permintaan fokus yang masih menjadi bagian dari stack, tetapi telah kehilangan fokus untuk sementara.
Layanan audio mobil harus mengelola semua aktivitas audio di mobil. Jika layanan audio mobil tidak mengelola beberapa bagian perilaku audio, informasi yang diekspos ke layanan audio OEM mobil tidak lengkap. Misalnya, jika OEM mengganti penanganan fokus audio di layanan mobil dengan mendaftarkan kebijakan fokus audio mereka sendiri, layanan audio mobil tidak dapat memberikan informasi lengkap ke layanan audio OEM mobil. Hal ini dapat memengaruhi kemampuan layanan audio OEM mobil dalam membuat keputusan karena mungkin tidak memiliki informasi yang tidak terlihat oleh layanan audio mobil.
Untuk melakukan tindakan, layanan audio mobil memanggil layanan mobil OEM. Panggilan ini dilakukan di seluruh proses, yang memerlukan komunikasi antarproses (IPC). IPC menambahkan latensi ke setiap panggilan. Penting untuk meminimalkan latensi di layanan OEM.
Karena panggilan layanan audio mobil ke layanan OEM bersifat memblokir, layanan OEM tidak boleh memanggil layanan audio mobil pada evaluasi API langsung. Sebagai gantinya, layanan audio mobil memberikan informasi yang diperlukan sehingga panggilan antara dua proses hanya perlu berjalan dalam satu arah.
Definisi layanan audio mobil OEM
Layanan fokus audio mobil OEM
Layanan audio mobil mengelola permintaan fokus audio dari aplikasi dengan mendaftarkan pemroses fokus kebijakan audio. Layanan audio mobil memiliki mekanisme untuk mengelola perilaku fokus berdasarkan Matriks interaksi statis. Matriks ini menentukan tiga jenis interaksi yang berbeda:
Interaksi serentak. Pemegang fokus dapat mempertahankan fokus secara bersamaan.
Interaksi eksklusif. Permintaan fokus yang masuk mengambil fokus dari pemegang fokus saat ini.
Menolak interaksi. Permintaan fokus masuk ditolak berdasarkan pemegang fokus saat ini.
Meskipun cukup untuk beberapa kasus penggunaan otomotif, hal ini tidak memenuhi semua kebutuhan interaksi yang mungkin berbeda karena persyaratan OEM. Untuk itu, kami 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 setiap kali ada permintaan fokus audio yang perlu dievaluasi. API ini adalah API dua arah yang memblokir hasil yang akan ditampilkan. Permintaan berisi informasi tentang status stack audio saat ini:
Informasi ini dapat digunakan untuk mengevaluasi newFocusRequest dibandingkan dengan pemegang fokus saat ini di focusHolders dan yang kehilangan fokus saat ini di focusLosers. API akan menampilkan hasilnya:
class OemCarAudioFocusResult {
int audioZoneId;
int audioFocusEvaluationResults;
AudioFocusEntry focusResult;
List<AudioFocusEntry> newLosers;
List<AudioFocusEntry> newlyBlocked;
}
Objek ini berisi informasi tentang hasil evaluasi sebenarnya dalam
audioFocusEvaluationResults, yang menunjukkan apakah permintaan saat ini telah
diberikan, ditunda, atau gagal. Setiap perubahan pada stack fokus saat ini
harus ditetapkan dalam entri newLosers dan newlyBlocked, bergantung pada sifat
perubahan stack.
Tempat newLosers berisi entri yang sebelumnya memegang fokus, tetapi
sekarang harus kehilangan fokus, baik secara permanen maupun sementara. Pihak yang kehilangan fokus permanen
akan dikeluarkan lebih lanjut dari stack fokus audio, dan pihak yang kehilangan fokus sementara
akan dipindahkan ke stack pihak yang kehilangan fokus saat ini hingga mereka mendapatkan kembali fokus atau
ditinggalkan dari pemohon fokus asli. Terlepas dari itu, pemroses fokus untuk
permintaan akan menerima fokus yang hilang yang sesuai.
Daftar newlyBlocked berisi entri yang sebelumnya ada dalam daftar
kehilangan fokus, tetapi sekarang diblokir oleh entri baru. Pemblokiran dapat bersifat permanen atau sementara. Untuk pemblokiran fokus permanen, entri akan dihapus dari stack dan kehilangan fokus akan dikirim ke pemroses fokus. Untuk kehilangan fokus sementara,
entri akan tetap berada di stack kehilangan fokus, tetapi pemblokir fokus baru akan
ditambahkan ke daftar pemblokirnya, tidak ada kehilangan fokus yang akan dikirim karena sebelumnya
dikirim saat pertama kali diblokir. Permintaan akhirnya akan dibuka blokirnya saat semua pemblokir saat ini dihapus, atau akan dihapus dari stack jika fokus ditinggalkan.
API kedua, notifyAudioFocusChange, adalah satu arah yang dipanggil pada setiap
permintaan atau pelepasan fokus audio. API ini sebagian besar digunakan untuk memberi tahu layanan OEM tentang perubahan fokus, yang dapat memengaruhi perilaku layanan audio mobil OEM.
Pedoman untuk evaluasi fokus
Di AAOS, fokus audio digunakan untuk mengelola pemutaran audio dan menentukan aplikasi mana yang harus dipatuhi untuk memberikan pengalaman yang optimal bagi pengguna. Oleh karena itu, layanan plugin OEM harus mempertimbangkan hal berikut saat mengelola permintaan fokus audio:
Tanpa fokus audio prioritas tinggi yang sedang berlangsung (seperti panggilan telepon, darurat, atau keselamatan), aplikasi harus dapat memperoleh fokus audio baik secara sementara maupun permanen.
Saat fokus media aktif, aplikasi yang meminta:
Fokus penggunaan panggilan, harus dapat menerima fokus secara bersamaan atau eksklusif.
Fokus penggunaan navigasi, harus dapat menerima fokus secara bersamaan atau eksklusif.
Fokus penggunaan Asisten, harus dapat menerima fokus secara bersamaan atau eksklusif.
Saat aplikasi fokus audio berprioritas tinggi (seperti panggilan telepon, peringatan darurat, atau peringatan keselamatan) aktif, setiap permintaan fokus audio tertunda yang masuk harus diberikan atau ditunda sesuai kebutuhan.
Meskipun saran di atas tidak lengkap, saran tersebut dapat membantu memastikan bahwa aplikasi yang meminta fokus akan dapat memperoleh fokus saat tidak ada suara prioritas tinggi yang aktif. Meskipun suara berprioritas tinggi aktif, permintaan fokus yang tertunda harus tetap dipatuhi dan harus dapat memperoleh fokus setelah suara berprioritas tinggi berhenti.
Layanan volume mobil OEM
Layanan audio mobil mengelola peristiwa tombol volume dengan memproses penyesuaian volume dari sistem audio atau dengan memproses peristiwa tombol volume langsung dari layanan input mobil. Dalam setiap kasus, perilaku default layanan audio mobil adalah menentukan grup volume mana yang akan diubah berdasarkan pemutar audio aktif dan daftar prioritas konteks audio.
Kami menyediakan dua daftar prioritas volume. Daftar pertama mempertimbangkan semua konteks audio dalam urutan ini. Daftar ini ditampilkan dalam urutan menurun, prioritas tertinggi di bagian atas dan prioritas terendah di bagian bawah. Misalnya, jika audio navigasi dan audio musik aktif secara bersamaan, maka volume navigasi akan berubah selama peristiwa tombol volume.
- Navigasi
- Telepon
- Musik
- Pengumuman
- Perintah suara
- Dering panggilan
- Suara sistem
- Keamanan
- Alarm
- Notifikasi
- Status kendaraan
- Keadaan Darurat
Untuk membuat pengelolaan peristiwa tombol 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 daftar kedua ini adalah memungkinkan suara yang lebih umum diubah melalui peristiwa utama. Tidak umum, mungkin suara dengan durasi yang lebih singkat, hanya dapat dikelola melalui UI setelan audio.
Versi sebenarnya dari volume dapat ditetapkan dengan konfigurasi
audioVolumeAdjustmentContextsVersion. Konfigurasi dapat
disetel 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 menerima
volumeAdjustment dan OemCarAudioVolumeRequest:
class OemCarAudioVolumeRequest {
int audioZoneId;
int callState;
List<AudioAttributes> activePlaybackAttributes;
List<AudioAttributes> duckedAttributes;
List<CarVolumeGroupInfo> volumeGroupState;
}
activePlaybackAttributes permintaan memiliki atribut audio aktif. duckedAttributes adalah semua atribut audio yang saat ini diredam. volumeGroupState
memiliki status grup volume saat ini. Permintaan
mewakili status stack audio saat ini dan dapat digunakan untuk menentukan
grup volume mana yang harus diubah. Hasil harus ditampilkan dalam
OemCarVolumeChangeInfo:
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
Boolean change menunjukkan apakah ada volume yang berubah, true menunjukkan bahwa
ada perubahan dan grup volume harus diperbarui. volumeGroupChanged adalah grup volume sebenarnya yang harus diubah. Grup
ini harus diubah sesuai dengan parameter volumeAdjustment asli
yang diteruskan ke API. Misalnya, jika hasilnya menunjukkan bahwa grup volume navigasi harus disetel ke senyap, maka booleannya adalah true dan grup volume yang ditampilkan harus untuk navigasi.
Layanan OEM mobil
Layanan audio mobil mengelola peredaman audio dengan memantau perubahan fokus audio dan
mengirim sinyal ke HAL AudioControl tentang perangkat audio mana yang harus diredam.
Saat fokus berubah, semua pemegang fokus aktif dievaluasi untuk menentukan
mana yang harus diredam berdasarkan kumpulan aturan peredaman statis
ini:
- Suara darurat meredam semua suara kecuali suara panggilan
- Perlindungan meredam semua suara kecuali suara darurat
- Navigasi meredam semua suara kecuali suara keselamatan dan darurat
- Call duck mematikan semua suara kecuali suara keselamatan, darurat, dan navigasi
- Voice meredam suara dering panggilan
- Musik dan pengumuman harus dikecilkan oleh semuanya
Aturan ini tidak lengkap dan OEM tetap bertanggung jawab untuk menentukan cara audio harus dikecilkan berdasarkan panduan ini. OEM dapat mengontrol rekomendasi ini secara lebih aktif berdasarkan persyaratan yang tersedia. OemCarDuckingService diperkenalkan di Android 14:
class OemCarAudioDuckingService {
List<AudioAttributes> evaluateAttributesToDuck(
OemCarAudioVolumeRequest request);
}
API ini dipanggil dari layanan audio mobil saat terjadi perubahan fokus audio. Menggunakan kembali
OemCarAudioVolumeRequest yang diperkenalkan di
layanan volume mobil OEM, dan berisi informasi yang relevan untuk membuat keputusan tentang atribut mana yang akan disembunyikan. Daftar atribut audio yang akan di-duck dari API dibandingkan dengan status audio saat ini:
Atribut audio yang saat ini diredam:
- Dalam daftar, terus dihindari
- Tidak ada dalam daftar, merunduk dinonaktifkan
Atribut audio saat ini tidak diredam:
- Dalam daftar, dikecilkan
- Tidak ada dalam daftar, merunduk dinonaktifkan
Layanan audio mobil kemudian menentukan perangkat output audio mana yang memiliki atribut audio dan menambahkannya ke daftar perangkat output audio yang di-ducking atau daftar perangkat audio yang tidak di-ducking. Pada akhirnya, perintah ini dikirim ke HAL AudioControl untuk melakukan perintah ducking yang diperlukan di tingkat hardware.
Gambar di bawah menunjukkan diagram urutan yang disederhanakan dari kontrol peredaman audio untuk permintaan fokus saat layanan peredaman OEM digunakan:
Urutan dimulai saat aplikasi meminta
Kelola fokus audio
melalui API pengelola audio publik. Permintaan diteruskan ke layanan audio mobil untuk menentukan hasilnya. Saat fokus audio diputuskan, peredaman audio
dievaluasi oleh layanan audio mobil yang memanggil OemCarAudioDuckingService untuk
mengevaluasi atribut audio mana yang harus diredam. Setelah hasil ditampilkan dari evaluateAttributesToDuck API, perangkat audio yang harus dikecilkan volumenya akan dihitung, dan akhirnya informasi dikirim ke AudioControl untuk menerapkan pengecilan volume ke hardware audio.
Implementasi referensi layanan audio mobil OEM
AAOS menyediakan penerapan referensi layanan mobil OEM di
packages/services/Car/tests/OemCarServiceTestApp, yang menerapkan
OemCarService, bersama dengan OemCarAudioFocusService,
OemCarAudioDuckingService, dan OemCarAudioVolumeService. Untuk yang terakhir,
setiap layanan menggunakan file XML untuk memuat perilaku statis. Misalnya,
OemCarAudioFocusServiceImp memuat oem_focus_config.xml, yang
berisi matriks interaksi. Matriks digunakan untuk mengevaluasi permintaan fokus
saat evaluateAudioFocusRequest dipanggil.
Proses debug aplikasi pengujian referensi
Aplikasi pengujian layanan mobil OEM adalah bagian dari kode sumber AOSP. OEM dapat melakukan perubahan sesuai kebutuhan mereka. Untuk proses debug, gunakan konfigurasi 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 bahwa layanan mobil OEM menggunakan perintah dump layanan mobil untuk layanan OEM:
adb shell dumpsys car_service --oem-service
Hasilnya bisa 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 siap dan false menunjukkan bahwa layanan belum siap.