एंड्रॉइड 14 में नई कार ओईएम प्लगइन सेवाएं कुछ कार घटकों को कॉन्फ़िगर करने में सक्षम बनाती हैं। विशेष रूप से ऑडियो के लिए, तीन नई प्लगइन सेवाएँ पेश की गई हैं, जो OEM को AAOS उपकरणों पर ऑडियो प्रबंधन को लचीले ढंग से कॉन्फ़िगर करने में सक्षम बनाती हैं:
- ऑडियो फोकस नियंत्रण
- ऑडियो वॉल्यूम और म्यूट नियंत्रण
- ऑडियो डकिंग नियंत्रण
कार प्लगइन सेवा वास्तुकला
नीचे दिया गया आंकड़ा कार सेवाओं और ओईएम कार सेवा से उनके संबंध का एक सिंहावलोकन प्रदान करता है। ऐप प्रक्रियाओं और कार सेवा प्रक्रिया के समान, ओईएम कार सेवा प्रक्रिया अपनी स्वयं की प्रक्रिया स्थान रखती है।
कार सेवा config_oemCarService में परिभाषित घटक को ढूंढकर OEM कार सेवा शुरू करती है। यदि कॉन्फ़िगरेशन खाली है, तो OEM सेवा मौजूद नहीं है और कोई सेवा प्रारंभ नहीं हुई है। घटक को 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 देखें।
OEM सेवा वास्तुकला के साथ कार ऑडियो सेवा
AAOS में, कार ऑडियो सेवा इन कार्यों का प्रबंधन करती है:
- ऑडियो रूटिंग
- ऑडियो फोकस
- ऑडियो डकिंग
- वॉल्यूम और म्यूट
एंड्रॉइड 14 से पहले, यह व्यवहार काफी हद तक स्थिर था और इसे केवल सेटिंग्स के माध्यम से संशोधित किया जा सकता था, हालांकि बहुत ही सीमित मामलों के लिए। एंड्रॉइड 14 ने 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 कार वॉल्यूम सेवा
कार ऑडियो सेवा या तो ऑडियो सिस्टम से वॉल्यूम समायोजन को सुनकर या सीधे कार इनपुट सेवा से वॉल्यूम कुंजी घटनाओं को सुनकर वॉल्यूम कुंजी घटनाओं का प्रबंधन करती है। प्रत्येक मामले में, कार ऑडियो सेवा का डिफ़ॉल्ट व्यवहार यह निर्धारित करना है कि सक्रिय ऑडियो प्लेयर और ऑडियो संदर्भ प्राथमिकता सूची के आधार पर किस वॉल्यूम समूह को बदलना है।
हम दो वॉल्यूम प्राथमिकता सूचियाँ प्रदान करते हैं। पहली सूची इस क्रम में सभी ऑडियो संदर्भों पर विचार करती है। सूची अवरोही क्रम में प्रस्तुत की गई है, शीर्ष पर सर्वोच्च प्राथमिकता और सबसे नीचे निम्नतम प्राथमिकता है। उदाहरण के लिए, यदि नेविगेशन ऑडियो और संगीत ऑडियो दोनों एक ही समय में सक्रिय हैं, तो वॉल्यूम कुंजी इवेंट के दौरान नेविगेशन वॉल्यूम बदल जाता है।
- मार्गदर्शन
- पुकारना
- संगीत
- घोषणा
- आवाज़ से आदेश
- कॉल रिंग
- सिस्टम ध्वनि
- सुरक्षा
- खतरे की घंटी
- अधिसूचना
- वाहन की स्थिति
- आपातकाल
वॉल्यूम कुंजी इवेंट प्रबंधन को कम जटिल बनाने के लिए, कार ऑडियो सेवा में ऑडियो संदर्भ की दूसरी प्राथमिकता सूची है:
- पुकारना
- मिडिया
- घोषणा
- आवाज़ से आदेश
यह सूची भी अवरोही क्रम में प्रस्तुत की गई है। इस दूसरी सूची का उद्देश्य प्रमुख घटनाओं के माध्यम से अधिक सामान्य ध्वनियों को बदलने की अनुमति देना है। असामान्य, शायद कम अवधि की ध्वनियाँ, केवल ऑडियो सेटिंग्स यूआई के माध्यम से प्रबंधित की जा सकती हैं।
वॉल्यूम का वास्तविक संस्करण audioVolumeAdjustmentContextsVersion कॉन्फ़िगरेशन के साथ सेट किया जा सकता है। कॉन्फ़िगरेशन को 1 या 2 पर सेट किया जा सकता है ( 2 डिफ़ॉल्ट है)।
वॉल्यूम प्रबंधन को अधिक लचीलापन प्रदान करने के लिए, OemCarAudioVolumeService को Android 14 में पेश किया गया है:
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 सभी वर्तमान में ducked ऑडियो विशेषताएँ हैं। volumeGroupState में वॉल्यूम समूह की वर्तमान स्थिति है। अनुरोध ऑडियो स्टैक की वर्तमान स्थिति का प्रतिनिधित्व करता है और इसका उपयोग यह निर्धारित करने के लिए किया जा सकता है कि किस वॉल्यूम समूह को बदला जाना चाहिए। परिणाम OemCarVolumeChangeInfo में लौटाए जाने चाहिए:
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
change बूलियन इंगित करता है कि क्या कोई वॉल्यूम बदल गया है, true इंगित करता है कि कोई बदलाव है और वॉल्यूम समूह को अद्यतन किया जाना चाहिए। volumeGroupChanged वास्तविक वॉल्यूम समूह है जिसे बदला जाना चाहिए। इस समूह को एपीआई को दिए गए मूल volumeAdjustment पैरामीटर के अनुसार बदला जाना चाहिए। उदाहरण के लिए, यदि परिणाम इंगित करते हैं कि नेविगेशन वॉल्यूम समूह को म्यूट किया जाना चाहिए, तो बूलियन true होगा और नेविगेशन के लिए लौटाया गया वॉल्यूम समूह होना चाहिए।
OEM कार डकिंग सेवा
कार ऑडियो सेवा ऑडियो फ़ोकस परिवर्तनों की निगरानी करके और AudioControl एचएएल को सिग्नल भेजकर ऑडियो डकिंग का प्रबंधन करती है कि किस ऑडियो डिवाइस को डक करना है। जब फोकस बदलता है, तो सभी सक्रिय फोकस धारकों का मूल्यांकन यह निर्धारित करने के लिए किया जाता है कि स्थिर डकिंग नियमों के इस सेट के आधार पर किसे डक किया जाना चाहिए:
- आपात्कालीन ध्वनियाँ कॉल ध्वनियों को छोड़कर बाकी सभी चीज़ों को दबा देती हैं
- आपातकालीन आवाज़ों को छोड़कर सुरक्षा सब कुछ टाल देती है
- नेविगेशन सुरक्षा और आपातकालीन ध्वनियों को छोड़कर बाकी सब कुछ छिपा देता है
- सुरक्षा, आपातकालीन और नेविगेशन ध्वनियों को छोड़कर बाकी सभी चीज़ों को कॉल करें
- वॉइस डक्स कॉल रिंग साउंड
- संगीत और घोषणाओं को हर चीज़ से दूर रखा जाना चाहिए
ये नियम संपूर्ण नहीं हैं और ओईएम यह निर्धारित करने के लिए जिम्मेदार हैं कि इन दिशानिर्देशों के आधार पर ध्वनियों को कैसे कम किया जाना चाहिए। OEM उपलब्ध आवश्यकताओं के आधार पर इन अनुशंसाओं को अधिक सक्रिय रूप से नियंत्रित कर सकते हैं। OemCarDuckingService को Android 14 में पेश किया गया है:
class OemCarAudioDuckingService {
List<AudioAttributes> evaluateAttributesToDuck(
OemCarAudioVolumeRequest request);
}
इस एपीआई को ऑडियो फोकस परिवर्तनों पर कार ऑडियो सेवा से कॉल किया जाता है। यह OEM कार वॉल्यूम सेवा में पेश किए गए OemCarAudioVolumeRequest पुन: उपयोग करता है, और इसमें यह निर्णय लेने के लिए प्रासंगिक जानकारी शामिल है कि किस विशेषता को डक करना है। एपीआई से डक करने के लिए ऑडियो विशेषताओं की सूची की तुलना वर्तमान ऑडियो स्थिति से की गई है:
ऑडियो विशेषता फिलहाल गायब है:
- सूची में, लगातार अनदेखा किया जा रहा है
- सूची में नहीं, डकिंग बंद कर दी गई
ऑडियो विशेषता वर्तमान में डक नहीं की गई है:
- सूची में, बत्तख
- सूची में नहीं, डकिंग बंद कर दी गई
कार ऑडियो सेवा तब यह निर्धारित करती है कि ऑडियो विशेषताएँ किस ऑडियो आउटपुट डिवाइस से संबंधित हैं और उन्हें क्रमशः डक्ड ऑडियो आउटपुट डिवाइस सूची या अनडक्ड ऑडियो डिवाइस सूची में जोड़ती है। हार्डवेयर स्तर पर आवश्यक डकिंग करने के लिए इसे अंततः ऑडियोकंट्रोल एचएएल को भेजा जाता है।
जब OEM डकिंग सेवा का उपयोग किया जाता है तो नीचे दिया गया चित्र फोकस अनुरोध के लिए ऑडियो डकिंग नियंत्रण का सरलीकृत अनुक्रम आरेख दिखाता है:
अनुक्रम तब शुरू होता है जब कोई ऐप सार्वजनिक ऑडियो प्रबंधक एपीआई के माध्यम से ऑडियो फोकस प्रबंधित करने का अनुरोध करता है। परिणाम निर्धारित करने के लिए अनुरोध कार ऑडियो सेवा को भेज दिया जाता है। जब ऑडियो फोकस तय किया जाता है, तो ऑडियो डकिंग का मूल्यांकन कार ऑडियो सेवा द्वारा OemCarAudioDuckingService को कॉल करके किया जाता है ताकि यह मूल्यांकन किया जा सके कि कौन सी ऑडियो विशेषताओं को डक किया जाना चाहिए। एक बार जब परिणाम evaluateAttributesToDuck एपीआई से वापस आ जाते हैं, तो डक करने के लिए ऑडियो डिवाइस की गणना की जाती है, और अंत में ऑडियो हार्डवेयर पर डकिंग लागू करने के लिए जानकारी AudioControl को भेजी जाती है।
OEM कार ऑडियो सेवा संदर्भ कार्यान्वयन
AAOS packages/services/Car/tests/OemCarServiceTestApp में OEM कार सेवा का एक संदर्भ कार्यान्वयन प्रदान करता है, जो OemCarAudioFocusService , OemCarAudioDuckingService और OemCarAudioVolumeService के साथ OemCarService लागू करता है। बाद के लिए, प्रत्येक सेवा स्थिर व्यवहार को लोड करने के लिए XML फ़ाइल का उपयोग करती है। उदाहरण के लिए, OemCarAudioFocusServiceImp oem_focus_config.xml लोड करता है, जिसमें एक इंटरेक्शन मैट्रिक्स होता है। जब evaluateAudioFocusRequest कॉल किया जाता है तो फोकस अनुरोध का मूल्यांकन करने के लिए मैट्रिक्स का उपयोग किया जाता है।
संदर्भ परीक्षण ऐप डिबगिंग
OEM कार सेवा परीक्षण ऐप 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 इंगित करता है कि यह तैयार नहीं है।