Android 14 में, कार ओईएम के प्लगिन की नई सेवाएं उपलब्ध हैं. इनकी मदद से, कार के कुछ कॉम्पोनेंट को कॉन्फ़िगर किया जा सकता है. खास तौर पर ऑडियो के लिए, तीन नई प्लगिन सेवाएं लॉन्च की गई हैं. इनकी मदद से, 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 में फ़ोकस पाने वाले मौजूदा प्रॉडक्ट और focusLosers में फ़ोकस खोने वाले मौजूदा प्रॉडक्ट की तुलना में newFocusRequest का आकलन करने के लिए किया जा सकता है. एपीआई को ये नतीजे दिखाने चाहिए:
class OemCarAudioFocusResult {
int audioZoneId;
int audioFocusEvaluationResults;
AudioFocusEntry focusResult;
List<AudioFocusEntry> newLosers;
List<AudioFocusEntry> newlyBlocked;
}
इसमें audioFocusEvaluationResults में मौजूद आकलन के असली नतीजों के बारे में जानकारी होती है. इससे पता चलता है कि मौजूदा अनुरोध को मंज़ूरी मिली है, इसमें देरी हुई है या यह पूरा नहीं हो सका. मौजूदा फ़ोकस स्टैक में किए गए किसी भी बदलाव को newLosers और newlyBlocked एंट्री में सेट किया जाना चाहिए. यह बदलाव के टाइप पर निर्भर करता है.
जहां newLosers में ऐसी एंट्री शामिल हैं जिन पर पहले फ़ोकस किया गया था, लेकिन अब उन पर फ़ोकस नहीं किया जाना चाहिए. ऐसा स्थायी या अस्थायी तौर पर हो सकता है. ऑडियो फ़ोकस को हमेशा के लिए खोने वाले ऐप्लिकेशन को ऑडियो फ़ोकस स्टैक से हटा दिया जाएगा. वहीं, ऑडियो फ़ोकस को कुछ समय के लिए खोने वाले ऐप्लिकेशन को, ऑडियो फ़ोकस को फ़िलहाल खोने वाले ऐप्लिकेशन के स्टैक में तब तक रखा जाएगा, जब तक वे ऑडियो फ़ोकस वापस नहीं पा लेते या उन्हें ऑडियो फ़ोकस का अनुरोध करने वाले मूल ऐप्लिकेशन से हटा नहीं दिया जाता. हालांकि, अनुरोधों के लिए फ़ोकस लिसनर को फ़ोकस खो जाने की सूचना मिलेगी.
newlyBlocked सूची में ऐसी एंट्री शामिल हैं जो पहले फ़ोकस लूज़र की सूची में थीं, लेकिन अब नई एंट्री की वजह से ब्लॉक कर दी गई हैं. ब्लॉक हमेशा के लिए या कुछ समय के लिए हो सकता है. हमेशा के लिए फ़ोकस ब्लॉक होने पर, एंट्री को स्टैक से हटा दिया जाएगा. साथ ही, फ़ोकस के हट जाने की सूचना, फ़ोकस लिसनर को भेज दी जाएगी. फ़ोकस में कुछ समय के लिए रुकावट आने पर, एंट्री को फ़ोकस में रुकावट डालने वाले स्टैक में रखा जाएगा. हालांकि, फ़ोकस में रुकावट डालने वाले नए एलिमेंट को, रुकावट डालने वाले एलिमेंट की सूची में जोड़ा जाएगा. फ़ोकस में रुकावट आने की सूचना नहीं भेजी जाएगी, क्योंकि पहली बार ब्लॉक किए जाने पर यह सूचना पहले ही भेजी जा चुकी है. अनुरोध को तब तक ब्लॉक किया जाएगा, जब तक सभी मौजूदा ब्लॉकर हटा नहीं दिए जाते. अगर फ़ोकस हटा दिया जाता है, तो अनुरोध को स्टैक से हटा दिया जाएगा.
दूसरा एपीआई, notifyAudioFocusChange, एकतरफ़ा है. इसे हर ऑडियो फ़ोकस अनुरोध या छोड़ने पर कॉल किया जाता है. इस एपीआई का इस्तेमाल, ओईएम सेवा को फ़ोकस में हुए बदलावों के बारे में बताने के लिए किया जाता है. इससे ओईएम की कार ऑडियो सेवा के व्यवहार पर असर पड़ सकता है.
फ़ोकस के आकलन के लिए दिशा-निर्देश
AAOS में, ऑडियो फ़ोकस का इस्तेमाल ऑडियो प्लेबैक को मैनेज करने के लिए किया जाता है. साथ ही, यह तय करने के लिए भी किया जाता है कि उपयोगकर्ता को बेहतर अनुभव देने के लिए, किस ऐप्लिकेशन को ऑडियो फ़ोकस का पालन करना चाहिए. इसलिए, ओईएम प्लगिन सेवा को ऑडियो फ़ोकस के अनुरोध को मैनेज करते समय, इन बातों का ध्यान रखना चाहिए:
अगर किसी ऐप्लिकेशन को ऑडियो फ़ोकस की ज़रूरत नहीं है (जैसे कि फ़ोन कॉल, आपातकालीन या सुरक्षा से जुड़ा ऐप्लिकेशन), तो उसे कुछ समय के लिए या हमेशा के लिए ऑडियो फ़ोकस मिल जाना चाहिए.
मीडिया फ़ोकस चालू होने पर, ये ऐप्लिकेशन अनुरोध कर सकते हैं:
कॉल के इस्तेमाल पर फ़ोकस किया जाता है. साथ ही, इसे एक साथ या अलग-अलग फ़ोकस किया जा सकता है.
नेविगेशन के इस्तेमाल पर फ़ोकस किया जाता है. इस पर एक साथ या अलग-अलग फ़ोकस किया जा सकता है.
Assistant के इस्तेमाल पर फ़ोकस किया गया हो. साथ ही, 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 होगी. साथ ही, लौटाया गया
वॉल्यूम ग्रुप, नेविगेशन के लिए होगा.
ओईएम कार डकिंग सेवा
Car audio service, ऑडियो डकिंग को मैनेज करती है. इसके लिए, यह ऑडियो फ़ोकस में होने वाले बदलावों को मॉनिटर करती है. साथ ही, AudioControl एचएएल को यह सिग्नल भेजती है कि किन ऑडियो डिवाइसों को डक करना है.
फ़ोकस बदलने पर, फ़ोकस रखने वाले सभी चालू ऑब्जेक्ट का आकलन किया जाता है. इससे यह तय किया जाता है कि डकिंग की इन स्टैटिक नियमों के आधार पर, किस ऑब्जेक्ट को डक किया जाना चाहिए:
- आपातकालीन स्थितियों वाली आवाज़ें, कॉल की आवाज़ों को छोड़कर बाकी सभी आवाज़ों को कम कर देती हैं
- सुरक्षा से जुड़ी सुविधा, आपातकालीन स्थितियों वाली आवाज़ों को छोड़कर सभी आवाज़ों को कम कर देती है
- नेविगेशन सिस्टम, सुरक्षा और आपातकालीन स्थितियों से जुड़ी आवाज़ों को छोड़कर, अन्य सभी आवाज़ों को कम कर देता है
- कॉल डक की सुविधा, सुरक्षा, आपातकालीन, और नेविगेशन से जुड़ी आवाज़ों को छोड़कर सभी आवाज़ों को बंद कर देती है
- वॉइस डक कॉल की घंटी की आवाज़ें
- संगीत और सूचनाओं की आवाज़ को हर तरह के ऑडियो के लिए कम किया जाना चाहिए
ये नियम पूरी तरह से लागू नहीं होते. ओईएम की यह ज़िम्मेदारी बनी रहती है कि वे इन दिशा-निर्देशों के आधार पर यह तय करें कि आवाज़ को कैसे कम किया जाना चाहिए. ओईएम, उपलब्ध ज़रूरी शर्तों के आधार पर इन सुझावों को ज़्यादा बेहतर तरीके से कंट्रोल कर सकते हैं. 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 का मतलब है कि सेवा इस्तेमाल के लिए तैयार नहीं है.