Yapılandırılabilir ses politikası motoru

Android 14'te Android Automotive İşletim Sistemi (AAOS), birincil ses bölgesinde araç ses yönetimi için yapılandırılabilir ses politikası (CAP) motorundan yararlanır. CAP motoru, AAOS'un yalnızca ses yönlendirmeyi, yalnızca ses düzeyini veya hem yönlendirmeyi hem de ses düzeyini aynı anda kontrol etmesine olanak tanır. Aşağıdaki işaretler, davranışı kontrol etmek için kullanılabilir:

• CAP hacim yönetimini etkinleştirmek için useCoreAudioVolume işaretini kullanın. Bu değer true olduğunda, araba ses hizmeti ses grubu yöneticisi API'lerini kullanarak ses gruplarını yönetir.

• CAP ses yönlendirme yönetimini etkinleştirmek için useCoreAudioRouting işaretini kullanın. Bu değer true olduğunda, araba ses hizmeti ses yönlendirmesini yönetmek için yapılandırılabilir ses politikası yönlendirmesini kullanır.

Ses politikası motoru, Android'de varsayılan olarak varsayılan ses politikası motoru şeklinde de desteklenir.

Arka plan

CAP motoru, Intel'in parametre çerçevesini temel alır. Bu çerçeve, parametreleri işlemek için kullanılan eklenti tabanlı ve kural tabanlı bir çerçevedir. Özellikle Android'de ses yönetimi için CAP motoru, XML dosyası kurallarını tanımlama özelliğini kullanıma sundu. Bu kurallar, aşağıdakileri belirtecek şekilde tanımlanabilir:

• Ses ürünü stratejisi
• Ses çıkış cihazı seçimiyle ilgili kurallar
• Ses giriş cihazı seçimiyle ilgili kurallar
• Ses düzeyini ve sesi kapatmayı yönetme kuralları ile ses düzeyi tabloları

Android 16'dan önceki sürümlerde CAP başlatma

Aşağıdaki şekilde, Android 6 itibarıyla yapılandırılabilir ses politikası motoru yapılandırma yönetimine genel bir bakış gösterilmektedir:

1. şekil. Android 6'dan itibaren CAP motoru yapılandırma yönetimi.

Şekilde gösterildiği gibi, CAP motoru yapılandırması, audio_policy_engine_configuration.xml dosyasındaki bilgileri ayrıştırarak ses politikası hizmeti tarafından elde edilir.vendor CAP motoru yapılandırma dosyası, gerekli bilgileri almak için audio_policy_engine_configuration.xsd içinde tanımlanan şemayı kullanır. audio_policy_engine_configuration.xml, otomotiv sektörüne yönelik bir örnektir. Diğer form faktörleriyle ilgili benzer örnekler frameworks/av/services/audiopolicy/engineconfigurable/config/example/ klasöründe yer alır.

Aşağıdaki şekilde, yapılandırılabilir ses politikası motoru bilgilerinin ses politikası hizmetine nasıl yüklendiği hakkında daha ayrıntılı bilgiler verilmektedir. Bu durumda, parametre çerçevesi yapıyı ve ayarları XML dosyalarından yükler.

Şekil 2. Ses politikası hizmetine yüklenen CAP bilgileri.

Android 15 ve önceki sürümlerde CAP yapı dosyaları

Yapı ve ayarları almak için ses politikası hizmeti, ParameterFrameworkConfigurationPolicy.xml dosyasını okur. Bu, yapı açıklama dosyası konumu aracılığıyla yapı bilgilerine referans verir:

<StructureDescriptionFileLocation Path="Structure/Policy/PolicyClass.xml"/>

Bu, dosyadaki yapı bilgilerini gösterir:

/vendor/etc/parameter-framework/Structure/Policy/PolicyClass.xml

Android'de iskelet yapısı sağlanır. . Yapı bilgileri için ürün stratejisi yapı bilgileri gerekir. Bu nedenle Android, mevcut ürün stratejisi XML dosyasından bilgi oluşturabilen buildStrategiesStructureFile.py üretim aracını sunar. Bu, aşağıdaki gibi genrule default buildstrategiesstructurerule aracılığıyla referans verilebilir:

genrule {
    name: "buildstrategiesstructure_gen",
    defaults: ["buildstrategiesstructurerule"],
    srcs: [
        ":audio_policy_engine_configuration_files",
    ],
}

Burada audio_policy_engine_configuration_files, ses politikası motoru yapılandırma dosyalarıdır. Bu otomotiv örneği, automotive klasöründeki ses politikası yapılandırma dosyalarına referans verir. Diğer örneklerde, cihazın satıcı bölümündeki dosyaları göndermek için derlemenin nasıl yapılandırılacağı gösterilmektedir.

Android 15 ve önceki sürümlerde CAP ayar dosyaları

Yapıya benzer şekilde, parametrelerin kurallarını ve değerlerini temsil eden ayar bilgileri, ParameterFrameworkConfigurationPolicy.xml dosyasında şu şekilde referans verilir:

<SettingsConfiguration>
  <ConfigurableDomainsFileLocation Path="Settings/Policy/PolicyConfigurableDomains.xml"/>
</SettingsConfiguration>

Android, ses politikası motoru yapılandırmasını ve parametre çerçevesi dosyalarını kullanarak bu bilgileri oluşturmak için derleme araçları da sağlar. Daha fazla bilgi için Yapılandırmalar bölümüne bakın.

AIDL ses HAL CAP başlatma

Android 16'dan itibaren AIDL Audio HAL API tanımı, ses politikası motoru yapılandırmaları AudioHalCapConfiguration.aidl ile genişletildi. Aşağıdaki şekilde, Android 16 itibarıyla CAP motoru yapılandırma yönetimine genel bir bakış gösterilmektedir:

3.Şekil Android 16 itibarıyla CAP motoru yapılandırma yönetimi.

Ses politikası hizmeti, cihazın satıcı bölümündeki XML dosyalarından bilgileri ayrıştırmak yerine doğrudan AIDL Audio HAL API'lerini kullanarak CAP motoru bilgilerini alır.

Bu yapılandırmada, parametre çerçevesinin yapısı ses sunucusu tarafında CAP motoru tarafından yüklenmeye devam eder.

Şekil 4. CAP motor yapısı.

Her durumda, yapılandırmada ürün stratejileri, hacim grupları ve ölçütlerle ilgili bilgiler tam olarak belirtilmelidir.

Aşağıdaki şekilde, CAP motoru yapılandırmasını almak için ses politikası hizmeti tarafından kullanılan AIDL ses HAL API'lerinin üst düzey bir genel görünümü gösterilmektedir:

5.Şekil AIDL ses HAL API'leri.

Bu kurulumda, ses politikası hizmeti AIDL ses HAL'sinden aşağıdaki bilgileri alır:

• Yapılandırma
• Stratejiler
• Ciltler
• Ölçütler
• Ayarlar

Varsayılan AIDL Audio HAL yükleyici

HIDL'den AIDL'ye geçişi kolaylaştırmak için varsayılan ses AIDL Audio HAL, XML CAP motoru yükleyici sağlar. Tedarikçiler, ses HAL'lerini varsayılan ses HAL'siyle genişleterek veya libaudioserviceexampleimpl kitaplığına başvurarak bu yükleyiciyi doğrudan kullanabilir.

Varsayılan AIDL ses HAL yükleyicisi, aşağıdaki bilgileri almak için audio_policy_engine_configuration.xml kullanır:

• Yapılandırma
• Stratejiler
• Ciltler
• Ölçütler

Yapı bilgileri PolicyConfigurableDomains.xml dosyasından alınır. Önceki mekanizmadan temel farkı, yapı bilgilerinin ses politikası hizmetindeki parametre çerçevesi yerine AIDL ses HAL'si tarafından da alınmasıdır.

Satıcılar, ses politikası motoru yapılandırmasındaki bilgileri kullanarak yapılandırılabilir alanlar oluşturmak için domaingeneratorpolicyrule aracını kullanabilir. Otomotiv Cuttlefish sanal cihaz örneği referans olarak kullanılabilir.

AIDL yapılandırmasındaki yapı

Android 16 ve sonraki sürümlerde ses politikası hizmeti, yapı bilgilerini ParameterFrameworkConfigurationCap.xml [file](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/av/services/audiopolicy/engineconfigurable/wrapper/ParameterManagerWrapper.cpp;l=71

). Özellikle bilgileri yapı açıklaması dosyasından alır:

<StructureDescriptionFileLocation Path="Structure/Policy/CapClass.xml"/>

Çerçeve, gerekli dosyaları /etc/parameter-framework/ klasörüne bırakır.

Yapı, kontrol edilmesi gereken parametreleri temsil eder. Bu nedenle, yapılandırmada veya alanlarda bunlara referans verilmelidir. Bunun için AIDL motoru yapılandırmasında parametreler için önceden belirlenmiş bir ad kullanılmalıdır. Ürün stratejileri için yapılar CapProductStrategies.xml bölümünde yapılandırılır.

Varsayılan ürün stratejileri

Varsayılan motorda sağlanan varsayılanlarla başlayarak ürün stratejileri STRATEGY_ önekiyle başlar:

• STRATEGY_PHONE
• STRATEGY_SONIFICATION
• STRATEGY_ENFORCED_AUDIBLE
• STRATEGY_ACCESSIBILITY
• STRATEGY_SONIFICATION_RESPECTFUL
• STRATEGY_MEDIA
• STRATEGY_DTMF
• STRATEGY_CALL_ASSISTANT
• STRATEGY_TRANSMITTED_THROUGH_SPEAKER

Bu biçim, varsayılan stratejileri kullanan cihazlarda HIDL'den AIDL'ye geçişi kolaylaştırmak için sağlanmıştır. Bu biçim değişikliği, motoru yapılandırmak için kullanılan mevcut dosyalar (ör. PfW, XML) üzerinde bazı etkiler yaratır. Özellikle tüm ürün stratejisi referansları yeni adları kullanacak şekilde değiştirilmelidir. Örneğin:

OEM tarafından tanımlanan ürün stratejileri

Yapılandırılabilir motor, OEM'lerin ürün stratejisi tanımını değiştirmesine olanak tanır. Bu desteği sürdürmek için ürün stratejisi dosyası CapProductStrategies.xml ayrıca vx_1000 ile vx_1039 arasında 40 tedarikçi tarafından genişletilebilir ürün stratejisi de sunar. Tüm satıcı uzantıları vx_ önekiyle başlamalı ve AIDL ses HAL ürün stratejisi tanımında ürün stratejisi kimliğini temsil eden bir sayıyla devam etmelidir. Tanımların geri kalanı (ör. ses özelliği grupları, ad), ses HAL motoru yapılandırmasındaki AudioHALProductStrategy nesnesinden alınır.

Varsayılan ürün stratejilerinde olduğu gibi, satıcı tarafından tanımlanan OEM referansları da AIDL olmayan yapılandırma ile AIDL yapılandırması arasında uyarlanmalıdır. Örneğin:

Ürün stratejileri

Ürün stratejileri, ses akışlarının nasıl kategorize edilip gruplandırılacağını özelleştirmenin bir yolunu sunar. Bu sayede, yönlendirme ve ses seviyesi yönetimi de dahil olmak üzere ses cihazlarının yapılandırılması konusunda daha fazla esneklik sağlanır. Her ürün stratejisinde, bu ürün stratejisiyle ilişkilendirilmesi gereken akışları tanımlayan bir veya daha fazla ses özelliği grubu olabilir. Bu ses özelliği grupları, sesleri daha ayrıntılı bir şekilde sınıflandırmaya olanak tanır ve aşağıdaki türlerin bir karışımı olabilir:

• Kullanım türleri, sesin neden çalındığını (ör. medya, bildirim, arama) açıklar.
• İçerik türleri, oynatılan içeriği (ör. müzik, konuşma, video, seslendirme) tanımlar.
• İşaret türleri, akışla ilgili farklı davranışları veya istekleri tanımlar.
• Etiket türleri, herhangi bir satıcı dize değerleri listesini destekler.
  • Her dize, VX_ ile başlamalı ve ardından alfanümerik bir dize (ör. VX_OEM, VX_NAVIGATION) gelmelidir.

<ProductStrategy name="music" id="1008">
    <AttributesGroup streamType="AUDIO_STREAM_MUSIC" volumeGroup="media">
        <Attributes> <Usage value="AUDIO_USAGE_MEDIA"/> </Attributes>
        <Attributes> <Usage value="AUDIO_USAGE_GAME"/> </Attributes>
        <!-- Default product strategy has empty attributes -->
        <Attributes></Attributes>
    </AttributesGroup>
</ProductStrategy>

Bu alıntıda, araba emülatörlerinde kullanılan bir ürün stratejisi örneği gösterilmektedir. Bu öğe, sırasıyla ses kullanımına yönelik medya ve oyun olmak üzere iki ses özelliği içerir. Bu ürün stratejisi, MUSIC araba ses hizmetinde kullanılan ses bağlamıyla eşleşir, ancak bu tür bir eşleşme zorunlu değildir. CAP'yi Android ile birlikte kullanan OEM'ler için temel yardımcı programlardan biri, daha esnek ses gruplandırma tanımlarına izin vermektir.

Hacim grupları

Ayrıca, her ses özelliği grubunun ilişkili bir hacim grubu olmalıdır. Bu birim grubu, ses özelliği grubuna ait ses özellikleriyle eşleşen tüm yayınlarla ilişkilendirilir. Ürün stratejileri bölümündeki örnek müzik ürünü stratejisinde media hacim grubu bulunur ve medya hacim grubunun tanımı şu şekildedir:

<volumeGroup>
    <name>media</name>
    <indexMin>0</indexMin>
    <indexMax>40</indexMax>
    <volume deviceCategory="DEVICE_CATEGORY_SPEAKER">
        <point>0,-2400</point>
        <point>33,-1600</point>
        <point>66,-800</point>
        <point>100,0</point>
    </volume>
</volumeGroup>

Bu tanımda birim grubu şunları içerir:

• Grup adı
• Grup minimum endeksi
• Grup maksimum endeksi
• Ses grubu eğrileri

Ses grubu eğrileri, ses grubu dizini ile milibel cinsinden ses kazancı arasında noktasal eşleme içerir. Belirtilen noktalar, ses seviyesi yönetilirken en iyi eşleşen kazancı doğrusal olarak tahmin etmek için kullanılır. Her bir ses grubu eğrisi bir cihaz türü kategorisiyle (örneğin, kulaklık, hoparlör, harici medya) ilişkilendirilir.

Ses seviyesi grubu, ses özellikleri grubunun parçası olan akışların ses seviyesini yönetir. Örneğin, müzik veya oyun içeren ses özelliklerine sahip bir akış başlatıldığında, medya ses grubu için son ayarlanan ses düzeyi dizini kullanılır. Bu durumda, seçilen cihaza göre ilgili cihaz kategorisi eğrisi seçilir ve yayın başlatıldığında ilgili kazanç ayarlanır.

Yapılandırmalar

CAP motorunda, sesin nasıl davranması gerektiğini belirleyen koşulları veya kuralları tanımlamak için yapılandırmalar kullanılır. Bu yapılandırmalar, ses sisteminin mevcut durumuna bağlı olarak uygulanacak uygun kuralları seçmek için çalışma zamanında değerlendirilir.

Şekil 5'te gösterildiği gibi, API birden fazla alan içerir. Her alanın amacı, çözülecek mantığı daha küçük yönlendirme sorunlarına (ör. cihaz 1, cihaz 2) bölmektir.

Her alanın yapılandırmaları, her yapılandırmanın da bir dizi kuralı vardır. Kurallar, AudioPolicyManager tarafından sağlanan ölçütlere göre belirlenir:

• Ses modu
• Kullanılabilir giriş ve çıkış cihazları
• Kullanılabilir giriş ve çıkış cihazlarının adresleri
• Şunun için kullanın:
  • Medya
  • İletişim
  • Kayıt
  • Yuva
  • Sistem
  • HDMI sistem sesi
  • Kodlanmış surround
  • Zil titreşimi

Her alan, davranışı etkilemesi gereken kuralları belirleyen yapılandırmalar içerir. Yapılandırma sırasının önemli olduğunu ve yapılandırmaların gerekli sırada olduğundan emin olmanız gerektiğini unutmayın. Bir yapılandırmanın kuralları doğrulandıktan sonra yapılandırma seçilir.

Aşağıdaki kodda, yapılandırılabilir alanları yapılandırmak için gerekli XML dosyasını oluşturmak üzere kullanılabilecek bir parametre çerçevesi dosyasının alıntı örneği gösterilmektedir:

supDomain: DeviceForProductStrategies
  supDomain: Music
    domain: SelectedDevice
      conf: BluetoothA2dp
        ForceUseForMedia IsNot NO_BT_A2DP
        ForceUseForCommunication IsNot BT_SCO
        AvailableOutputDevices Includes BLUETOOTH_A2DP
        component:/Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 1
          bus = 0
      conf: Bus
        AvailableOutputDevices Includes Bus
        AvailableOutputDevicesAddresses Includes BUS00_MEDIA
        component: /Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 0
          bus = 1
      conf: Default
        component: /Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 0
          bus = 0

DeviceForProductStrategies alanı, ürün stratejileri cihaz seçimi işlenirken farklı kuralların nasıl uygulanacağını tanımlar. Mavi kısımlarda dikkate alınması gereken kurallar, yeşil kısımda ise uygulanan yapılandırma açıklanır. Bu örnekte aşağıdaki yapılandırmalar yer almaktadır:

• Müzik ürünü stratejisi için Bluetooth A2DP cihazını seçin (ID 1000, vx_1000)
  • Medya için kullanılıyorsa A2DP'yi hariç tutmaz.
  • İletişim için kullanılıyorsa BT SCO değildir.
  • Varsa BT A2DP'yi ekleyin.
• Veri yolu cihazını seçin.
  • Otobüs cihazları özelliği kullanılabiliyorsa
  • Adres BUS00_MEDIA ise
• Aksi takdirde varsayılan çıkış cihazını seçin

İlgili yapılandırılabilir politika motoru XML dosyasını oluşturmak için aşağıdaki adımları uygulayarak bir derleme kuralı tanımlayıp parametre çerçevesi (PFW) dosyalarını derleme sisteminden geçirin:

1. Android.bp dosyasında, dosya için bir dosya grubu oluşturun:

   filegroup {
       name: ":device_for_product_strategies.pfw",
       srcs: ["engine/parameter-framework/Settings/device_for_product_strategyies.pfw"],
   }
   

2. Dosyayı diğer PfW dosyalarına (varsa) ekleyin.

   filegroup {
       name: "edd_files",
       srcs: [
           ":device_for_input_source.pfw",
           ":volumes.pfw",
           ":device_for_product_strategyies.pfw",
       ],
   }
   

3. İlgili alan oluşturma kuralını oluşturun:

   genrule {
       name: "domaingeneratorpolicyrule_gen",
       defaults: ["domaingeneratorpolicyrule"],
       srcs: [
           ":audio_policy_engine_criterion_types",
           ":audio_policy_pfw_structure_files",
           ":audio_policy_pfw_toplevel",
           ":edd_files",
       ],
   }
   

   Burada domaingeneratorpolicyrule, PolicyConfigurableDomains.xml dosyasını oluşturmak için çerçeve tarafından sağlanan bir oluşturma kuralıdır. Alan oluşturma kurallarına dahil edilen diğer kaynak dosyalar (scrs) şunlardır:

   Kaynak	Açıklama
   audio_policy_pfw_toplevel	Üst düzey parametre çerçevesi yapılandırma dosyası.
   audio_policy_pfw_structure_files	Yapılandırma dosyalarını oluşturmak için kullanılan alan oluşturma yapısı dosyaları.
   audio_policy_engine_criterion_types	Oluşturma sırasında kullanılan ölçütleri açıklayan ölçüt türleri XML dosyası.
   edd_files	Tek alan dosyalarının listesi (her biri tek bir <ConfigurableDomain> etiketi içerir).

Derlemede oluşturma kuralı çalıştırıldıktan sonra PolicyConfigurableDomains.xml, tüm alanlarla birlikte oluşturulur. Aşağıda, PfW örneği kuralları kullanılarak oluşturulan dosyadan bir alıntı gösterilmektedir:

---ConfigurableDomain Name="DeviceForProductStrategies.Music.SelectedDevice"---
<Configurations>
  <Configuration Name="BluetoothA2dp">
    <CompoundRule Type="All">
      <SelectionCriterionRule SelectionCriterion="ForceUseForMedia" MatchesWhen="IsNot" Value="NO_BT_A2DP"/>
      <SelectionCriterionRule SelectionCriterion="ForceUseForCommunication" MatchesWhen="IsNot" Value="BT_SCO"/>
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevices" MatchesWhen="Includes" Value="BLUETOOTH_A2DP"/>
    </CompoundRule>
  </Configuration>
  <Configuration Name="Bus">
    <CompoundRule Type="All">
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevices" MatchesWhen="Includes" Value="BUS"/>
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevicesAddresses" MatchesWhen="Includes" Value="BUS00_MEDIA"/>
    </CompoundRule>
  </Configuration>
  <Configuration Name="Default">
    <CompoundRule Type="All"/>
  </Configuration>
</Configurations>

CAP hata ayıklama

CAP yapılandırmalarını boşaltmak için remote-process komutunu kullanabilirsiniz:

adb root && adb remount
adb shell remote-process unix:///dev/socket/audioserver/policy_debug dumpDomains

Bu işlem, geçerlilik koşulları da dahil olmak üzere tüm alanları ve yapılandırmaları gösterir. Aşağıda, Bluetooth A2DP, veri yolu cihazı ve varsayılan yapılandırmalar kullanılarak Cuttlefish otomotiv cihazından alınmış bir alıntı gösterilmektedir. Yapılandırmalar bölümüne bakın:

- ConfigurableDomain: DeviceForProductStrategies.Music.SelectedDevice =
 {Sequence aware: no, Last applied configuration: Bus}
  - Configuration: BluetoothA2dp
    - CompoundRule = All
      - SelectionCriterionRule = ForceUseForMedia IsNot NO_BT_A2DP
      - SelectionCriterionRule = ForceUseForCommunication IsNot BT_SCO
      - SelectionCriterionRule = AvailableOutputDevices Includes BLUETOOTH_A2DP
  - Configuration: Bus
    - CompoundRule = All
      - SelectionCriterionRule = AvailableOutputDevices Includes BUS
      - SelectionCriterionRule = AvailableOutputDevicesAddresses Includes BUS00_MEDIA_CARD_0_DEV_0
  - Configuration: Default
    - CompoundRule = All

CAP parametre çerçevesinde hata ayıklamak için kullanılabilecek diğer komutlar hakkında daha fazla bilgi edinmek için bu aracı kullanın:

adb shell remote-process unix:///dev/socket/audioserver/policy_debug help

Aracı kullanmak için OEM üreticilerinin cihazda ayarlamaya izin vermesi gerekir. Cihazın ayarlamaya izin verip vermediğini doğrulamak için aşağıdaki komutu kullanın:

adb shell cat /system/etc/parameter-framework/ParameterFrameworkConfigurationCap.xml

Android 15 ve önceki sürümlerde dosya farklı olabilir. Bu nedenle, aşağıdaki komutu kullanın:

adb shell cat /system/etc/parameter-framework/ParameterFrameworkConfigurationPolicy.xml

Dosya, ilgili sunucu bağlantı noktasıyla birlikte TuningAllowed="true" içermelidir:

<?xml version="1.0" encoding="UTF-8"?>
<ParameterFrameworkConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    SystemClassName="Policy" TuningAllowed="true" ServerPort="unix:///dev/socket/audioserver/policy_debug">
    <SubsystemPlugins>
        <Location Folder="">
            <Plugin Name="libpolicy-subsystem.so"/>
        </Location>
    </SubsystemPlugins>
    <StructureDescriptionFileLocation Path="Structure/Policy/CapClass.xml"/>
</ParameterFrameworkConfiguration>

Bu dosya, derleme görüntüsünün türüne göre otomatik olarak oluşturulur (veya eski derleme için yayın ya da hata ayıklama için farklı bir dosya kullanın). Yayın derlemesi, TuningAllowed değerini soket bağlantı noktası olmadan false olarak ayarlar (yayın derlemelerinde soketlere izin verilmez). Mühendislik ve userdebug derlemeleri, kullanılan soket bağlantı noktasıyla true olarak ayarlar. Bu dosyanın, audio_policy_pfw_toplevel tarafından başvurulan dosya olduğunu unutmayın. Uzak işlem aracı, cihazın üreticisi veya derleme dosyasına da dahil edilmelidir:

# Tool used for debug Parameter Framework (only for eng and userdebug builds)
PRODUCT_PACKAGES_DEBUG += remote-process

Soketlere izin vermek için ilgili SELinux politikası da eklenmelidir. Bu yalnızca hata ayıklama modunda çalışır. Çünkü yayın modu, soketlere açıkça izin vermez:

BOARD_SEPOLICY_DIRS += frameworks/av/services/audiopolicy/engineconfigurable/sepolicy

Android 16'da CAP'ye geçiş

AIDL ses HAL CAP motoru ve önceki sürümlerin getirdiği büyük değişiklikler nedeniyle dikkate almanız gereken çeşitli cihaz geçişi senaryoları vardır. Bu bölümde en belirgin geçiş senaryoları ele alınmakta ve CAP motoru yapılandırmasının etkinleştirilmesi için yapılması gereken çalışmalarla ilgili öneriler verilmektedir.

1. senaryo: Android 16 veya sonraki sürümlerin kullanıldığı yeni cihazda, cihaz CAP yapılandırması için önceki bir kaynak yok

Yeni bir cihaz, vendor bölümünde Android 16 veya sonraki bir sürümle başlatılmalıdır. Bu nedenle, yapılandırılabilir ses politikası motoru yapılandırmasını AIDL ses HAL arayüzü üzerinden kullanıma sunması gerekir. Cihaz CAP motoru yapılandırması örneklerden kopyalanmalıdır. vendor bölümünde PfW CAP alan tanımı olmamalıdır.

Cihazda kullanılan sistem görüntüsü Android 16 veya sonraki bir sürüm olmalıdır. Ses hizmeti çerçevesi, CAP yapılandırmasını AIDL ses HAL arayüzü aracılığıyla keşfeder. Bu nedenle, PfW'yi sistem görüntüsündeki PfW CAP alanı tanımını kullanarak başlatır ve AIDL aracılığıyla alınan cihaz CAP yapılandırmasını yükler.

Örnek olarak, bu değişiklikte tanıtılan ve gerekli yapılandırma dosyalarını ayarlamak için gereken dosyalar, derleme kuralları ve make dosyaları için referans olarak kullanılabilecek otomotiv Cuttlefish sanal cihazını inceleyin. Bu, varsayılan AIDL ses HAL'sinde sağlanan yükleyicilerle çalışır.

2. senaryo: CAP kullanan önceki bir cihazdan Android 16 veya sonraki bir sürümü kullanan yeni cihaza geçiş

Yeni bir cihaz, vendor bölümünde Android 16 veya sonraki bir sürümle başlatılmalıdır. Ancak OEM'nin kullanılabilir bir cihaz CAP motoru yapılandırması olduğundan, OEM bunu başlangıç noktası olarak kullanmak (veya tamamen yeniden kullanmak) isteyebilir. CAP yapılandırmasının AIDL sürümünde Android 15 ve önceki sürümlere kıyasla bazı değişiklikler yapıldığından tedarikçinin mevcut yapılandırmayı AIDL'ye dönüştürmesi gerekir. Gerekli değişiklikler için Android 16 ve önceki sürümler arasındaki değişiklikler hakkında Ürün stratejileri bölümündeki tartışmaya bakın. Genel olarak, ses çerçevesi CAP yapılandırmasını 1. senaryodakiyle aynı şekilde keşfedip yükler.

Senaryo 3: CAP'si olan mevcut bir cihazda yalnızca sistem bölümü Android 16'ya güncelleniyor

Bu senaryoda, vendor bölümü, cihazın CAP yapılandırmasının Android 15 ve önceki sürümlerini ve PfW CAP alanı tanımını içerir. vendor bölümüne dokunulmadığı için HIDL HAL kullanılmaya devam eder. Çerçeve, Android 15 ve önceki sürümlerdeki senaryoyu izler ve CAP ile ilgili tüm yapılandırmaları vendor bölümünden yükler.

4. senaryo: CAP'nin bulunduğu, Android 15'te piyasaya sürülmüş mevcut cihaz

Android 15'te AIDL'de CAP desteklenmediğinden bazı satıcılar, ses çerçevesi tarafından yüklenen AIDL Audio HAL ve CAP ile yeni cihazlar piyasaya sürdü. Bu karma mod resmi olmasa da Android 16'ya dahil edilmiştir. Bu modun, Android 16'da yeni cihazları yayınlamak için değil, Android 15 satıcısı olan mevcut cihazların Android 16'ya (system bölüm güncellemesi) güncellenmesini sağlamak için kullanılması gerektiğini unutmayın.

Ses çerçevesi, CAP yapılandırması olmadan AIDL ses HAL'i ses yapılandırmasını keşfeder. CAP yapılandırması için ses politikası hizmeti (audio framework), CAP yapılandırmasını vendor bölümünden yüklemeye geri döner. Bu durumda hem PfW CAP alan tanımı hem de cihaz CAP yapılandırması vendor bölümünden yüklenmelidir.

CAP taşıma özeti

Aşağıdaki tabloda, uyumlu sistem ve satıcı yapılandırmaları ile CAP yapılandırması için gerekenler özetlenmiştir: