Layanan plugin audio mobil

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.

gambar

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.

gambar

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 sifatnya 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 asli. 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. 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 kehilangan fokus, 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 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) dapat memperoleh 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.

  1. Navigasi
  2. Telepon
  3. Musik
  4. Pengumuman
  5. Perintah suara
  6. Dering panggilan
  7. Suara sistem
  8. Keamanan
  9. Alarm
  10. Notifikasi
  11. Status kendaraan
  12. Keadaan Darurat

Agar pengelolaan peristiwa kunci volume tidak terlalu rumit, layanan audio mobil memiliki daftar prioritas kedua konteks audio:

  1. Telepon
  2. Media
  3. Pengumuman
  4. 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 panduan 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 diperkecil:

    • 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:

gambar

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 terakhir 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.