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. Serupa 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 di
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 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 di
packages/services/Car/tests/OemCarServiceTestApp.
Meskipun dimulai oleh layanan mobil, layanan ini tidak otomatis
mewarisi izin yang tersedia untuk layanan audio mobil. Dengan demikian, 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 bisukan
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 untuk layanan audio mobil agar dapat berkomunikasi dengan komponen yang ditentukan OEM yang mengelola:
- Fokus audio
- Pengecilan volume audio
- Volume dan bisukan
Gambar di bawah menunjukkan arsitektur sederhana untuk layanan audio mobil dan layanan OEM mobil. Layanan audio mobil menentukan hook yang berbeda yang dapat memanggil layanan audio OEM mobil untuk mengelola perilaku audio. Hal 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 akan meneruskan bagian yang diperlukan dari status stack audio saat ini ke layanan audio OEM mobil. Misalnya, saat layanan audio mobil menangkap permintaan untuk mengevaluasi fokus audio, layanan tersebut akan meneruskan status stack saat ini ke layanan audio OEM mobil. Status saat ini mencakup holder fokus saat ini dan pengalih fokus saat ini. Focus loser adalah permintaan fokus yang masih merupakan 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 ditampilkan ke layanan audio OEM mobil tidak lengkap. Misalnya, jika OEM menimpa 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 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 antar-proses (IPC). IPC menambahkan latensi ke 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. Sebagai gantinya, layanan audio mobil memberikan informasi yang diperlukan sehingga panggilan antara dua 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 menentukan tiga jenis interaksi yang berbeda:
Interaksi serentak. Holder fokus dapat mempertahankan fokus secara bersamaan.
Interaksi eksklusif. Permintaan fokus yang masuk mengambil fokus dari holder fokus saat ini.
Menolak interaksi. Permintaan fokus masuk ditolak berdasarkan holder fokus saat ini.
Meskipun cukup untuk beberapa kasus penggunaan otomotif, hal ini tidak memenuhi semua
kebutuhan interaksi yang mungkin berbeda karena persyaratan OEM. Untuk ini, kita
memperkenalkan OemCarAudioFocusService:
public interface OEmCarAudioFocusService {
OemCarAuddioFocusResults evaluateAudioFocusRequest(
OemCarAudioFocusEvaluationRequest request);
void notifyAudioFocusChange(
List<AudioFocusEntry> holder,
List<AudioFocusEntry> losers, int zoneId);
}
evaluateAudioFocusRequest API dipanggil dari layanan audio mobil kapan saja
ada permintaan untuk fokus audio yang perlu dievaluasi, ini adalah API
dua arah yang memblokir agar hasil ditampilkan. Permintaan berisi informasi
tentang status stack audio saat ini:
Informasi ini dapat digunakan untuk mengevaluasi newFocusRequest dibandingkan dengan
holder fokus saat ini di focusHolders dan pengalih 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 sebenarnya di
audioFocusEvaluationResults, yang menunjukkan apakah permintaan saat ini telah
diberikan, tertunda, atau gagal. Setiap perubahan pada stack fokus saat ini
harus ditetapkan dalam entri newLosers dan newlyBlocked, bergantung pada sifat
perubahan stack.
Jika newLosers berisi entri yang sebelumnya memegang fokus, tetapi
sekarang harus kehilangan fokus, baik secara permanen maupun sementara. Pengalah fokus permanen
akan dihapus lebih lanjut dari stack fokus audio, dan pengalah fokus sementara
akan dipindahkan ke stack pengalah 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 sesuai yang hilang.
Daftar newlyBlocked berisi entri yang sebelumnya ada dalam daftar fokus yang hilang, tetapi sekarang diblokir oleh entri baru. Pemblokiran dapat 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 dalam stack fokus yang kalah, tetapi pemblokir fokus baru akan
ditambahkan ke daftar pemblokirnya, tidak ada kehilangan fokus yang akan dikirim seperti yang sebelumnya
dikirim saat pertama kali diblokir. Permintaan pada akhirnya akan diblokir 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 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 yang optimal bagi pengguna. Dengan demikian, layanan plugin OEM harus mempertimbangkan hal berikut saat mengelola permintaan fokus audio:
Tanpa fokus audio prioritas tinggi yang tetap (seperti panggilan telepon, darurat, atau keselamatan), aplikasi harus dapat memperoleh fokus audio secara sementara atau permanen.
Saat fokus media aktif, aplikasi meminta:
Fokus penggunaan panggilan, harus dapat menerima fokus secara serentak atau secara eksklusif.
Fokus penggunaan navigasi, harus dapat menerima fokus secara serentak atau secara eksklusif.
Fokus penggunaan Asisten, harus dapat menerima fokus secara serentak atau secara eksklusif.
Saat aplikasi fokus audio prioritas tinggi (seperti panggilan telepon, pemberitahuan darurat, atau pemberitahuan 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. Meskipun suara berprioritas tinggi aktif, permintaan fokus yang tertunda harus tetap dihormati dan harus dapat mendapatkan 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, volume navigasi akan diubah selama peristiwa tombol volume.
- Navigasi
- Telepon
- Musik
- Pengumuman
- Perintah suara
- Dering panggilan
- Suara sistem
- Keamanan
- Alarm
- Notifikasi
- Status kendaraan
- Keadaan Darurat
Agar 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 untuk 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 volume yang sebenarnya dapat ditetapkan dengan
konfigurasi audioVolumeAdjustmentContextsVersion. Konfigurasi dapat
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 aktif. duckedAttributes
adalah semua atribut audio yang saat ini dibisukan. 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. Hasilnya akan 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. 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 peredam suara mobil OEM
Layanan audio mobil mengelola audio ducking dengan memantau perubahan fokus audio dan
mengirim sinyal ke HAL AudioControl tentang perangkat audio yang akan di-duck.
Saat fokus berubah, semua holder fokus aktif dievaluasi untuk menentukan
mana yang harus disembunyikan berdasarkan kumpulan aturan
penyamaran statis ini:
- Suara darurat meredam semua suara kecuali suara panggilan
- Mode keselamatan akan membisukan semua suara kecuali suara darurat
- Navigasi meredam semua suara kecuali suara keselamatan dan darurat
- Panggilan akan membisukan semua suara kecuali suara keselamatan, darurat, dan navigasi
- Suara dering panggilan Voice dibisukan
- Musik dan pengumuman harus disamarkan oleh semua suara
Aturan ini tidak lengkap dan OEM tetap bertanggung jawab untuk menentukan
cara suara harus diredam 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 fokus audio berubah. Class ini 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 disembunyikan dari API dibandingkan dengan status audio saat ini:
Atribut audio saat ini dibisukan:
- Ada dalam daftar, terus disembunyikan
- Tidak ada dalam daftar, peredam suara dinonaktifkan
Atribut audio saat ini tidak dibisukan:
- Di daftar, disembunyikan
- Tidak ada dalam daftar, peredam suara dinonaktifkan
Layanan audio mobil kemudian menentukan perangkat output audio yang menjadi milik atribut audio dan menambahkannya ke daftar perangkat output audio yang dibisukan atau daftar perangkat audio yang tidak dibisukan. Hal ini pada akhirnya dikirim ke AudioControl HAL untuk melakukan ducking yang diperlukan di tingkat hardware.
Gambar di bawah menunjukkan diagram urutan sederhana dari kontrol audio yang diredam untuk permintaan fokus saat layanan peredam 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, audio ducking
dievaluasi oleh layanan audio mobil yang memanggil OemCarAudioDuckingService untuk
mengevaluasi atribut audio mana yang harus di-duck. Setelah hasilnya ditampilkan
dari evaluateAttributesToDuck API, perangkat audio yang akan di-duck dihitung,
dan akhirnya informasi dikirim ke AudioControl untuk menerapkan duck
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 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.
Referensi proses debug aplikasi pengujian
Aplikasi pengujian layanan mobil OEM adalah bagian dari kode sumber AOSP. OEM dapat membuat
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 layanan mobil OEM menggunakan perintah dump layanan mobil untuk
layanan OEM:
adb shell dumpsys car_service --oem-service
Hasilnya mungkin 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 dalam 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.