Android 14 में, कार के OEM प्लगिन की नई सेवाएं उपलब्ध हैं. इनकी मदद से, कार के कुछ कॉम्पोनेंट को कॉन्फ़िगर किया जा सकता है. खास तौर पर ऑडियो के लिए, तीन नई प्लग-इन सेवाएं लॉन्च की गई हैं. इनकी मदद से, OEM AAOS डिवाइसों पर ऑडियो मैनेजमेंट को आसानी से कॉन्फ़िगर कर सकते हैं:
- ऑडियो फ़ोकस कंट्रोल
- ऑडियो की आवाज़ और म्यूट करने का कंट्रोल
- ऑडियो डकिंग कंट्रोल
कार प्लगिन सेवा का आर्किटेक्चर
नीचे दिए गए डायग्राम में, कार से जुड़ी सेवाओं और ओईएम की कार से जुड़ी सेवा के बीच के संबंध के बारे में खास जानकारी दी गई है. ऐप्लिकेशन प्रोसेस और कार सेवा की प्रोसेस की तरह ही, OEM कार सेवा की प्रोसेस भी अपनी प्रोसेस स्पेस में होती है.
कार सेवा, config_oemCarService में तय किए गए कॉम्पोनेंट को ढूंढकर, ओईएम की कार सेवा शुरू करती है. अगर कॉन्फ़िगरेशन खाली है, तो OEM सेवा मौजूद नहीं है और कोई सेवा शुरू नहीं की गई है. कॉम्पोनेंट को OemCarService से एक्सटेंड किया जाना चाहिए.
कार में ऑडियो की सुविधा देने वाली सेवा को, कार में ऑडियो की सुविधा देने वाली OEM सेवा को हासिल करने के लिए एपीआई को फिर से लिखना होगा:
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 में, कार ऑडियो सेवा के लिए एक ऐसा सिस्टम पेश किया गया है जो OEM के तय किए गए कॉम्पोनेंट से कम्यूनिकेट करता है. यह कॉम्पोनेंट इन चीज़ों को मैनेज करता है:
- ऑडियो फ़ोकस
- ऑडियो डकिंग
- वॉल्यूम और म्यूट करने की सुविधा
नीचे दी गई इमेज में, कार ऑडियो सेवा और कार ओईएम सेवा के लिए आसान आर्किटेक्चर दिखाया गया है. कार ऑडियो सेवा, अलग-अलग हुक तय करती है. ये हुक, कार ओईएम की ऑडियो सेवा को कॉल कर सकते हैं, ताकि ऑडियो के व्यवहार को मैनेज किया जा सके. ऐसा सिर्फ़ तब होता है, जब ओईएम की कार ऑडियो सेवा का कॉम्पोनेंट तय किया गया हो. ऐसा न होने पर, कार ऑडियो सेवा डिफ़ॉल्ट सेटिंग का इस्तेमाल करती है.
यह पक्का करने के लिए कि कार ऑडियो सेवा और कार ओईएम ऑडियो सेवा हमेशा सिंक रहें, कार ऑडियो सेवा हर कॉल के लिए, ऑडियो स्टैक की मौजूदा स्थिति के ज़रूरी हिस्सों को कार ओईएम ऑडियो सेवा को पास करती है. उदाहरण के लिए, जब कार की ऑडियो सेवा, ऑडियो फ़ोकस का आकलन करने के अनुरोध को इंटरसेप्ट करती है, तो वह स्टैक की मौजूदा स्थिति को कार ओईएम की ऑडियो सेवा को भेजती है. मौजूदा स्थिति में, फ़ोकस पाने वाले और फ़ोकस खोने वाले एलिमेंट शामिल होते हैं. फ़ोकस लूज़र, फ़ोकस के ऐसे अनुरोध होते हैं जो अब भी स्टैक का हिस्सा हैं, लेकिन फ़िलहाल उनका फ़ोकस हट गया है.
कार में ऑडियो सेवा को, कार में होने वाली सभी ऑडियो गतिविधियों को मैनेज करना होगा. अगर कार की ऑडियो सेवा, ऑडियो के कुछ हिस्सों को मैनेज नहीं करती है, तो कार ओईएम की ऑडियो सेवा को दिखाई गई जानकारी अधूरी होती है. उदाहरण के लिए, अगर कोई ओईएम, कार सेवा में ऑडियो फ़ोकस हैंडलिंग को बदलता है, तो कार ऑडियो सेवा, कार ओईएम ऑडियो सेवा को पूरी जानकारी नहीं दे सकती. ऐसा इसलिए होता है, क्योंकि ओईएम ने अपनी ऑडियो फ़ोकस नीति रजिस्टर की है. इससे कार ओईएम की ऑडियो सेवा के फ़ैसले लेने की क्षमता पर असर पड़ सकता है, क्योंकि हो सकता है कि उसके पास ऐसी जानकारी न हो जो कार की ऑडियो सेवा को नहीं दिखती.
कार्रवाइयां करने के लिए, कार ऑडियो सेवा, ओईएम की कार सेवाओं को कॉल करती है. ये कॉल, अलग-अलग प्रोसेस के बीच किए जाते हैं. इसके लिए, इंटर-प्रोसेस कम्यूनिकेशन (आईपीसी) की ज़रूरत होती है. आईपीसी से हर कॉल में देरी होती है. ओईएम सेवा में इंतज़ार के समय को कम से कम करना ज़रूरी है.
कार की ऑडियो सेवा, ओईएम की सेवा को कॉल करने से रोक रही है. इसलिए, ओईएम की सेवा को सीधे तौर पर एपीआई के आकलन के लिए, कार की ऑडियो सेवा को कॉल नहीं करना चाहिए. इसके बजाय, कार ऑडियो सेवा ज़रूरी जानकारी उपलब्ध कराती है, ताकि दोनों प्रोसेस के बीच कॉल सिर्फ़ एक दिशा में जा सकें.
OEM की कार ऑडियो सेवा की परिभाषाएं
OEM कार ऑडियो फ़ोकस सेवा
कार ऑडियो सेवा, ऑडियो फ़ोकस की नीति के लिसनर को रजिस्टर करके, ऐप्लिकेशन से मिले ऑडियो फ़ोकस के अनुरोधों को मैनेज करती है. कार ऑडियो सेवा में, फ़ोकस के व्यवहार को मैनेज करने का एक तरीका होता है. यह तरीका, स्टैटिक इंटरैक्शन मैट्रिक्स पर आधारित होता है. मैट्रिक्स में तीन तरह के इंटरैक्शन के बारे में बताया गया है:
एक साथ इंटरैक्शन. फ़ोकस होल्ड करने वाले लोग, एक ही समय पर फ़ोकस बनाए रख सकते हैं.
एक्सक्लूसिव इंटरैक्शन. फ़ोकस करने के नए अनुरोध से, फ़ोकस करने वाले मौजूदा व्यक्ति का फ़ोकस हट जाता है.
इंटरैक्शन अस्वीकार करें. फ़ोकस करने का अनुरोध करने वाले मौजूदा व्यक्ति के आधार पर, फ़ोकस करने का इनकमिंग अनुरोध अस्वीकार कर दिया गया.
ऑटोमोटिव से जुड़े कुछ मामलों में यह सुविधा काम करती है. हालांकि, यह इंटरैक्शन से जुड़ी सभी ज़रूरतों को पूरा नहीं करती. ओईएम की ज़रूरी शर्तों की वजह से, इन ज़रूरतों में अंतर हो सकता है. इसके लिए, हम OemCarAudioFocusService को पेश कर रहे हैं:
public interface OEmCarAudioFocusService {
OemCarAuddioFocusResults evaluateAudioFocusRequest(
OemCarAudioFocusEvaluationRequest request);
void notifyAudioFocusChange(
List<AudioFocusEntry> holder,
List<AudioFocusEntry> losers, int zoneId);
}
जब भी ऑडियो फ़ोकस करने का अनुरोध किया जाता है, तब कार ऑडियो सेवा से एपीआई evaluateAudioFocusRequest को कॉल किया जाता है. यह एक ऐसा एपीआई है जो नतीजे दिखाने के लिए ब्लॉक करता है. अनुरोध में, ऑडियो स्टैक की मौजूदा स्थिति के बारे में जानकारी शामिल होती है:
इस जानकारी का इस्तेमाल, focusHolders में फ़ोकस पाने वाले मौजूदा लोगों की तुलना में newFocusRequest का आकलन करने के लिए किया जा सकता है. साथ ही, focusLosers में फ़ोकस खोने वाले मौजूदा लोगों की तुलना में newFocusRequest का आकलन करने के लिए भी किया जा सकता है. एपीआई को ये नतीजे दिखाने चाहिए:
class OemCarAudioFocusResult {
int audioZoneId;
int audioFocusEvaluationResults;
AudioFocusEntry focusResult;
List<AudioFocusEntry> newLosers;
List<AudioFocusEntry> newlyBlocked;
}
इसमें audioFocusEvaluationResults में मौजूद आकलन के असली नतीजों के बारे में जानकारी होती है. इससे पता चलता है कि मौजूदा अनुरोध को मंज़ूरी मिली है, इसमें देरी हुई है या यह पूरा नहीं किया जा सका. फ़ोकस स्टैक में किए गए किसी भी बदलाव को newLosers और newlyBlocked एंट्री में सेट किया जाना चाहिए. यह बदलाव के टाइप पर निर्भर करता है.
जहां newLosers में ऐसी एंट्री शामिल हैं जिन पर पहले फ़ोकस किया गया था, लेकिन अब उन पर फ़ोकस नहीं किया जाना चाहिए. ऐसा हमेशा के लिए या कुछ समय के लिए किया जा सकता है. ऑडियो फ़ोकस को हमेशा के लिए छोड़ने वाले ऐप्लिकेशन को, ऑडियो फ़ोकस स्टैक से हटा दिया जाएगा. वहीं, ऑडियो फ़ोकस को कुछ समय के लिए छोड़ने वाले ऐप्लिकेशन को, ऑडियो फ़ोकस को छोड़ने वाले मौजूदा ऐप्लिकेशन के स्टैक में तब तक रखा जाएगा, जब तक वे फ़ोकस वापस नहीं पा लेते या उन्हें फ़ोकस का अनुरोध करने वाले मूल ऐप्लिकेशन से हटा नहीं दिया जाता. हालांकि, अनुरोधों के लिए फ़ोकस लिसनर को फ़ोकस खो जाने की सूचना मिलेगी.
newlyBlocked सूची में ऐसी एंट्री शामिल हैं जो पहले फ़ोकस लूज़र सूची में थीं, लेकिन अब नई एंट्री की वजह से ब्लॉक कर दी गई हैं. ब्लॉक हमेशा के लिए या कुछ समय के लिए हो सकता है. अगर फ़ोकस को हमेशा के लिए ब्लॉक किया जाता है, तो एंट्री को स्टैक से हटा दिया जाएगा. साथ ही, फ़ोकस के बंद होने की सूचना, फ़ोकस लिसनर को भेज दी जाएगी. फ़ोकस के कुछ समय के लिए हट जाने पर, एंट्री को फ़ोकस लूज़र स्टैक में रखा जाएगा. हालांकि, फ़ोकस को ब्लॉक करने वाले नए एलिमेंट को, ब्लॉक करने वाले एलिमेंट की सूची में जोड़ दिया जाएगा. फ़ोकस के हट जाने की सूचना नहीं भेजी जाएगी, क्योंकि पहली बार ब्लॉक किए जाने पर यह सूचना पहले ही भेजी जा चुकी है. अनुरोध को आखिर में तब अनब्लॉक किया जाएगा, जब सभी मौजूदा ब्लॉकर हटा दिए जाएंगे. इसके अलावा, अगर फ़ोकस हटा दिया जाता है, तो इसे स्टैक से हटा दिया जाएगा.
दूसरा एपीआई, notifyAudioFocusChange है. यह एकतरफ़ा है. इसे हर ऑडियो फ़ोकस के अनुरोध या उसे छोड़ने पर कॉल किया जाता है. इस एपीआई का इस्तेमाल, ओईएम सेवा को फ़ोकस में हुए बदलावों के बारे में बताने के लिए किया जाता है. इससे ओईएम की कार ऑडियो सेवा के व्यवहार पर असर पड़ सकता है.
फ़ोकस के आकलन से जुड़े दिशा-निर्देश
AAOS में, ऑडियो फ़ोकस का इस्तेमाल ऑडियो चलाने की सुविधा को मैनेज करने के लिए किया जाता है. साथ ही, यह तय करने के लिए भी किया जाता है कि उपयोगकर्ता को बेहतर अनुभव देने के लिए, किस ऐप्लिकेशन को ऑडियो फ़ोकस का पालन करना चाहिए. इसलिए, ओईएम प्लगिन सेवा को ऑडियो फ़ोकस के अनुरोध को मैनेज करते समय, इन बातों का ध्यान रखना चाहिए:
अगर किसी ऐप्लिकेशन को ऑडियो फ़ोकस की ज़रूरत नहीं है (जैसे कि फ़ोन कॉल, आपातकालीन या सुरक्षा से जुड़ा ऐप्लिकेशन), तो उसे कुछ समय के लिए या हमेशा के लिए ऑडियो फ़ोकस मिल जाना चाहिए.
मीडिया फ़ोकस चालू होने पर, ये ऐप्लिकेशन अनुरोध कर सकते हैं:
कॉल के इस्तेमाल पर फ़ोकस किया जाता है. इसे एक साथ या अलग-अलग फ़ोकस किया जा सकता है.
नेविगेशन के इस्तेमाल पर फ़ोकस किया जाता है. इस पर एक साथ या अलग-अलग फ़ोकस किया जा सकता है.
Assistant के इस्तेमाल पर फ़ोकस किया जाता है. इसे एक साथ या अलग-अलग फ़ोकस किया जा सकता है.
ज़्यादा प्राथमिकता वाले ऑडियो फ़ोकस (जैसे, फ़ोन कॉल, आपातकालीन सूचना या सुरक्षा से जुड़ी सूचना) वाले ऐप्लिकेशन चालू होने पर, ऑडियो फ़ोकस के लिए आने वाली किसी भी अनुरोध को ज़रूरत के हिसाब से स्वीकार या अस्वीकार किया जाना चाहिए.
ऊपर दिए गए सुझावों के अलावा, और भी सुझाव हो सकते हैं. हालांकि, इनसे यह पक्का करने में मदद मिल सकती है कि फ़ोकस मोड का अनुरोध करने वाले ऐप्लिकेशन, फ़ोकस मोड को चालू कर सकें. ऐसा तब होगा, जब ज़्यादा प्राथमिकता वाली कोई आवाज़ नहीं सुनाई दे रही होगी. ज़्यादा प्राथमिकता वाले साउंड चालू होने पर भी, फ़ोकस करने के लिए किए गए अनुरोधों का पालन किया जाना चाहिए. साथ ही, ज़्यादा प्राथमिकता वाला साउंड बंद होने के बाद, फ़ोकस करने के लिए किए गए अनुरोधों को पूरा किया जाना चाहिए.
OEM कार वॉल्यूम सेवा
कार में मौजूद ऑडियो सेवा, आवाज़ के बटन से जुड़े इवेंट मैनेज करती है. इसके लिए, वह ऑडियो सिस्टम से आवाज़ में किए गए बदलावों को सुनती है या कार में मौजूद इनपुट सेवा से सीधे तौर पर आवाज़ के बटन से जुड़े इवेंट सुनती है. हर मामले में, कार में मौजूद ऑडियो सेवा का डिफ़ॉल्ट व्यवहार यह तय करना होता है कि चालू ऑडियो प्लेयर और ऑडियो कॉन्टेक्स्ट की प्राथमिकता सूची के आधार पर, किस वॉल्यूम ग्रुप को बदलना है.
हम वॉल्यूम प्राथमिकता की दो सूचियां उपलब्ध कराते हैं. पहली सूची में, ऑडियो के सभी कॉन्टेक्स्ट को इस क्रम में रखा गया है. सूची को घटते क्रम में दिखाया जाता है. सबसे ज़्यादा प्राथमिकता वाले सुझाव सबसे ऊपर और सबसे कम प्राथमिकता वाले सुझाव सबसे नीचे दिखते हैं. उदाहरण के लिए, अगर नेविगेशन ऑडियो और संगीत ऑडियो, दोनों एक ही समय पर चालू हैं, तो आवाज़ कम या ज़्यादा करने के बटन को दबाने पर, नेविगेशन की आवाज़ में बदलाव होगा.
- नेविगेशन
- कॉल करें
- संगीत
- सूचना
- बोला गया निर्देश
- कॉल रिंग
- सिस्टम ध्वनि
- सुरक्षा
- अलार्म
- सूचना
- वाहन की स्थिति
- आपातकालीन कॉल
आवाज़ के मुख्य इवेंट को मैनेज करने की प्रोसेस को आसान बनाने के लिए, कार ऑडियो सेवा में ऑडियो कॉन्टेक्स्ट की दूसरी प्राथमिकता वाली सूची होती है:
- कॉल करें
- मीडिया
- सूचना
- बोला गया निर्देश
इस सूची को भी घटते क्रम में दिखाया जाता है. इस दूसरी सूची का मकसद, मुख्य इवेंट के ज़रिए ज़्यादा सामान्य आवाज़ों को बदलने की अनुमति देना है. कम सुनाई देने वाली आवाज़ों को सिर्फ़ ऑडियो सेटिंग के यूज़र इंटरफ़ेस (यूआई) से मैनेज किया जा सकता है. जैसे, कम समय के लिए सुनाई देने वाली आवाज़ें.
वॉल्यूम का मौजूदा वर्शन, 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 होगा. साथ ही, लौटाया गया
वॉल्यूम ग्रुप, नेविगेशन के लिए होना चाहिए.
OEM कार डकिंग सेवा
कार ऑडियो सेवा, ऑडियो डकिंग को मैनेज करती है. इसके लिए, वह ऑडियो फ़ोकस में होने वाले बदलावों को मॉनिटर करती है. साथ ही, AudioControl HAL को यह सिग्नल भेजती है कि किन ऑडियो डिवाइसों को डक करना है.
फ़ोकस बदलने पर, फ़ोकस रखने वाले सभी चालू ऑब्जेक्ट का आकलन किया जाता है. इससे यह तय किया जाता है कि डकिंग के इस सेट के आधार पर, किस ऑब्जेक्ट को डक किया जाना चाहिए. डकिंग के नियम ये हैं:
- आपातकालीन स्थितियों वाली आवाज़ें, कॉल की आवाज़ों को छोड़कर बाकी सभी आवाज़ों को कम कर देती हैं
- सुरक्षा से जुड़ी सुविधा, आपातकालीन स्थितियों वाली आवाज़ों को छोड़कर सभी आवाज़ों को कम कर देती है
- नेविगेशन सिस्टम, सुरक्षा और आपातकालीन आवाज़ों को छोड़कर बाकी सभी आवाज़ों को कम कर देता है
- कॉल डकिंग की सुविधा, सुरक्षा, आपातकालीन, और नेविगेशन से जुड़ी आवाज़ों को छोड़कर सभी आवाज़ों के लिए काम करती है
- वॉइस डक की सुविधा, कॉल की घंटी की आवाज़ को कम करती है
- संगीत और सूचनाओं की आवाज़ को हर तरह के ऑडियो के लिए कम किया जाना चाहिए
ये नियम पूरी तरह से लागू नहीं होते. ओईएम यह तय करने के लिए ज़िम्मेदार होते हैं कि इन दिशा-निर्देशों के आधार पर आवाज़ को कैसे कम किया जाना चाहिए. ओईएम, उपलब्ध ज़रूरी शर्तों के आधार पर इन सुझावों को ज़्यादा बेहतर तरीके से कंट्रोल कर सकते हैं. OemCarDuckingService को Android 14 में पेश किया गया है:
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 का मतलब है कि सेवा इस्तेमाल के लिए तैयार नहीं है.