Android 14 में कार के लिए OEM प्लग इन की नई सेवाओं की मदद से, कार के कुछ कॉम्पोनेंट कॉन्फ़िगर किए जा सकते हैं. खास तौर पर ऑडियो के लिए, तीन नई प्लग-इन सेवाएं शुरू की गई हैं. इनकी मदद से, OEM, AAOS डिवाइसों पर ऑडियो मैनेजमेंट को आसानी से कॉन्फ़िगर कर सकते हैं:
- ऑडियो फ़ोकस कंट्रोल
- ऑडियो वॉल्यूम और म्यूट कंट्रोल
- ऑडियो डकिंग कंट्रोल
कार प्लग इन सेवा का आर्किटेक्चर
नीचे दिए गए इलस्ट्रेशन में, कार सेवाओं और OEM कार सेवा के साथ उनके संबंध के बारे में खास जानकारी दी गई है. ऐप्लिकेशन की प्रोसेस और कार की सेवा की प्रोसेस की तरह ही, OEM कार की सेवा की प्रोसेस भी अपने प्रोसेस स्पेस में होती है.
कार सेवा, config_oemCarService में बताए गए कॉम्पोनेंट को ढूंढकर, OEM कार सेवा शुरू करती है. अगर कॉन्फ़िगरेशन खाली है, तो 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 में दिए गए रेफ़रंस टेस्ट ऐप्लिकेशन को देखें.
भले ही, यह सेवा कार सेवा से शुरू की गई हो, लेकिन यह कार की ऑडियो सेवा के लिए उपलब्ध अनुमतियों को अपने-आप नहीं पाती. इसलिए, OEM सेवाओं के लिए ज़रूरी अनुमति, सही तरीके से ली जानी चाहिए. उदाहरण के लिए, packages/services/Car/data/etc/com.android.car.oemcarservice.testapp.xml देखें.
OEM सेवा आर्किटेक्चर वाली कार ऑडियो सेवा
AAOS में, कार ऑडियो सेवा ये कार्रवाइयां मैनेज करती है:
- ऑडियो रूटिंग
- ऑडियो फ़ोकस
- ऑडियो डकिंग
- वॉल्यूम और म्यूट करना
Android 14 से पहले, यह व्यवहार काफ़ी हद तक स्टैटिक था और इसे सिर्फ़ सेटिंग में जाकर बदला जा सकता था. हालांकि, ऐसा कुछ ही मामलों में किया जा सकता था. Android 14 में, कार की ऑडियो सेवा के लिए एक सुविधा जोड़ी गई है. इससे, OEM के तय किए गए उस कॉम्पोनेंट से संपर्क किया जा सकता है जो इन चीज़ों को मैनेज करता है:
- ऑडियो फ़ोकस
- ऑडियो डकिंग
- वॉल्यूम और म्यूट करना
नीचे दी गई इमेज में, कार की ऑडियो सेवा और कार की OEM सेवा के लिए, आसानी से समझा जा सकने वाला आर्किटेक्चर दिखाया गया है. कार की ऑडियो सेवा, अलग-अलग हुक तय करती है. ये हुक, ऑडियो के व्यवहार को मैनेज करने के लिए, कार की OEM ऑडियो सेवा को कॉल कर सकते हैं. ऐसा सिर्फ़ तब होता है, जब संबंधित OEM कार ऑडियो सेवा कॉम्पोनेंट तय किया गया हो. ऐसा न होने पर, कार की ऑडियो सेवा डिफ़ॉल्ट तरीके से काम करती है.
यह पक्का करने के लिए कि कार की ऑडियो सेवा और कार की OEM ऑडियो सेवा हमेशा सिंक में रहें, हर कॉल के लिए कार की ऑडियो सेवा, ऑडियो स्टैक की मौजूदा स्थिति के ज़रूरी हिस्सों को कार की OEM ऑडियो सेवा को भेजती है. उदाहरण के लिए, जब कार की ऑडियो सेवा, ऑडियो फ़ोकस का आकलन करने के लिए किसी अनुरोध को इंटरसेप्ट करती है, तो वह स्टैक की मौजूदा स्थिति को कार की OEM ऑडियो सेवा को भेजती है. मौजूदा स्थिति में, फ़ोकस रखने वाले और फ़ोकस खोने वाले मौजूदा उपयोगकर्ता शामिल होते हैं. फ़ोकस खोने वाले अनुरोध, ऐसे फ़ोकस अनुरोध होते हैं जो अब भी स्टैक का हिस्सा होते हैं, लेकिन जिन पर फ़िलहाल फ़ोकस नहीं है.
कार की ऑडियो सेवा को कार में होने वाली सभी ऑडियो गतिविधियों को मैनेज करना चाहिए. अगर कार की ऑडियो सेवा, ऑडियो के कुछ हिस्सों को मैनेज नहीं करती है, तो कार की OEM ऑडियो सेवा को दिखाई गई जानकारी अधूरी होती है. उदाहरण के लिए, अगर कोई OEM, कार सेवा में ऑडियो फ़ोकस मैनेज करने की सुविधा को बदलकर, अपनी ऑडियो फ़ोकस नीति को रजिस्टर करता है, तो कार की ऑडियो सेवा, कार की OEM ऑडियो सेवा को पूरी जानकारी नहीं दे पाएगी. इससे कार की OEM ऑडियो सेवा के फ़ैसले लेने की क्षमता पर असर पड़ सकता है, क्योंकि हो सकता है कि उसमें ऐसी जानकारी न हो जो कार की ऑडियो सेवा को दिखती है.
कार्रवाइयां करने के लिए, कार की ऑडियो सेवा, OEM कार सेवाओं को कॉल करती है. ये कॉल, अलग-अलग प्रोसेस के लिए किए जाते हैं. इसके लिए, इंटर-प्रोसेस कम्यूनिकेशन (आईपीसी) की ज़रूरत होती है. आईपीसी, हर कॉल में इंतज़ार का समय जोड़ता है. OEM सेवा में इंतज़ार का समय कम करना ज़रूरी है.
कार की ऑडियो सेवा के कॉल, OEM सेवा को ब्लॉक कर रहे हैं. इसलिए, OEM सेवा को सीधे एपीआई के आकलन के लिए, कार की ऑडियो सेवा को कॉल नहीं करना चाहिए. इसके बजाय, कार की ऑडियो सेवा ज़रूरी जानकारी देती है, ताकि दोनों प्रोसेस के बीच कॉल सिर्फ़ एक दिशा में ट्रैवल कर सकें.
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, एक तरह का एपीआई है. इसे ऑडियो फ़ोकस के हर अनुरोध या उसे छोड़ने पर कॉल किया जाता है. एपीआई का ज़्यादातर इस्तेमाल, फ़ोकस में हुए बदलावों के बारे में OEM सेवा को बताने के लिए किया जाता है. इससे OEM कार ऑडियो सेवा के काम करने के तरीके पर असर पड़ सकता है.
फ़ोकस के आकलन के लिए दिशा-निर्देश
AAOS में, ऑडियो फ़ोकस का इस्तेमाल ऑडियो चलाने के लिए किया जाता है. साथ ही, यह तय करने के लिए भी किया जाता है कि उपयोगकर्ता को बेहतर अनुभव देने के लिए, किस ऐप्लिकेशन को प्राथमिकता दी जानी चाहिए. इसलिए, ऑडियो फ़ोकस के अनुरोध को मैनेज करते समय, OEM प्लग इन सेवा को इन बातों का ध्यान रखना चाहिए:
अगर फ़ोन कॉल, आपातकालीन स्थिति या सुरक्षा जैसी किसी भी ज़रूरी ऑडियो फ़ोकस की सुविधा चालू नहीं है, तो ऐप्लिकेशन कुछ समय के लिए या हमेशा के लिए ऑडियो फ़ोकस हासिल कर सकते हैं.
मीडिया फ़ोकस चालू होने पर, ऐप्लिकेशन ये काम कर सकते हैं:
कॉल के इस्तेमाल पर फ़ोकस, एक साथ या सिर्फ़ एक कॉल पर किया जा सकता है.
नेविगेशन के इस्तेमाल से जुड़े फ़ोकस को एक साथ या सिर्फ़ एक बार फ़ोकस मिलना चाहिए.
Assistant के इस्तेमाल से जुड़े फ़ोकस को एक साथ या सिर्फ़ एक बार फ़ोकस किया जा सकता है.
जब ज़्यादा प्राथमिकता वाले ऑडियो फ़ोकस (जैसे, फ़ोन कॉल, आपातकालीन सूचना या सुरक्षा से जुड़ी सूचना) वाले ऐप्लिकेशन चालू होते हैं, तो आने वाले किसी भी ऑडियो फ़ोकस के अनुरोध को स्वीकार किया जाना चाहिए या ज़रूरत के हिसाब से उसे देर से पूरा किया जाना चाहिए.
ऊपर दिए गए सुझावों में सभी चीज़ें शामिल नहीं हैं. हालांकि, इनसे यह पक्का करने में मदद मिल सकती है कि जब कोई ऐसी आवाज़ न हो जिसे प्राथमिकता दी गई हो, तब फ़ोकस पाने का अनुरोध करने वाले ऐप्लिकेशन को फ़ोकस मिल सके. ज़्यादा प्राथमिकता वाली आवाज़ें चालू होने पर भी, फ़ोकस करने के लिए किए गए अनुरोधों को पूरा किया जाना चाहिए. साथ ही, ज़्यादा प्राथमिकता वाली आवाज़ बंद होने के बाद, फ़ोकस करने की सुविधा फिर से चालू हो जानी चाहिए.
OEM कार वॉल्यूम सेवा
कार की ऑडियो सेवा, आवाज़ के बटन से होने वाले इवेंट को मैनेज करती है. इसके लिए, वह ऑडियो सिस्टम से आवाज़ के लेवल में होने वाले बदलावों को सुनती है या सीधे कार की इनपुट सेवा से आवाज़ के बटन से होने वाले इवेंट को सुनती है. हर मामले में, कार की ऑडियो सेवा के डिफ़ॉल्ट तरीके से यह तय किया जाता है कि चालू ऑडियो प्लेयर और ऑडियो कॉन्टेक्स्ट की प्राथमिकता सूची के आधार पर, किस वॉल्यूम ग्रुप में बदलाव करना है.
हम वॉल्यूम की प्राथमिकता वाली दो सूचियां उपलब्ध कराते हैं. पहली सूची में, सभी ऑडियो कॉन्टेक्स्ट इस क्रम में शामिल होते हैं. सूची को घटते क्रम में दिखाया जाता है. सबसे ऊपर सबसे ज़्यादा प्राथमिकता वाली समस्याएं होती हैं और सबसे नीचे सबसे कम प्राथमिकता वाली समस्याएं होती हैं. उदाहरण के लिए, अगर नेविगेशन ऑडियो और संगीत ऑडियो, दोनों एक ही समय पर चालू हैं, तो वॉल्यूम बटन से होने वाले इवेंट के दौरान नेविगेशन वॉल्यूम बदल जाता है.
- नेविगेशन
- कॉल करें
- संगीत
- घोषणा
- बोला गया निर्देश
- कॉल रिंग
- सिस्टम ध्वनि
- सुरक्षा
- अलार्म
- सूचना
- वाहन की स्थिति
- आपातकालीन कॉल
वॉल्यूम बटन से जुड़े मुख्य इवेंट को मैनेज करना आसान बनाने के लिए, कार की ऑडियो सेवा में ऑडियो कॉन्टेक्स्ट की एक दूसरी प्राथमिकता वाली सूची होती है:
- कॉल करें
- मीडिया
- घोषणा
- बोला गया निर्देश
यह सूची भी घटते क्रम में दिखाई जाती है. इस दूसरी सूची का मकसद, मुख्य इवेंट की मदद से ज़्यादा सामान्य साउंड बदलना है. आम तौर पर इस्तेमाल न होने वाली, कम अवधि वाली आवाज़ों को सिर्फ़ ऑडियो सेटिंग के यूज़र इंटरफ़ेस (यूआई) से मैनेज किया जा सकता है.
वॉल्यूम का असल वर्शन, audioVolumeAdjustmentContextsVersion कॉन्फ़िगरेशन की मदद से सेट किया जा सकता है. कॉन्फ़िगरेशन को 1 या 2 पर सेट किया जा सकता है. 2 डिफ़ॉल्ट तौर पर सेट होता है.
वॉल्यूम मैनेज करने की सुविधा को ज़्यादा बेहतर बनाने के लिए, Android 14 में OemCarAudioVolumeService को जोड़ा गया है:
public interface OemCarAudioVolumeService {
OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}
OEM कार ऑडियो वॉल्यूम सेवा का एक ही तरीका है, जिसमें एक 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 को सिग्नल भेजती है कि किन ऑडियो डिवाइसों को डक करना है.
फ़ोकस बदलने पर, सभी चालू फ़ोकस होल्डर का आकलन किया जाता है, ताकि यह तय किया जा सके कि स्टैटिक डकिंग के इन नियमों के आधार पर, किन एलिमेंट को डक किया जाना चाहिए:
- आपातकालीन स्थितियों वाली आवाज़ें, कॉल की आवाज़ों को छोड़कर बाकी सभी आवाज़ों को कम कर देती हैं
- सुरक्षा मोड चालू होने पर, आपातकालीन स्थितियों वाली आवाज़ों को छोड़कर, सभी आवाज़ें बंद हो जाती हैं
- नेविगेशन की सुविधा, सुरक्षा और आपातकालीन स्थिति से जुड़ी आवाज़ों को छोड़कर, सभी आवाज़ों को कम कर देती है
- सुरक्षा, आपातकालीन, और नेविगेशन की आवाज़ों को छोड़कर, सभी आवाज़ों को शांत कर देता है
- वॉइस डक कॉल की घंटी की आवाज़ें
- संगीत और सूचनाओं को सभी चीज़ों से डक किया जाना चाहिए
ये नियम पूरी जानकारी नहीं देते. इन दिशा-निर्देशों के आधार पर, OEM यह तय करने के लिए ज़िम्मेदार हैं कि आवाज़ों को कैसे कम किया जाए. OEM, उपलब्ध ज़रूरी शर्तों के आधार पर, इन सुझावों को ज़्यादा सक्रिय तरीके से कंट्रोल कर सकते हैं. OemCarDuckingService को Android 14 में जोड़ा गया है:
class OemCarAudioDuckingService {
List<AudioAttributes> evaluateAttributesToDuck(
OemCarAudioVolumeRequest request);
}
ऑडियो फ़ोकस में बदलाव होने पर, कार की ऑडियो सेवा से इस एपीआई को कॉल किया जाता है. इसमें, OEM कार वॉल्यूम सेवा में पेश किए गए OemCarAudioVolumeRequest का फिर से इस्तेमाल किया जाता है. साथ ही, इसमें यह तय करने के लिए ज़रूरी जानकारी होती है कि किन एट्रिब्यूट को छिपाना है. एपीआई से डक करने के लिए, ऑडियो एट्रिब्यूट की सूची की तुलना ऑडियो की मौजूदा स्थिति से की जाती है:
फ़िलहाल, ऑडियो एट्रिब्यूट को छिपाया गया है:
- सूची में शामिल है, लेकिन अब भी छिपा हुआ है
- सूची में नहीं है, डकिंग की सुविधा बंद है
ऑडियो एट्रिब्यूट को फ़िलहाल डक नहीं किया गया है:
- सूची में शामिल है, लेकिन 'नतीजों में न दिखाएं' सुविधा चालू है
- सूची में नहीं है, डकिंग की सुविधा बंद है
इसके बाद, कार की ऑडियो सेवा यह तय करती है कि ऑडियो एट्रिब्यूट किन ऑडियो आउटपुट डिवाइसों से जुड़े हैं. साथ ही, उन्हें डक किए गए ऑडियो आउटपुट डिवाइसों की सूची या डक नहीं किए गए ऑडियो डिवाइसों की सूची में जोड़ती है. आखिर में, इसे हार्डवेयर लेवल पर ज़रूरी डकिंग करने के लिए, AudioControl HAL को भेजा जाता है.
नीचे दिए गए इलस्ट्रेशन में, फ़ोकस अनुरोध के लिए ऑडियो डकिंग कंट्रोल का आसानी से समझा जा सकने वाला सिलसिलेवार डायग्राम दिखाया गया है. यह तब दिखता है, जब OEM डकिंग सेवा का इस्तेमाल किया जाता है:
यह क्रम तब शुरू होता है, जब कोई ऐप्लिकेशन सार्वजनिक ऑडियो मैनेजर एपीआई के ज़रिए, ऑडियो फ़ोकस मैनेज करने का अनुरोध करता है. नतीजे पाने के लिए, अनुरोध को कार की ऑडियो सेवा पर भेजा जाता है. ऑडियो फ़ोकस तय होने के बाद, कार की ऑडियो सेवा OemCarAudioDuckingService को कॉल करके, ऑडियो डकिंग का आकलन करती है. इससे यह तय होता है कि किन ऑडियो एट्रिब्यूट को डक किया जाना चाहिए. evaluateAttributesToDuck एपीआई से नतीजे मिलने के बाद, डक करने के लिए ऑडियो डिवाइसों का हिसाब लगाया जाता है. आखिर में, ऑडियो हार्डवेयर पर डकिंग लागू करने के लिए, जानकारी AudioControl को भेजी जाती है.
OEM कार ऑडियो सेवा को रेफ़रंस के तौर पर लागू करना
AAOS, packages/services/Car/tests/OemCarServiceTestApp में OEM कार सेवा के लागू होने का रेफ़रंस देता है. यह OemCarService के साथ-साथ OemCarAudioFocusService,
OemCarAudioDuckingService, और OemCarAudioVolumeService को लागू करता है. बाद वाले मामले में, हर सेवा स्टैटिक व्यवहार को लोड करने के लिए, एक्सएमएल फ़ाइल का इस्तेमाल करती है. उदाहरण के लिए,
OemCarAudioFocusServiceImp, oem_focus_config.xml को लोड करता है, जिसमें इंटरैक्शन मैट्रिक होती है. evaluateAudioFocusRequest को कॉल करने पर, फ़ोकस अनुरोध का आकलन करने के लिए मैट्रिक का इस्तेमाल किया जाता है.
टेस्ट ऐप्लिकेशन को डीबग करने के बारे में रेफ़रंस
OEM कार सेवा टेस्ट ऐप्लिकेशन, AOSP सोर्स कोड का हिस्सा है. OEM, अपनी ज़रूरतों के हिसाब से बदलाव कर सकते हैं. डीबग करने के लिए, टेस्ट ऐप्लिकेशन को चालू करने के लिए 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>
OEM कार सेवा के लिए, कार सेवा 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 से पता चलता है कि सेवा इस्तेमाल के लिए तैयार नहीं है.