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 manajemen audio secara fleksibel pada perangkat AAOS:
- Kontrol fokus audio
- Volume audio dan kontrol bisu
- Kontrol Audio Merunduk
Arsitektur layanan plugin mobil
Gambar di bawah ini memberikan gambaran umum tentang layanan mobil dan hubungannya dengan layanan mobil OEM. Mirip dengan proses aplikasi dan proses servis mobil, proses servis 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 menimpa API untuk memperoleh 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:
- Perutean audio
- Fokus audio
- Audio merunduk
- 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 layanan audio mobil untuk berkomunikasi dengan komponen yang ditentukan OEM yang mengelola:
- Fokus audio
- Audio merunduk
- Volume dan bisu
Gambar di bawah menunjukkan arsitektur yang disederhanakan untuk layanan audio mobil dan layanan OEM mobil. Layanan audio mobil menentukan kait berbeda yang dapat memanggil layanan audio OEM mobil untuk mengelola perilaku audio. Yang terakhir ini hanya terjadi jika komponen layanan audio mobil OEM yang sesuai ditentukan. Jika tidak, layanan audio mobil akan menggunakan perilaku default.
Untuk memastikan bahwa layanan audio mobil dan layanan audio OEM mobil selalu sinkron, untuk setiap panggilan, layanan audio mobil meneruskan bagian yang diperlukan dari status tumpukan audio saat ini ke layanan audio OEM mobil. Misalnya, ketika layanan audio mobil mencegat permintaan untuk mengevaluasi fokus audio, layanan tersebut meneruskan status tumpukan saat ini ke layanan audio OEM mobil. Status saat ini mencakup pemegang fokus saat ini dan pecundang fokus saat ini. Pecundang fokus adalah permintaan fokus yang masih menjadi bagian dari tumpukan namun kehilangan fokus untuk sementara.
Layanan audio mobil harus mengatur seluruh aktivitas audio di dalam mobil. Jika layanan audio mobil tidak mengelola beberapa bagian perilaku audio, maka informasi yang diberikan ke layanan audio OEM mobil tidak lengkap. Misalnya, jika OEM menimpa penanganan fokus audio di layanan mobil dengan mendaftarkan kebijakan fokus audio mereka sendiri, maka layanan audio mobil tidak dapat memberikan informasi lengkap ke layanan audio OEM mobil. Hal ini dapat mempengaruhi kemampuan layanan audio OEM mobil untuk mengambil keputusan karena mungkin kekurangan informasi yang tidak terlihat oleh layanan audio mobil.
Untuk mengambil tindakan, layanan audio mobil menghubungi layanan mobil OEM. Panggilan ini dilakukan lintas proses, yang memerlukan komunikasi antar-proses (IPC). IPC menambahkan latensi pada setiap panggilan. Penting untuk 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. Sebaliknya, 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 pendengar fokus kebijakan audio. Layanan audio mobil memiliki mekanisme untuk mengelola perilaku fokus berdasarkan matriks Interaksi statis. Matriks mendefinisikan tiga jenis interaksi yang berbeda:
Interaksi serentak. Pemegang fokus dapat mempertahankan fokus pada saat yang bersamaan.
Interaksi eksklusif. Permintaan fokus masuk mengambil fokus dari pemegang fokus saat ini.
Tolak interaksi. 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 ini 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, ini adalah API dua arah yang memblokir agar hasilnya kembali. Permintaan tersebut berisi informasi tentang status tumpukan audio saat ini:
Informasi ini dapat digunakan untuk mengevaluasi newFocusRequest dibandingkan dengan pemegang fokus saat ini di focusHolders dan pecundang fokus saat ini di focusLosers . API harus mengembalikan hasilnya:
class OemCarAudioFocusResult {
int audioZoneId;
int audioFocusEvaluationResults;
AudioFocusEntry focusResult;
List<AudioFocusEntry> newLosers;
List<AudioFocusEntry> newlyBlocked;
}
Ini berisi informasi tentang hasil evaluasi aktual di audioFocusEvaluationResults , yang menunjukkan apakah permintaan saat ini telah dikabulkan, ditunda, atau gagal. Setiap perubahan pada tumpukan fokus saat ini harus diatur dalam entri newLosers dan newlyBlocked , bergantung pada sifat perubahan tumpukan.
Dimana newLosers berisi entri yang sebelumnya memegang fokus namun sekarang harus kehilangan fokus, baik secara permanen atau sementara. Pecundang fokus permanen akan dihapus lebih lanjut dari tumpukan fokus audio, dan pecundang fokus sementara akan dipindahkan ke tumpukan pecundang fokus saat ini hingga mereka mendapatkan kembali fokus atau ditinggalkan dari peminta fokus awal. Terlepas dari itu, pemroses fokus untuk permintaan tersebut akan menerima hilangnya fokus terkait.
Daftar newlyBlocked berisi entri yang sebelumnya ada dalam daftar pecundang fokus namun sekarang diblokir oleh entri baru. Blok tersebut dapat bersifat permanen atau sementara, untuk fokus permanen yang diblokir, entri akan dihapus dari tumpukan dan kehilangan fokus akan dikirim ke pendengar fokus. Untuk kehilangan fokus sementara, entri akan tetap berada di tumpukan pecundang fokus namun pemblokir fokus baru akan ditambahkan ke daftar pemblokirnya, tidak ada kehilangan fokus yang akan dikirim seperti yang telah dikirim sebelumnya saat pertama kali diblokir. Permintaan akhirnya akan dibuka blokirnya ketika semua pemblokir saat ini dihapus, atau akan dihapus dari tumpukan jika fokus ditinggalkan.
API kedua, notifyAudioFocusChange , adalah salah satu cara yang dipanggil pada setiap permintaan atau pengabaian 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 optimal bagi pengguna. Oleh karena itu, layanan plugin OEM harus mempertimbangkan hal berikut saat mengelola permintaan fokus audio:
Tanpa fokus audio berprioritas tinggi (seperti panggilan telepon, keadaan darurat, atau keselamatan), aplikasi seharusnya dapat memperoleh fokus audio baik secara sementara atau permanen.
Saat fokus media aktif, aplikasi meminta:
Fokus penggunaan panggilan, harus dapat menerima fokus baik secara bersamaan maupun eksklusif.
Fokus penggunaan navigasi, harus dapat menerima fokus baik secara bersamaan maupun eksklusif.
Fokus penggunaan Asisten, harus dapat menerima fokus baik secara bersamaan atau eksklusif.
Saat aplikasi fokus audio prioritas tinggi (seperti panggilan telepon, peringatan darurat, atau peringatan keselamatan) aktif, permintaan fokus audio tertunda apa pun yang masuk harus dikabulkan atau ditunda sesuai kebutuhan.
Meskipun saran di atas tidak menyeluruh, saran tersebut dapat membantu menjamin bahwa aplikasi yang meminta fokus dapat memperoleh fokus ketika tidak ada suara prioritas tinggi yang aktif. Meskipun suara berprioritas tinggi aktif, permintaan fokus tertunda tetap harus dipenuhi dan harus dapat memperoleh fokus setelah suara berprioritas 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 disajikan dalam urutan menurun, prioritas tertinggi di atas dan prioritas terendah di bawah. Misalnya, jika audio navigasi dan audio musik aktif secara bersamaan, maka volume navigasi akan diubah selama aktivitas tombol volume.
- Navigasi
- Panggilan
- Musik
- Pengumuman
- Perintah suara
- Dering panggilan
- Suara sistem
- Keamanan
- Alarm
- Pemberitahuan
- Status kendaraan
- Keadaan darurat
Untuk membuat manajemen peristiwa tombol volume menjadi tidak terlalu rumit, layanan audio mobil memiliki daftar konteks audio prioritas kedua:
- Panggilan
- Media
- Pengumuman
- Perintah suara
Daftar ini juga disajikan dalam urutan menurun. Tujuan dari daftar kedua ini adalah untuk memungkinkan suara yang lebih umum diubah melalui peristiwa-peristiwa penting. Jarang terjadi, mungkin suara dengan durasi lebih pendek, hanya dapat diatur melalui UI pengaturan audio.
Versi volume sebenarnya dapat diatur dengan konfigurasi audioVolumeAdjustmentContextsVersion . Konfigurasi dapat diatur 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 menggunakan 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 dihindari. volumeGroupState memiliki status grup volume saat ini. Permintaan tersebut mewakili status tumpukan audio saat ini dan dapat digunakan untuk menentukan grup volume mana yang harus diubah. Hasilnya harus dikembalikan dalam OemCarVolumeChangeInfo :
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
change boolean menunjukkan jika ada volume yang berubah, true menunjukkan adanya 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, maka boolean akan bernilai true dan grup volume yang dikembalikan harus sesuai dengan navigasi.
Layanan merunduk mobil OEM
Layanan audio mobil mengelola pengecilan audio dengan memantau perubahan fokus audio dan mengirimkan sinyal ke AudioControl HAL tentang perangkat audio mana yang harus dihindarkan. Ketika fokus berubah, semua pemegang fokus aktif dievaluasi untuk menentukan mana yang harus dihindari berdasarkan rangkaian aturan pengelak statis berikut:
- Suara darurat meredam segalanya kecuali suara panggilan
- Keamanan menghindari segalanya kecuali suara darurat
- Navigasi menghindari segalanya kecuali suara keselamatan dan darurat
- Panggil bebek semuanya kecuali suara keselamatan, darurat, dan navigasi
- Suara dering panggilan bebek terdengar
- Musik dan pengumuman harus dihindari dalam segala hal
Aturan-aturan ini tidak menyeluruh dan OEM tetap bertanggung jawab untuk menentukan cara menghindari suara berdasarkan pedoman 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. Ini menggunakan kembali OemCarAudioVolumeRequest yang diperkenalkan di layanan volume mobil OEM , dan berisi informasi yang relevan untuk membuat keputusan tentang atribut mana yang harus dihindari. Daftar atribut audio yang harus dihindari dari API dibandingkan dengan status audio saat ini:
Atribut audio saat ini dihindari:
- Masuk daftar, terus merunduk
- Tidak ada dalam daftar, gerakan merunduk dimatikan
Atribut audio saat ini tidak dihindari:
- Dalam daftar, merunduk
- Tidak ada dalam daftar, gerakan merunduk dimatikan
Layanan audio mobil kemudian menentukan perangkat keluaran audio mana yang memiliki atribut audio dan menambahkannya masing-masing ke daftar perangkat keluaran audio yang dirundukkan atau daftar perangkat audio yang tidak dimasuki. Ini pada akhirnya dikirim ke AudioControl HAL untuk melakukan pengelak yang diperlukan pada tingkat perangkat keras.
Gambar di bawah menunjukkan diagram urutan yang disederhanakan dari kontrol pengelompokan audio untuk permintaan fokus ketika layanan pengelompokan OEM digunakan:
Urutannya dimulai saat aplikasi meminta Kelola fokus audio melalui API pengelola audio publik. Permintaan tersebut diteruskan ke layanan audio mobil untuk ditentukan hasilnya. Ketika fokus audio ditentukan, pengecilan audio dievaluasi oleh layanan audio mobil yang memanggil OemCarAudioDuckingService untuk mengevaluasi atribut audio mana yang harus dihindari. Setelah hasilnya dikembalikan dari API evaluateAttributesToDuck , perangkat audio yang akan di-duck dihitung, dan akhirnya informasi dikirim ke AudioControl untuk menerapkan ducking ke perangkat keras audio.
Implementasi referensi layanan audio mobil OEM
AAOS menyediakan implementasi referensi layanan mobil OEM dalam packages/services/Car/tests/OemCarServiceTestApp , yang mengimplementasikan 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 ini digunakan untuk mengevaluasi permintaan fokus ketika evaluateAudioFocusRequest dipanggil.
Referensi uji debug aplikasi
Aplikasi pengujian layanan mobil OEM adalah bagian dari kode sumber AOSP. OEM dapat melakukan perubahan sesuai 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, gunakan perintah dump layanan mobil untuk layanan OEM:
adb shell dumpsys car_service --oem-service
Hasilnya mungkin serupa dengan keluaran 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 kumpulan info dump menentukan status fitur dan layanan. Misalnya, info dump mIsOemServiceReady menentukan apakah layanan siap digunakan, dengan true menunjukkan layanan sudah siap dan false menunjukkan layanan belum siap.