Yapılandırılabilir ses politikası motoru

Android 14'te Android Automotive Operating System (AAOS), birincil ses bölgesindeki yapılandırılabilir ses politikası (CAP) motoru araba ses yönetiminden yararlanır. Daha açık belirtmek gerekirse CAP motoru, AAOS'un yalnızca ses yönlendirmeyi, yalnızca ses hacmini veya hem yönlendirmeyi hem de hacmi aynı anda kontrol etmesine olanak tanır. Davranışı kontrol etmek için aşağıdaki işaretçiler kullanılabilir:

• CAP ses düzeyi yönetimini etkinleştirmek için useCoreAudioVolume işaretini kullanın. Bu değer true olduğunda araç ses hizmeti, ses gruplarını yönetmek için ses yöneticisi API'lerini kullanır.

• CAP ses yönlendirme yönetimini etkinleştirmek için useCoreAudioRouting işaretini kullanın. Bu değer true olduğunda, araç 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 ses politikası motoru şeklinde varsayılan olarak da desteklenir.

Arka plan

CAP motoru, parametreleri işlemek için eklenti tabanlı ve kural tabanlı bir çerçeve olan Intel'in parametre çerçevesini temel alır. CAP motoru, özellikle Android ses yönetimi için aşağıdakileri belirtmek üzere XML dosyası kuralları tanımlama olanağı sundu:

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

Android 16'dan önceki CAP başlatma

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

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

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

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ı bilgi 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ı

Ses politikası hizmeti, yapıyı ve ayarları almak için 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 bir yapı sağlanır. Yapı bilgileri, ürün stratejisi yapı bilgilerini gerektirir. Bu nedenle Android, mevcut ürün stratejisi XML dosyasından bilgi oluşturabilen buildStrategiesStructureFile.py oluşturma aracını sağlar. Buna, genrule default buildstrategiesstructurerule aracılığıyla aşağıdaki gibi 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ını ifade eder. Bu otomotiv örneği, otomotiv klasöründeki ses politikası yapılandırma dosyalarına referans verir. Diğer örneklerde, dosyaları cihazın tedarikçi bölümüne aktarmak için bir derlemenin nasıl yapılandırılacağı gösterilmektedir.

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

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

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

Android, ses politikası motoru yapılandırması 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'si ilk başlatılması

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

Şekil 3. Android 16'dan itibaren CAP motoru yapılandırma yönetimi.

Ses politikası hizmeti, cihazın tedarikçi bölümündeki XML dosyalarındaki bilgileri ayrıştırmak yerine doğrudan AIDL Audio HAL API'lerini kullanarak CAP motor 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ırma, ürün stratejileri, hacim grupları ve ölçütlerle ilgili bilgileri eksiksiz olarak belirtmelidir.

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

Şekil 5. 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ükleyicisi

HIDL'den AIDL'ye geçişi kolaylaştırmak için varsayılan ses AIDL ses HAL'i bir XML CAP motor yükleyicisi sağlar. Tedarikçi firmalar, ses HAL'lerini varsayılan ses HAL'iyle genişleterek veya libaudioserviceexampleimpl kitaplığına referans vererek 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'i tarafından da elde edilmesidir.

Tedarikçi firmalar, ses politikası motoru yapılandırmasından elde edilen bilgileri kullanarak yapılandırılabilir alanları oluşturmak için domaingeneratorpolicyrule aracını kullanabilir. Otomotiv Mürekkep Balığı sanal cihaz örneği referans olarak kullanılabilir.

AIDL yapılandırmasında yapı

Android 16 ve sonraki sürümlerde ses politikası hizmeti, ParameterFrameworkConfigurationCap.xml dosyasını okuyup ayrıştırarak yapı bilgilerini alır. Özellikle yapı açıklaması dosyasından bilgi alır:

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

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

Yapı, kontrol edilmesi gereken parametreleri temsil eder. Bu nedenle, yapılandırmada veya alanlarda bu parametrelere referans verilmelidir. Bunun için AIDL motor yapılandırması, parametreler için önceden belirlenmiş bir ad kullanmalıdır. Ürün stratejileri için yapılar CapProductStrategies.xml'te yapılandırılır.

Varsayılan ürün stratejileri

Ürün stratejileri, varsayılan motorda sağlanan varsayılanlardan başlayarak STRATEGY_ ön ekiyle 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) için bazı sonuçlar doğurur. Özellikle tüm ürün stratejisi referansları, yeni adların kullanılacağı şekilde değiştirilmelidir. Örneğin:

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

Yapılandırılabilir motor, OEM'lerin ürün stratejileri tanımını değiştirmesine olanak tanır. Bu desteği sürdürmek için ürün stratejisi dosyası CapProductStrategies.xml, vx_1000 ile vx_1039 arasında 40 tedarikçi firma tarafından genişletilebilir ürün stratejisi de sağlar. Tüm satıcı uzantıları vx_ ön ekiyle 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ında AudioHALProductStrategy nesnesinden alınır.

Varsayılan ürün stratejilerine benzer şekilde, tedarikçi firma tarafından tanımlanan OEM referansları da AIDL dışı 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 edildiğini ve gruplandırıldığını özelleştirmenizi sağlar. Bu sayede, ses cihazlarının nasıl yönlendirildiği ve ses seviyelerinin nasıl yönetildiği de dahil olmak üzere ses cihazlarını yapılandırma konusunda daha fazla esneklik elde edebilirsiniz. Her ürün stratejisinde, söz konusu ürün stratejisiyle ilişkilendirilmesi gereken yayınları tanımlayan bir veya daha fazla ses özelliği grubu bulunabilir. Bu ses özellikleri grupları, sesleri kategorize etmek için daha ayrıntılı bir yaklaşım sağlar ve aşağıdaki türlerin bir karışımı olabilir:

• Kullanım türleri, bir sesin neden çalındığını (ör. medya, bildirim, arama) açıklar.
• İçerik türü türleri, oynatılan içeriği (ör. müzik, konuşma, video, seslendirme) tanımlar.
• Bayrak türleri, akışla ilgili farklı davranışları veya istekleri tanımlar.
• Etiketler türleri, tedarikçi firma dize değerlerinin herhangi bir 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. Sırasıyla ses kullanımı aracı ve oyun olmak üzere iki ses özelliği içerir. Bu ürün stratejisi, araç ses hizmetinde kullanılan MUSIC ses bağlamıyla eşleşiyor ancak bu tür bir eşleşme şartı yoktur. Android ile birlikte CAP kullanan OEM'ler için en önemli özelliklerden biri, daha esnek ses gruplandırma tanımlarına izin vermesidir.

Ses seviyesi grupları

Ayrıca her ses özelliği grubunun ilişkili bir ses seviyesi grubu olmalıdır. Bu ses seviyesi grubu, ses özelliği grubuna ait ses özellikleriyle eşleşen tüm akışlarla ilişkilidir. Ürün stratejileri bölümündeki örnek müzik ürün stratejisinde media ses grubu bulunur ve medya ses grubu şu şekilde tanımlanır:

<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 dizini
• Grup maksimum dizini
• Ses grubu eğrileri

Ses grubu eğrileri, ses grubu dizini ile milibasta ses kazancı arasında noktasal eşleme içerir. Sağlanan noktalar, hacim yönetilirken en iyi eşleşen kazancı doğrusal olarak ayrıştırmak için kullanılır. Her ses grubu eğrisi bir cihaz türü kategorisiyle (ör. 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 yayın başlatıldığında, medya ses grubu için son ayarlanan ses dizini kullanılır. Bu durumda, seçilen cihaza göre ilgili cihaz kategorisi eğrisi seçilir ve akış başlatıldığında ilgili kazanç ayarlanır.

Yapılandırmalar

CAP motorunda, sesin nasıl davranacağını 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ı, mantığı çözülmesi gereken daha küçük yönlendirme sorunlarına (ör. 1. cihaz, 2. cihaz) bölmektir.

Her alanın yapılandırmaları ve her yapılandırmada 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ış cihazı adresleri
• Kullanım alanı:
  • Medya
  • İletişim
  • Kayıt
  • Yuva
  • Sistem
  • Hdmi sistem sesi
  • Kodlanmış surround
  • Titreşimli zil sesi

Her alan, davranışı etkilemesi gereken kuralları belirten 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ırmayla ilgili 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çimiyle ilgili farklı kuralların nasıl uygulanacağını tanımlar. Mavi kısımlar dikkate alınması gereken kuralları, yeşil kısım ise uygulanan yapılandırmayı açıklar. Bu örnekte aşağıdaki yapılandırmalar yer alır:

• Müzik ürünü stratejisi için Bluetooth A2DP cihazı seçin (1000 kimliği, vx_1000)
  • Medya için kullanılırsa A2DP hariç tutulmaz
  • İletişim için kullanılıyorsa BT SCO'su değildir
  • Mevcut cihazlar varsa BT A2DP'yi ekleyin
• Veri yolu cihazını seçin
  • Otobüs cihazları mevcutsa
  • 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ımlayarak parametre çerçevesi (PFW) dosyalarını derleme sistemi üzerinden çalıştırın:

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ı bağımsız değişkenidir. 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ı 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 dosyası listesi (her biri tek bir <ConfigurableDomain> etiketi içerir).

Derlemede oluşturma kuralı çalıştırıldıktan sonra PolicyConfigurableDomains.xml tüm alan adlarıyla oluşturulur. Aşağıda, PfW kurallarının kullanıldığı örnekte oluşturulan dosyanın bir bölümü 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ı dökmek için remote-process simgesini kullanabilirsiniz:

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

Burada, geçerlilik koşulları da dahil olmak üzere tüm alanlar ve yapılandırmalar gösterilir. Aşağıda, Bluetooth A2DP, otobüs cihazı ve varsayılan yapılandırmaları kullanan Cuttlefish otomotiv cihazından 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ıklama için kullanılabilen diğer komutlar hakkında daha fazla bilgi için şu aracı kullanın:

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

Aracı kullanmak için OEM üreticilerin 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 sürüm veya hata ayıklama için farklı bir dosya kullanılır). Sürüm derlemesi, soket bağlantı noktası olmadan TuningAllowed değerini false olarak ayarlar (sürüm derlemelerinde soketler bu amaç için yasaktır). Mühendislik ve userdebug derlemeleri, kullanılan soket bağlantı noktasıyla birlikte bu değeri true olarak ayarlar. Bunun, audio_policy_pfw_toplevel tarafından referans verilen dosya olduğunu unutmayın. Uzak işlem aracı, cihazın make veya derleme dosyasına da eklenmelidir:

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

Soketlere izin veren ilgili SELinux politikası da eklenmelidir. Bu yöntem yalnızca hata ayıklama modunda çalışır çünkü yayın modunda soketlere açıkça izin verilmez:

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

Android 16'da CAP taşıma

AIDL ses HAL CAP motoru ve önceki sürümlerin getirdiği önemli değişiklikler göz önüne alındığında, dikkate almanız gereken çeşitli cihaz geçiş senaryoları vardır. Bu bölümde, en belirgin geçiş senaryoları ele alınmakta ve CAP motor yapılandırmasını etkinleştirmek için yapılması gereken çalışmalarla ilgili öneriler sunulmaktadır.

1. senaryo: Android 16 veya sonraki bir sürümü kullanan yeni cihaz, cihaz CAP yapılandırması için önceki kaynak yok

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

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

Örneğin, bu değişiklik kapsamında kullanıma sunulan ve gerekli yapılandırma dosyalarını oluşturmak için gereken dosyalar, derleme kuralları ve make dosyaları için referans olarak kullanılabilen otomotiv Cuttlefish sanal cihazına bakın. Bu, varsayılan AIDL ses HAL'inde sağlanan yükleyicilerle çalışır.

2. senaryo: CAP kullanan önceki bir cihazdan Android 16 veya sonraki bir sürümü kullanan yeni cihaz

Yeni cihaz, vendor bölümünde Android 16 veya sonraki bir kodla başlatılmalıdır. Ancak OEM, kullanılabilir bir cihaz CAP motoru yapılandırmasına sahip olduğundan bunu başlangıç noktası olarak kullanmak (veya tamamen yeniden kullanmak) ister. CAP yapılandırmasının AIDL sürümünde, Android 15 ve önceki sürümlere kıyasla bazı değişiklikler vardır. Bu nedenle tedarikçi firma, mevcut yapılandırmayı AIDL'ye dönüştürmelidir. Android 16 ile önceki sürümler arasındaki değişiklikler için gereken değişikliklerle ilgili olarak Ürün stratejileri bölümündeki tartışmaya bakın. Genel olarak ses çerçevesi, CAP yapılandırmasını 1. senaryoda olduğu gibi bulur ve yükler.

Senaryo 3: CAP'ye sahip mevcut cihaz yalnızca sistem bölümünü Android 16'ya güncelliyor

Bu senaryoda vendor bölümü, cihaz 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'i kullanmaya devam eder. Çerçeve, Android 15 ve önceki sürümlerin senaryosunu takip eder ve CAP ile ilgili tüm yapılandırmayı vendor bölümünden yükler.

4. senaryo: Android 15'te kullanıma sunulan mevcut cihaz, CAP ile

Android 15'te CAP, AIDL'de desteklenmediğinden bazı tedarikçiler, ses çerçevesi tarafından yüklenen AIDL Audio HAL ve CAP içeren yeni cihazlar piyasaya sürdü. Bu karma mod resmi değildi ancak Android 16'ya dahil edildi. Bu modun, Android 16 çalıştıran yeni cihazların piyasaya sürülmesi için değil, Android 15 tedarikçi firmaya sahip 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 ses yapılandırmasını keşfeder. CAP yapılandırması için ses politikası hizmeti (ses çerçevesi), CAP yapılandırmasını vendor bölümden 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, CAP yapılandırmasıyla uyumlu sistem ve tedarikçi firma yapılandırmaları ve gereksinimleri özetlenmiştir: