Android 14 में, कार ओईएम प्लग-इन की नई सेवाओं की मदद से, कार के कुछ कॉम्पोनेंट को कॉन्फ़िगर किया जा सकता है. खास तौर पर ऑडियो के लिए, प्लग-इन की तीन नई सेवाएं लॉन्च की गई हैं. इनकी मदद से, ओईएम AAOS डिवाइसों पर ऑडियो मैनेजमेंट को फ़्लेक्सिबली कॉन्फ़िगर कर सकते हैं:
- ऑडियो फ़ोकस कंट्रोल
- ऑडियो वॉल्यूम और म्यूट कंट्रोल
- ऑडियो डकिंग कंट्रोल
कार प्लग-इन सेवा का आर्किटेक्चर
नीचे दी गई इमेज में, कार की सेवाओं और ओईएम की कार सेवा के बीच के संबंध की खास जानकारी दी गई है. ऐप्लिकेशन की प्रोसेस और कार सेवा की प्रोसेस की तरह, ओईएम की कार सेवा की प्रोसेस भी अपनी प्रोसेस स्पेस में होती है.
कार सेवा, config_oemCarService में तय किए गए कॉम्पोनेंट को ढूंढकर, ओईएम की कार सेवा शुरू करती है. अगर कॉन्फ़िगरेशन खाली है, तो ओईएम की सेवा मौजूद नहीं होती और कोई सेवा शुरू नहीं की जाती. कॉम्पोनेंट को
OemCarService तक बढ़ाया जाना चाहिए.
कार ऑडियो सेवा को, कार ऑडियो ओईएम सेवा पाने के लिए एपीआई को ओवरराइट करना होगा:
public final class OemCarServiceImp extends OemCarService {
@Override
public OemCarAudioFocusService getOemAudioFocusService();
@Override
public OemCarAudioDuckingService getOemAudioDuckingService();
@Override
public OemCarAudioVolumeService getOemAudioVolumeService();
}
उदाहरण
के लिए, रेफ़रंस टेस्ट ऐप्लिकेशन देखें जो
packages/services/Car/tests/OemCarServiceTestAppमें तय किया गया है.
सेवा, कार सेवा से शुरू होती है. हालांकि, इसे कार ऑडियो सेवा के लिए उपलब्ध अनुमतियां अपने-आप नहीं मिलतीं. इसलिए, ओईएम की सेवाओं के लिए ज़रूरी कोई भी अनुमति, सही तरीके से हासिल की जानी चाहिए. उदाहरण के लिए, packages/services/Car/data/etc/com.android.car.oemcarservice.testapp.xml देखें.
ओईएम सेवा के आर्किटेक्चर के साथ कार ऑडियो सेवा
AAOS में, कार ऑडियो सेवा इन कार्रवाइयों को मैनेज करती है:
- ऑडियो रूटिंग
- ऑडियो फ़ोकस
- ऑडियो डकिंग
- वॉल्यूम और म्यूट
Android 14 से पहले, यह व्यवहार ज़्यादातर स्टैटिक था और इसमें सिर्फ़ सेटिंग के ज़रिए बदलाव किया जा सकता था. हालांकि, यह बदलाव बहुत कम मामलों में किया जा सकता था. Android 14 में, कार ऑडियो सेवा के लिए एक ऐसा तरीका लॉन्च किया गया है जिससे ओईएम की तय की गई किसी कॉम्पोनेंट के साथ कम्यूनिकेट किया जा सकता है. यह कॉम्पोनेंट इन चीज़ों को मैनेज करता है:
- ऑडियो फ़ोकस
- ऑडियो डकिंग
- वॉल्यूम और म्यूट
नीचे दी गई इमेज में, कार ऑडियो सेवा और कार ओईएम सेवा के लिए, आसान आर्किटेक्चर दिखाया गया है. कार ऑडियो सेवा, अलग-अलग हुक तय करती है. इनकी मदद से, ऑडियो के व्यवहार को मैनेज करने के लिए, कार ओईएम ऑडियो सेवा को कॉल किया जा सकता है. ऐसा सिर्फ़ तब होता है, जब ओईएम की कार ऑडियो सेवा का कॉम्पोनेंट तय किया गया हो. अन्यथा, कार ऑडियो सेवा डिफ़ॉल्ट व्यवहार का इस्तेमाल करती है.
यह पक्का करने के लिए कि कार ऑडियो सेवा और कार ओईएम ऑडियो सेवा हमेशा सिंक में रहें, कार ऑडियो सेवा हर कॉल के लिए, ऑडियो स्टैक की मौजूदा स्थिति के ज़रूरी हिस्सों को कार ओईएम ऑडियो सेवा को पास करती है. उदाहरण के लिए, जब कार ऑडियो सेवा, ऑडियो फ़ोकस का आकलन करने के लिए किसी अनुरोध को इंटरसेप्ट करती है, तो वह स्टैक की मौजूदा स्थिति को कार ओईएम ऑडियो सेवा को पास करती है. मौजूदा स्थिति में, मौजूदा फ़ोकस होल्डर और मौजूदा फ़ोकस लूज़र शामिल होते हैं. फ़ोकस लूज़र, फ़ोकस के ऐसे अनुरोध होते हैं जो अब भी स्टैक का हिस्सा हैं, लेकिन जिन्होंने अस्थायी तौर पर फ़ोकस खो दिया है.
कार में ऑडियो से जुड़ी सभी गतिविधि को कार ऑडियो सेवा मैनेज करती है. अगर कार ऑडियो सेवा, ऑडियो के व्यवहार के कुछ हिस्सों को मैनेज नहीं करती है, तो कार ओईएम ऑडियो सेवा को दिखाई जाने वाली जानकारी अधूरी होती है. उदाहरण के लिए, अगर कोई ओईएम, अपनी ऑडियो फ़ोकस नीति रजिस्टर करके, कार सेवा में ऑडियो फ़ोकस को मैनेज करने की सुविधा को ओवरराइट करता है, तो कार ऑडियो सेवा, कार ओईएम ऑडियो सेवा को पूरी जानकारी नहीं दे सकती. इससे, कार ओईएम ऑडियो सेवा के फ़ैसले लेने की क्षमता पर असर पड़ सकता है, क्योंकि हो सकता है कि उसके पास ऐसी जानकारी न हो जो कार ऑडियो सेवा को नहीं दिखती.
कार्रवाई करने के लिए, कार ऑडियो सेवा, ओईएम की कार सेवाओं को कॉल करती है. ये कॉल, अलग-अलग प्रोसेस के ज़रिए किए जाते हैं. इसके लिए, इंटर-प्रोसेस कम्यूनिकेशन (आईपीसी) की ज़रूरत होती है. आईपीसी से, हर कॉल में देरी होती है. ओईएम की सेवा में देरी को कम करना ज़रूरी है.
ओईएम की सेवा को कार ऑडियो सेवा के कॉल ब्लॉक करने की अनुमति है. इसलिए, ओईएम की सेवा को डायरेक्ट एपीआई के आकलन के लिए, कार ऑडियो सेवा को कॉल नहीं करना चाहिए. इसके बजाय, कार ऑडियो सेवा ज़रूरी जानकारी उपलब्ध कराती है, ताकि दोनों प्रोसेस के बीच कॉल सिर्फ़ एक दिशा में किए जा सकें.
ओईएम की कार ऑडियो सेवा की परिभाषाएं
ओईएम की कार ऑडियो फ़ोकस सेवा
कार ऑडियो सेवा, ऑडियो नीति के फ़ोकस लिसनर को रजिस्टर करके, ऐप्लिकेशन से मिले ऑडियो फ़ोकस के अनुरोधों को मैनेज करती है. कार ऑडियो सेवा के पास, स्टैटिक इंटरैक्शन मैट्रिक्स के आधार पर, फ़ोकस के व्यवहार को मैनेज करने का एक तरीका है. मैट्रिक्स में, तीन तरह के इंटरैक्शन तय किए जाते हैं:
एक साथ इंटरैक्शन. फ़ोकस होल्डर, एक ही समय पर फ़ोकस बनाए रख सकते हैं.
एक्सक्लूसिव इंटरैक्शन. फ़ोकस का नया अनुरोध, मौजूदा फ़ोकस होल्डर से फ़ोकस छीन लेता है.
इंटरैक्शन अस्वीकार करना. मौजूदा फ़ोकस होल्डर के आधार पर, फ़ोकस का नया अनुरोध अस्वीकार कर दिया जाता है.
ऑटोमोटिव के कुछ इस्तेमाल के मामलों के लिए यह काफ़ी है. हालांकि, यह इंटरैक्शन की सभी ज़रूरतों को पूरा नहीं करता. ओईएम की ज़रूरतों की वजह से, इंटरैक्शन अलग-अलग हो सकते हैं. इसके लिए, हम OemCarAudioFocusService लॉन्च कर रहे हैं:
public interface OEmCarAudioFocusService {
OemCarAuddioFocusResults evaluateAudioFocusRequest(
OemCarAudioFocusEvaluationRequest request);
void notifyAudioFocusChange(
List<AudioFocusEntry> holder,
List<AudioFocusEntry> losers, int zoneId);
}
evaluateAudioFocusRequest एपीआई को, कार ऑडियो सेवा से तब कॉल किया जाता है, जब ऑडियो फ़ोकस के लिए कोई ऐसा अनुरोध आता है जिसका आकलन करना ज़रूरी है. यह एक टू-वे एपीआई है, जो नतीजे मिलने तक ब्लॉक रहता है. अनुरोध में, ऑडियो स्टैक की मौजूदा स्थिति के बारे में जानकारी होती है:
इस जानकारी का इस्तेमाल, focusHolders में मौजूद मौजूदा फ़ोकस होल्डर और focusLosers में मौजूद मौजूदा फ़ोकस लूज़र की तुलना में, newFocusRequest का आकलन करने के लिए किया जा सकता है. एपीआई को ये नतीजे दिखाने चाहिए:
class OemCarAudioFocusResult {
int audioZoneId;
int audioFocusEvaluationResults;
AudioFocusEntry focusResult;
List<AudioFocusEntry> newLosers;
List<AudioFocusEntry> newlyBlocked;
}
इसमें, audioFocusEvaluationResults में, आकलन के असल नतीजों के बारे में जानकारी होती है. इससे पता चलता है कि मौजूदा अनुरोध को अनुमति दी गई है, इसमें देरी हुई है या यह पूरा नहीं हुआ है. मौजूदा फ़ोकस स्टैक में किए गए किसी भी बदलाव को, स्टैक में हुए बदलाव के हिसाब से, newLosers और newlyBlocked एंट्री में सेट किया जाना चाहिए.
यहां newLosers में ऐसी एंट्री शामिल होती हैं जो पहले फ़ोकस बनाए हुए थीं, लेकिन अब उन्हें स्थायी या अस्थायी तौर पर फ़ोकस खोना चाहिए. स्थायी फ़ोकस लूज़र को, ऑडियो फ़ोकस स्टैक से हटा दिया जाएगा. वहीं, अस्थायी फ़ोकस लूज़र को, मौजूदा फ़ोकस लूज़र स्टैक में तब तक ले जाया जाएगा, जब तक वे फ़ोकस वापस हासिल नहीं कर लेते या उन्हें फ़ोकस के लिए अनुरोध करने वाले मूल व्यक्ति या कंपनी से हटा नहीं दिया जाता. इसके बावजूद, अनुरोधों के लिए फ़ोकस लिसनर को, फ़ोकस खोने की जानकारी मिलेगी.
newlyBlocked सूची में ऐसी एंट्री शामिल होती हैं जो पहले फ़ोकस लूज़र सूची में थीं, लेकिन अब नई एंट्री से ब्लॉक कर दी गई हैं. ब्लॉक स्थायी या अस्थायी हो सकता है. स्थायी फ़ोकस ब्लॉक के लिए, एंट्री को स्टैक से हटा दिया जाएगा और फ़ोकस लिसनर को फ़ोकस खोने की जानकारी भेजी जाएगी. अस्थायी फ़ोकस खोने के लिए, एंट्री फ़ोकस लूज़र स्टैक में बनी रहेगी. हालांकि, इसके ब्लॉक करने वालों की सूची में एक नया फ़ोकस ब्लॉकर जोड़ा जाएगा. फ़ोकस खोने की जानकारी नहीं भेजी जाएगी, क्योंकि पहली बार ब्लॉक किए जाने पर यह जानकारी पहले ही भेजी जा चुकी है. अनुरोध को आखिर में तब अनब्लॉक किया जाएगा, जब मौजूदा सभी ब्लॉकर हटा दिए जाएंगे. अगर फ़ोकस छोड़ दिया जाता है, तो इसे स्टैक से हटा दिया जाएगा.
दूसरा एपीआई, notifyAudioFocusChange एक वन-वे एपीआई है. इसे ऑडियो फ़ोकस के हर अनुरोध या फ़ोकस छोड़ने पर कॉल किया जाता है. इस एपीआई का इस्तेमाल ज़्यादातर, ओईएम की सेवा को फ़ोकस में हुए बदलावों के बारे में बताने के लिए किया जाता है. इससे, ओईएम की कार ऑडियो सेवा के व्यवहार पर असर पड़ सकता है.
फ़ोकस के आकलन के लिए दिशा-निर्देश
AAOS में, ऑडियो फ़ोकस का इस्तेमाल, ऑडियो चलाने की सुविधा को मैनेज करने और यह तय करने के लिए किया जाता है कि उपयोगकर्ता को बेहतर अनुभव देने के लिए, किस ऐप्लिकेशन को ऑडियो फ़ोकस बनाए रखना चाहिए. इसलिए, ओईएम के प्लग-इन की सेवा को, ऑडियो फ़ोकस के अनुरोध को मैनेज करते समय इन बातों का ध्यान रखना चाहिए:
उच्च प्राथमिकता वाले ऑडियो फ़ोकस (जैसे, फ़ोन कॉल, आपातकालीन कॉल या सुरक्षा) के बिना, ऐप्लिकेशन अस्थायी या स्थायी तौर पर ऑडियो फ़ोकस हासिल कर सकते हैं.
मीडिया फ़ोकस चालू होने पर, इन चीज़ों के लिए अनुरोध करने वाले ऐप्लिकेशन:
कॉल के इस्तेमाल के लिए फ़ोकस, एक साथ या एक्सक्लूसिव तौर पर फ़ोकस हासिल कर सकते हैं.
नेविगेशन के इस्तेमाल के लिए फ़ोकस, एक साथ या एक्सक्लूसिव तौर पर फ़ोकस हासिल कर सकते हैं.
Assistant के इस्तेमाल के लिए फ़ोकस, एक साथ या एक्सक्लूसिव तौर पर फ़ोकस हासिल कर सकते हैं.
उच्च प्राथमिकता वाले ऑडियो फ़ोकस (जैसे, फ़ोन कॉल, आपातकालीन अलर्ट या सुरक्षा अलर्ट) वाले ऐप्लिकेशन चालू होने पर, ऑडियो फ़ोकस के किसी भी ऐसे अनुरोध को अनुमति दी जानी चाहिए जिसमें देरी हुई हो. हालांकि, ज़रूरत के हिसाब से इसमें देरी की जा सकती है.
ऊपर दिए गए सुझाव पूरी सूची नहीं हैं. हालांकि, इनसे यह पक्का करने में मदद मिल सकती है कि फ़ोकस के लिए अनुरोध करने वाले ऐप्लिकेशन, उच्च प्राथमिकता वाली आवाज़ें चालू न होने पर फ़ोकस हासिल कर सकें. उच्च प्राथमिकता वाली आवाज़ें चालू होने पर भी, फ़ोकस के ऐसे अनुरोधों को प्राथमिकता दी जानी चाहिए जिनमें देरी हुई हो. साथ ही, उच्च प्राथमिकता वाली आवाज़ें बंद होने के बाद, उन्हें फ़ोकस हासिल करने की अनुमति दी जानी चाहिए.
ओईएम की कार वॉल्यूम सेवा
कार ऑडियो सेवा, आवाज़ बटन से जुड़े इवेंट को मैनेज करती है. इसके लिए, वह ऑडियो सिस्टम से वॉल्यूम में किए गए बदलावों को सुनती है या कार इनपुट सेवा से सीधे आवाज़ बटन से जुड़े इवेंट को सुनती है. हर मामले में, कार ऑडियो सेवा का डिफ़ॉल्ट व्यवहार यह तय करना होता है कि चालू ऑडियो प्लेयर और ऑडियो कॉन्टेक्स्ट की प्राथमिकता वाली सूची के आधार पर, किस वॉल्यूम ग्रुप में बदलाव करना है.
हम वॉल्यूम की प्राथमिकता वाली दो सूचियां उपलब्ध कराते हैं. पहली सूची में, सभी ऑडियो कॉन्टेक्स्ट को इस क्रम में शामिल किया जाता है. सूची को घटते क्रम में दिखाया जाता है. इसमें सबसे ज़्यादा प्राथमिकता वाले ऑडियो कॉन्टेक्स्ट सबसे ऊपर और सबसे कम प्राथमिकता वाले ऑडियो कॉन्टेक्स्ट सबसे नीचे होते हैं. उदाहरण के लिए, अगर नेविगेशन ऑडियो और संगीत ऑडियो, दोनों एक ही समय पर चालू हैं, तो वॉल्यूम के बटन से जुड़े इवेंट के दौरान, नेविगेशन की आवाज़ में बदलाव किया जाता है.
- नेविगेशन
- कॉल करें
- संगीत
- सूचना
- बोला गया निर्देश
- कॉल की घंटी यहां बजेगी
- सिस्टम ध्वनि
- सुरक्षा
- अलार्म
- सूचना
- वाहन का स्टेटस
- आपातकालीन कॉल
वॉल्यूम के बटन से जुड़े इवेंट को मैनेज करने की प्रोसेस को आसान बनाने के लिए, कार ऑडियो सेवा के पास ऑडियो कॉन्टेक्स्ट की प्राथमिकता वाली दूसरी सूची है:
- कॉल करें
- मीडिया
- सूचना
- बोला गया निर्देश
इस सूची को भी घटते क्रम में दिखाया जाता है. इस दूसरी सूची का मकसद, बटन से जुड़े इवेंट के ज़रिए, ज़्यादा सामान्य आवाज़ों में बदलाव करने की अनुमति देना है. कम सुनाई देने वाली आवाज़ों को सिर्फ़ ऑडियो सेटिंग के यूज़र इंटरफ़ेस (यूआई) के ज़रिए मैनेज किया जा सकता है. जैसे, कम समय के लिए सुनाई देने वाली आवाज़ें.
audioVolumeAdjustmentContextsVersion कॉन्फ़िगरेशन की मदद से, वॉल्यूम का असल वर्शन सेट किया जा सकता है. कॉन्फ़िगरेशन को 1 या 2 पर सेट किया जा सकता है. 2 डिफ़ॉल्ट रूप से सेट होता है.
वॉल्यूम को मैनेज करने की ज़्यादा फ़्लेक्सिबिलिटी देने के लिए, Android 14 में OemCarAudioVolumeService लॉन्च किया गया है:
public interface OemCarAudioVolumeService {
OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}
ओईएम की कार ऑडियो वॉल्यूम सेवा में एक ही तरीका है. इसमें volumeAdjustment और OemCarAudioVolumeRequest शामिल होते हैं:
class OemCarAudioVolumeRequest {
int audioZoneId;
int callState;
List<AudioAttributes> activePlaybackAttributes;
List<AudioAttributes> duckedAttributes;
List<CarVolumeGroupInfo> volumeGroupState;
}
अनुरोध के activePlaybackAttributes में, चालू ऑडियो एट्रिब्यूट होते हैं. duckedAttributes में, फ़िलहाल डक किए गए सभी ऑडियो एट्रिब्यूट होते हैं. volumeGroupState में, वॉल्यूम ग्रुप की मौजूदा स्थिति होती है. अनुरोध, ऑडियो स्टैक की मौजूदा स्थिति को दिखाता है. इसका इस्तेमाल यह तय करने के लिए किया जा सकता है कि किस वॉल्यूम ग्रुप में बदलाव करना है. नतीजे, OemCarVolumeChangeInfo में दिखाए जाने चाहिए:
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
change बूलियन से पता चलता है कि किसी वॉल्यूम में बदलाव हुआ है या नहीं. true का मतलब है कि बदलाव हुआ है और वॉल्यूम ग्रुप को अपडेट किया जाना चाहिए. volumeGroupChanged वह असल वॉल्यूम ग्रुप है जिसमें बदलाव किया जाना चाहिए. इस ग्रुप में बदलाव, एपीआई को पास किए गए ओरिजनल volumeAdjustment पैरामीटर के हिसाब से किया जाना चाहिए. उदाहरण के लिए, अगर नतीजों से पता चलता है कि नेविगेशन वॉल्यूम ग्रुप को म्यूट किया जाना चाहिए, तो बूलियन true होगा और दिखाया गया वॉल्यूम ग्रुप, नेविगेशन के लिए होगा.
ओईएम की कार डकिंग सेवा
कार ऑडियो सेवा, ऑडियो फ़ोकस में हुए बदलावों की निगरानी करके और AudioControl HAL को यह सिग्नल भेजकर, ऑडियो डकिंग को मैनेज करती है कि किन ऑडियो डिवाइस को डक करना है.
फ़ोकस में बदलाव होने पर, चालू सभी फ़ोकस होल्डर का आकलन किया जाता है, ताकि यह तय किया जा सके
कि डकिंग के इन स्टैटिक डकिंग
नियमोंके आधार पर, किसे डक करना है:
- आपातकालीन स्थितियों वाली आवाज़ें, कॉल की आवाज़ों को छोड़कर बाकी सभी आवाज़ों को डक करती हैं
- सुरक्षा से जुड़ी आवाज़ें, आपातकालीन स्थितियों वाली आवाज़ों को छोड़कर बाकी सभी आवाज़ों को डक करती हैं
- नेविगेशन की आवाज़ें, सुरक्षा और आपातकालीन स्थितियों वाली आवाज़ों को छोड़कर बाकी सभी आवाज़ों को डक करती हैं
- कॉल की आवाज़ें, सुरक्षा, आपातकालीन स्थितियों वाली और नेविगेशन की आवाज़ों को छोड़कर बाकी सभी आवाज़ों को डक करती हैं
- वॉइस कमांड की आवाज़ें, कॉल की घंटी की आवाज़ों को डक करती हैं
- संगीत और सूचनाओं की आवाज़ें, सभी आवाज़ों को डक करती हैं
ये नियम पूरी सूची नहीं हैं. ओईएम को इन दिशा-निर्देशों के आधार पर यह तय करना होगा कि आवाज़ों को कैसे डक करना है. ओईएम, उपलब्ध ज़रूरी शर्तों के आधार पर, इन सुझावों को ज़्यादा सक्रियता से कंट्रोल कर सकते हैं. Android 14 में OemCarDuckingService लॉन्च किया गया है:
class OemCarAudioDuckingService {
List<AudioAttributes> evaluateAttributesToDuck(
OemCarAudioVolumeRequest request);
}
इस एपीआई को, कार ऑडियो सेवा से ऑडियो फ़ोकस में हुए बदलावों पर कॉल किया जाता है. यह ओईएम की कार वॉल्यूम सेवा में लॉन्च किए गए OemCarAudioVolumeRequest का फिर से इस्तेमाल करता है. इसमें, यह तय करने से जुड़ी ज़रूरी जानकारी होती है कि किन एट्रिब्यूट को डक करना है. एपीआई से डक किए जाने वाले ऑडियो एट्रिब्यूट की सूची की तुलना, ऑडियो की मौजूदा स्थिति से की जाती है:
फ़िलहाल डक किया गया ऑडियो एट्रिब्यूट:
- सूची में शामिल है, इसलिए डक किया जाता रहेगा
- सूची में शामिल नहीं है, इसलिए डकिंग बंद कर दी गई है
फ़िलहाल डक नहीं किया गया ऑडियो एट्रिब्यूट:
- सूची में शामिल है, इसलिए डक किया गया है
- सूची में शामिल नहीं है, इसलिए डकिंग बंद कर दी गई है
इसके बाद, कार ऑडियो सेवा यह तय करती है कि ऑडियो एट्रिब्यूट, किन ऑडियो आउटपुट डिवाइस से जुड़े हैं. इसके बाद, उन्हें क्रमशः डक किए गए ऑडियो आउटपुट डिवाइस की सूची या अनडक किए गए ऑडियो डिवाइस की सूची में जोड़ती है. इसे आखिर में, हार्डवेयर लेवल पर ज़रूरी डकिंग करने के लिए, AudioControl HAL को भेजा जाता है.
नीचे दी गई इमेज में, ओईएम की डकिंग सेवा का इस्तेमाल करने पर, फ़ोकस के अनुरोध के लिए, ऑडियो डकिंग कंट्रोल का आसान क्रम डायग्राम दिखाया गया है:
यह क्रम तब शुरू होता है, जब कोई ऐप्लिकेशन,
ऑडियो फ़ोकस को मैनेज करने
का अनुरोध, पब्लिक ऑडियो मैनेजर एपीआई के ज़रिए करता है. नतीजे तय करने के लिए, अनुरोध को कार ऑडियो सेवा को फ़ॉरवर्ड किया जाता है. ऑडियो फ़ोकस तय होने पर, कार ऑडियो सेवा, OemCarAudioDuckingService को कॉल करके, ऑडियो डकिंग का आकलन करती है. इससे यह तय किया जाता है कि किन ऑडियो एट्रिब्यूट को डक करना है. evaluateAttributesToDuck एपीआई से नतीजे मिलने के बाद, डक किए जाने वाले ऑडियो डिवाइस तय किए जाते हैं. इसके बाद, जानकारी को AudioControl को भेजा जाता है, ताकि ऑडियो हार्डवेयर पर डकिंग लागू की जा सके.
ओईएम की कार ऑडियो सेवा का रेफ़रंस लागू करने का तरीका
AAOS,
packages/services/Car/tests/OemCarServiceTestApp में, ओईएम की कार सेवा को लागू करने का रेफ़रंस उपलब्ध कराता है. इसमें
OemCarService, साथ ही OemCarAudioFocusService,
OemCarAudioDuckingService, और OemCarAudioVolumeService लागू किए जाते हैं. इनमें से हर सेवा, स्टैटिक व्यवहार लोड करने के लिए, एक्सएमएल फ़ाइल का इस्तेमाल करती है. उदाहरण के लिए, OemCarAudioFocusServiceImp, oem_focus_config.xml लोड करता है. इसमें इंटरैक्शन मैट्रिक्स शामिल होता है. मैट्रिक्स का इस्तेमाल, evaluateAudioFocusRequest को कॉल किए जाने पर, फ़ोकस के अनुरोध का आकलन करने के लिए किया जाता है.
रेफ़रंस टेस्ट ऐप्लिकेशन को डीबग करना
ओईएम की कार सेवा का टेस्ट ऐप्लिकेशन, AOSP के सोर्स कोड का हिस्सा है. ओईएम, अपनी ज़रूरतों के हिसाब से इसमें बदलाव कर सकते हैं. डीबग करने के लिए, टेस्ट ऐप्लिकेशन को चालू करने के लिए, config_oemCarService कॉन्फ़िगरेशन का इस्तेमाल करें.
<!-- 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>
यह पुष्टि करने के लिए कि ओईएम की कार सेवा, ओईएम की सेवा के लिए, कार सेवा के dump कमांड का इस्तेमाल करती है:
adb shell dumpsys car_service --oem-service
नतीजे, नीचे दिए गए आउटपुट की तरह हो सकते हैं:
***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
dump की जानकारी के हर बैच में मौजूद हर बूलियन, सुविधा और सेवा की स्थिति तय करता है. उदाहरण के लिए, डंप की जानकारी mIsOemServiceReady से यह पता चलता है कि सेवा इस्तेमाल के लिए तैयार है या नहीं. इसमें true का मतलब है कि सेवा इस्तेमाल के लिए तैयार है और false का मतलब है कि सेवा इस्तेमाल के लिए तैयार नहीं है.