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 bisu 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 konfigurasi 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();
}
Misalnya
, lihat
aplikasi pengujian referensi yang ditentukan dalam
packages/services/Car/tests/OemCarServiceTestApp.
Meskipun layanan dimulai oleh layanan mobil, layanan ini tidak secara otomatis mewarisi izin yang tersedia untuk layanan audio mobil. Oleh karena itu, izin apa pun 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 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 sinkron, untuk setiap panggilan, layanan audio mobil akan meneruskan bagian yang diperlukan dari status saat ini dari tumpukan audio ke layanan audio OEM mobil. Misalnya, saat layanan audio mobil mencegat permintaan untuk mengevaluasi fokus audio, layanan ini akan meneruskan status tumpukan saat ini ke layanan audio OEM mobil. Status saat ini mencakup pemegang fokus saat ini dan pihak yang kehilangan fokus saat ini. Pihak yang kehilangan fokus adalah permintaan fokus yang masih menjadi bagian dari tumpukan, tetapi yang untuk sementara kehilangan fokus.
Layanan audio mobil harus mengelola semua aktivitas audio di mobil. Jika layanan audio mobil tidak mengelola beberapa bagian dari perilaku audio, informasi yang ditampilkan ke layanan audio OEM mobil akan tidak lengkap. Misalnya, jika OEM mengganti penanganan fokus audio di layanan mobil dengan mendaftarkan kebijakan fokus audionya sendiri, layanan audio mobil tidak dapat memberikan informasi lengkap ke layanan audio OEM mobil. Hal ini dapat memengaruhi kemampuan layanan audio OEM mobil untuk membuat keputusan karena mungkin tidak memiliki informasi yang tidak terlihat oleh layanan audio mobil.
Untuk mengambil 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 dalam 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 kedua proses hanya perlu dilakukan 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 pada saat yang sama.
Interaksi eksklusif. Permintaan fokus masuk mengambil fokus dari pemegang fokus saat ini.
Interaksi tolak. Permintaan fokus masuk ditolak berdasarkan pemegang fokus saat ini.
Meskipun hal ini 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 ini berisi informasi tentang status tumpukan audio saat ini:
Informasi ini dapat digunakan untuk mengevaluasi newFocusRequest dibandingkan dengan pemegang fokus saat ini di focusHolders dan pihak yang kehilangan fokus saat ini di focusLosers. API harus menampilkan hasil:
class OemCarAudioFocusResult {
int audioZoneId;
int audioFocusEvaluationResults;
AudioFocusEntry focusResult;
List<AudioFocusEntry> newLosers;
List<AudioFocusEntry> newlyBlocked;
}
Hal ini berisi informasi tentang hasil evaluasi sebenarnya di audioFocusEvaluationResults, yang menunjukkan apakah permintaan saat ini telah diberikan, ditunda, atau gagal. Setiap perubahan pada tumpukan fokus saat ini harus ditetapkan dalam entri newLosers dan newlyBlocked, bergantung pada sifat perubahan tumpukan.
Dengan newLosers berisi entri yang sebelumnya memegang fokus, tetapi sekarang harus kehilangan fokus, baik secara permanen maupun sementara. Pihak yang kehilangan fokus permanen akan dihapus lebih lanjut dari tumpukan fokus audio, dan pihak yang kehilangan fokus sementara akan dipindahkan ke tumpukan pihak yang kehilangan fokus saat ini hingga mereka mendapatkan kembali fokus atau ditinggalkan dari peminta fokus asli. Terlepas dari itu, pemroses fokus untuk permintaan akan menerima fokus yang hilang yang sesuai.
Daftar newlyBlocked berisi entri yang sebelumnya berada dalam daftar pihak yang kehilangan fokus, tetapi sekarang diblokir oleh entri baru. Blokir dapat bersifat permanen atau sementara. Untuk fokus permanen yang diblokir, entri akan dihapus dari tumpukan dan fokus yang hilang akan dikirim ke pemroses fokus. Untuk fokus yang hilang sementara, entri akan tetap berada dalam tumpukan pihak yang kehilangan fokus, tetapi pemblokir fokus baru akan ditambahkan ke daftar pemblokirnya. Tidak ada fokus yang hilang yang akan dikirim karena sebelumnya telah dikirim saat pertama kali diblokir. Permintaan akhirnya akan berhenti diblokir saat semua pemblokir saat ini dihapus, atau akan dihapus dari tumpukan jika fokus ditinggalkan.
API kedua, notifyAudioFocusChange, adalah satu arah yang dipanggil pada setiap permintaan fokus audio atau ditinggalkan. API ini sebagian besar digunakan untuk memberi tahu layanan OEM tentang perubahan fokus, yang dapat memengaruhi perilaku layanan audio mobil OEM.
Panduan untuk evaluasi fokus
Di AAOS, fokus audio digunakan untuk mengelola pemutaran audio dan menentukan aplikasi mana yang harus dipatuhi untuk memberikan pengalaman optimal bagi pengguna. Oleh karena itu, layanan plugin OEM harus mempertimbangkan hal berikut saat mengelola permintaan fokus audio:
Tanpa fokus audio prioritas tinggi yang ada (seperti panggilan telepon, darurat, atau keselamatan), aplikasi harus dapat memperoleh fokus audio baik sementara maupun permanen.
Saat fokus media aktif, aplikasi yang meminta:
Fokus penggunaan panggilan, harus dapat menerima fokus baik secara serentak maupun eksklusif.
Fokus penggunaan navigasi, harus dapat menerima fokus baik secara serentak maupun eksklusif.
Fokus penggunaan asisten, harus dapat menerima fokus baik secara serentak maupun eksklusif.
Saat aplikasi fokus audio prioritas tinggi yang ada (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 menjamin bahwa aplikasi yang meminta fokus harus dapat memperoleh fokus saat tidak ada suara prioritas tinggi yang aktif. Bahkan saat suara prioritas tinggi aktif, permintaan fokus tertunda harus tetap dipertimbangkan dan harus dapat memperoleh fokus setelah suara prioritas tinggi berhenti.
Layanan volume mobil OEM
Layanan audio mobil mengelola peristiwa tombol volume dengan mendengarkan penyesuaian volume dari sistem audio atau dengan mendengarkan 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, dengan prioritas tertinggi di bagian atas dan prioritas terendah di bagian bawah. Misalnya, jika audio navigasi dan audio musik aktif pada saat yang sama, volume navigasi akan berubah selama peristiwa tombol volume.
- Navigasi
- Telepon
- Musik
- Pengumuman
- Perintah suara
- Dering panggilan
- Suara sistem
- Keamanan
- Alarm
- Notifikasi
- Status kendaraan
- Darurat
Untuk membuat pengelolaan peristiwa tombol volume menjadi tidak terlalu rumit, layanan audio mobil memiliki daftar prioritas kedua dari konteks audio:
- Telepon
- Media
- Pengumuman
- Perintah suara
Daftar ini juga ditampilkan dalam urutan menurun. Tujuan dari daftar kedua ini adalah untuk memungkinkan suara yang lebih umum diubah melalui peristiwa tombol. Suara yang tidak umum, mungkin suara dengan durasi yang lebih singkat, hanya dapat dikelola melalui UI setelan audio.
Versi volume sebenarnya dapat ditetapkan dengan konfigurasi audioVolumeAdjustmentContextsVersion. Konfigurasi dapat ditetapkan ke 1 atau 2 (2 adalah default).
Untuk memberikan lebih banyak fleksibilitas 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 mengambil 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 dikecilkan volumenya. volumeGroupState memiliki status grup volume saat ini. Permintaan ini mewakili status tumpukan audio saat ini dan dapat digunakan untuk menentukan grup volume mana yang harus diubah. Hasilnya harus ditampilkan di 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 dibisukan, boolean akan menjadi true dan grup volume yang ditampilkan harus 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 akan dikecilkan volumenya.
Saat fokus berubah, semua pemegang fokus aktif akan dievaluasi untuk menentukan
mana yang harus dikecilkan volumenya berdasarkan kumpulan aturan pengecilan volume statis
ini:
- Suara darurat mengecilkan volume semua suara kecuali suara panggilan
- Keselamatan mengecilkan volume semua suara kecuali suara darurat
- Navigasi mengecilkan volume semua suara kecuali suara keselamatan dan darurat
- Panggilan mengecilkan volume semua suara kecuali suara keselamatan, darurat, dan navigasi
- Suara mengecilkan volume suara dering panggilan
- Musik dan pengumuman harus dikecilkan volumenya oleh semuanya
Aturan ini tidak lengkap dan OEM tetap bertanggung jawab untuk menentukan cara suara harus dikecilkan volumenya 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 pada perubahan fokus audio. API ini menggunakan kembali
yang OemCarAudioVolumeRequestdiperkenalkan dalam
layanan volume mobil OEM, dan berisi informasi yang relevan
untuk membuat keputusan tentang atribut mana yang akan dikecilkan volumenya. Daftar atribut audio yang akan dikecilkan volumenya dari API dibandingkan dengan status audio saat ini:
Atribut audio yang saat ini dikecilkan volumenya:
- Dalam daftar, terus dikecilkan volumenya
- Tidak ada dalam daftar, pengecilan volume dinonaktifkan
Atribut audio yang saat ini tidak dikecilkan volumenya:
- Dalam daftar, dikecilkan volumenya
- Tidak ada dalam daftar, pengecilan volume dinonaktifkan
Layanan audio mobil kemudian menentukan perangkat output audio mana yang menjadi milik atribut audio dan menambahkannya ke daftar perangkat output audio yang dikecilkan volumenya atau daftar perangkat audio yang tidak dikecilkan volumenya. Hal ini pada akhirnya dikirim ke AudioControl HAL untuk melakukan pengecilan volume yang diperlukan di tingkat hardware.
Gambar di bawah menunjukkan diagram urutan yang disederhanakan dari kontrol 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 layanan audio mobil untuk menentukan hasilnya. Saat fokus audio ditentukan, pengecilan volume audio dievaluasi oleh layanan audio mobil yang memanggil OemCarAudioDuckingService untuk mengevaluasi atribut audio mana yang harus dikecilkan volumenya. Setelah hasil ditampilkan dari evaluateAttributesToDuck API, perangkat audio yang akan dikecilkan volumenya dihitung, dan akhirnya informasi dikirim ke AudioControl untuk menerapkan pengecilan volume ke hardware audio.
Implementasi referensi layanan audio mobil OEM
AAOS menyediakan implementasi referensi layanan mobil OEM di
packages/services/Car/tests/OemCarServiceTestApp, yang mengimplementasikan
OemCarService, bersama dengan OemCarAudioFocusService,
OemCarAudioDuckingService, dan OemCarAudioVolumeService. Untuk yang terakhir, setiap layanan menggunakan file dan XML untuk memuat perilaku statis. Misalnya, OemCarAudioFocusServiceImp memuat oem_focus_config.xml, yang berisi matriks interaksi. Matriks ini 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 dengan kebutuhannya. 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 layanan mobil OEM menggunakan perintah dump layanan mobil untuk layanan OEM:
adb shell dumpsys car_service --oem-service
Hasilnya dapat mirip dengan output di bawah:
***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 tidak siap.