साल 2026 से, हम अपने ट्रंक स्टेबल डेवलपमेंट मॉडल के साथ अलाइन होने के लिए, दूसरी और चौथी तिमाही में AOSP पर सोर्स कोड पब्लिश करेंगे. इससे यह पक्का किया जा सकेगा कि प्लैटफ़ॉर्म, पूरे सिस्टम के लिए स्थिर बना रहे. हमारा सुझाव है कि AOSP को बनाने और उसमें योगदान देने के लिए, aosp-main के बजाय android-latest-release का इस्तेमाल करें. android-latest-release मेनिफ़ेस्ट ब्रांच, हमेशा AOSP पर पुश की गई सबसे नई रिलीज़ का रेफ़रंस देगी. ज़्यादा जानकारी के लिए, AOSP में हुए बदलाव लेख पढ़ें.
Google uses AI technology to translate content into your preferred language. AI translations can contain errors.
ऑडियो से जुड़ी नीतियां कॉन्फ़िगर करना
संग्रह की मदद से व्यवस्थित रहें
अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.
Android 10 की रिलीज़ में, ऑडियो पॉलिसी मैनेजर को फिर से बनाया गया है. इससे कार में इस्तेमाल होने वाले ऐप्लिकेशन के लिए, ज़्यादा विकल्प उपलब्ध कराए जा सकेंगे:
OEM के हिसाब से राउटिंग की रणनीतियां.
लेगसी स्ट्रीम टाइप के ग्रुप के लिए, आवाज़ के लेवल को पसंद के मुताबिक सेट करने की सुविधा. इसके लिए, एक ही वॉल्यूम कर्व का इस्तेमाल किया जाता है.
ऑडियो नीति इंजन के ज़रिए तय की गई राउटिंग की रणनीतियां, हार्ड कोड नहीं की जाती हैं.
ऑडियो नीति इंजन, वॉल्यूम कर्व और ग्रुप मैनेज करता है.
इंटरनल रिफ़ैक्टरिंग, सामान्य कोड और कॉन्फ़िगर किए जा सकने वाले कोड के बीच फ़्यूचर स्प्लिट की तैयारी कर रही है. साथ ही, बेहतर ऑडियो डिवाइस मैनेजमेंट की सुविधा दे रही है. उदाहरण के लिए, नीति के नियमों में डिवाइस की सभी प्रॉपर्टी का इस्तेमाल करना. सिर्फ़ डिवाइस के टाइप का नहीं.
Android 7.0 में, ऑडियो टोपोलॉजी के बारे में बताने के लिए, ऑडियो नीति कॉन्फ़िगरेशन फ़ाइल फ़ॉर्मैट (एक्सएमएल) पेश किया गया था.
Android के पिछले वर्शन में, आपके प्रॉडक्ट पर मौजूद ऑडियो डिवाइसों के बारे में जानकारी देने के लिए, device/<company>/<device>/audio/audio_policy.conf का इस्तेमाल करना ज़रूरी था. Galaxy Nexus के ऑडियो हार्डवेयर के लिए, इस फ़ाइल का उदाहरण device/samsung/tuna/audio/audio_policy.conf में देखा जा सकता है. हालांकि, CONF एक आसान, मालिकाना हक वाला फ़ॉर्मैट है. यह टेलीविज़न और ऑटोमोबाइल जैसे वर्टिकल के लिए, जटिल टोपोलॉजी के बारे में बताने के लिए बहुत सीमित है.
Android 7.0 में audio_policy.conf को बंद कर दिया गया था. साथ ही, एक्सएमएल फ़ाइल फ़ॉर्मैट का इस्तेमाल करके ऑडियो टोपोलॉजी को तय करने की सुविधा जोड़ी गई थी. यह फ़ॉर्मैट, लोगों के लिए ज़्यादा आसानी से पढ़ा जा सकता है. इसमें एडिटिंग और पार्सिंग के कई टूल होते हैं. साथ ही, यह जटिल ऑडियो टोपोलॉजी के बारे में बताने के लिए काफ़ी फ़्लेक्सिबल होता है. Android 7.0, कॉन्फ़िगरेशन फ़ाइलों के एक्सएमएल फ़ॉर्मैट को चुनने के लिए USE_XML_AUDIO_POLICY_CONF बिल्ड फ़्लैग का इस्तेमाल करता है.
एक्सएमएल फ़ॉर्मैट के फ़ायदे
CONF फ़ाइल की तरह ही, एक्सएमएल फ़ाइल में आउटपुट और इनपुट स्ट्रीम प्रोफ़ाइलों की संख्या और टाइप, प्लेबैक और कैप्चर के लिए इस्तेमाल किए जा सकने वाले डिवाइस, और ऑडियो एट्रिब्यूट तय किए जा सकते हैं. इसके अलावा, एक्सएमएल फ़ॉर्मैट में ये बेहतर सुविधाएं मिलती हैं:
Android 10 में, एक साथ एक से ज़्यादा ऐक्टिव रिकॉर्डिंग ऐप्लिकेशन इस्तेमाल किए जा सकते हैं.
एक साथ कई रिकॉर्डिंग होने की वजह से, रिकॉर्डिंग शुरू करने के अनुरोध को कभी अस्वीकार नहीं किया जाता.
registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb)
कॉल बैक, क्लाइंट को कैप्चर पाथ में हुए बदलावों के बारे में सूचना देता है.
इन स्थितियों में, क्लाइंट को साइलेंट ऑडियो सैंपल मिलते हैं:
निजता से जुड़ा कोई इस्तेमाल का उदाहरण (जैसे, VOICE_COMMUNICATION) चालू है.
क्लाइंट के पास फ़ोरग्राउंड सेवा या फ़ोरग्राउंड यूज़र इंटरफ़ेस (यूआई) नहीं है.
नीति में इन खास भूमिकाओं को मान्यता दी गई है:
सुलभता सेवा: निजता से जुड़े इस्तेमाल के उदाहरण के चालू होने पर भी रिकॉर्ड कर सकती है.
Assistant: अगर यूज़र इंटरफ़ेस (यूआई) सबसे ऊपर है, तो इसे निजता के लिहाज़ से संवेदनशील माना जाता है.
ऑडियो प्रोफ़ाइल का स्ट्रक्चर, एचडीएमआई के सामान्य ऑडियो डिस्क्रिप्टर जैसा होता है. इससे हर ऑडियो फ़ॉर्मैट के लिए, सैंपलिंग रेट/चैनल मास्क का अलग सेट इस्तेमाल किया जा सकता है.
डिवाइसों और स्ट्रीम के बीच सभी संभावित कनेक्शन के बारे में साफ़ तौर पर बताया गया है.
पहले, एक नियम के तहत एक ही एचएएल मॉड्यूल से जुड़े सभी डिवाइसों को कनेक्ट किया जा सकता था. इससे ऑडियो नीति, ऑडियो पैच एपीआई के ज़रिए किए गए कनेक्शन को कंट्रोल नहीं कर पाती थी. एक्सएमएल फ़ॉर्मैट में, टोपोलॉजी की जानकारी से कनेक्शन की सीमाओं के बारे में पता चलता है.
शामिल है के लिए सहायता से, स्टैंडर्ड A2DP, यूएसबी या फिर से सबमिट करने की परिभाषाओं को दोहराने से बचा जा सकता है.
वॉल्यूम कर्व को पसंद के मुताबिक बनाया जा सकता है. पहले, वॉल्यूम टेबल को हार्डकोड किया जाता था. वॉल्यूम टेबल को XML फ़ॉर्मैट में दिखाया जाता है. साथ ही, इन्हें पसंद के मुताबिक बनाया जा सकता है.
frameworks/av/services/audiopolicy/config/audio_policy_configuration.xml पर मौजूद टेंप्लेट में, इनमें से कई सुविधाओं का इस्तेमाल दिखाया गया है.
फ़ाइल फ़ॉर्मैट और जगह
ऑडियो से जुड़ी नई नीति की कॉन्फ़िगरेशन फ़ाइल audio_policy_configuration.xml है और यह /system/etc में मौजूद है. यहां दिए गए उदाहरणों में, Android 12 और इससे पहले के वर्शन के लिए, XML फ़ाइल फ़ॉर्मैट में ऑडियो नीति का सामान्य कॉन्फ़िगरेशन दिखाया गया है.
Android 12 के लिए, ऑडियो से जुड़ी नीति का उदाहरण दिखाओ
टॉप-लेवल के स्ट्रक्चर में ऐसे मॉड्यूल होते हैं जो हर ऑडियो एचएएल हार्डवेयर मॉड्यूल से जुड़े होते हैं. हर मॉड्यूल में मिक्स पोर्ट, डिवाइस पोर्ट, और राउट की सूची होती है:
मिक्स पोर्ट, स्ट्रीम के लिए कॉन्फ़िगरेशन प्रोफ़ाइल के बारे में बताते हैं. इन्हें ऑडियो एचएएल में, चलाने और कैप्चर करने के लिए खोला जा सकता है.
डिवाइस पोर्ट, उन डिवाइसों के बारे में बताते हैं जिन्हें उनके टाइप के साथ अटैच किया जा सकता है. साथ ही, अगर ज़रूरी हो, तो पते और ऑडियो प्रॉपर्टी के बारे में भी बताते हैं.
Routes को मिक्स पोर्ट डिस्क्रिप्टर से अलग किया जाता है. इससे डिवाइस से डिवाइस या स्ट्रीम से डिवाइस तक के रूट की जानकारी मिलती है.
वॉल्यूम टेबल, पॉइंट की सामान्य सूचियां होती हैं. इनमें, यूज़र इंटरफ़ेस (यूआई) इंडेक्स को डेसिबल (डीबी) में बदलने के लिए इस्तेमाल किए गए कर्व के बारे में बताया जाता है. अलग से शामिल की गई फ़ाइल में डिफ़ॉल्ट कर्व दिए जाते हैं. हालांकि, इस्तेमाल के किसी तरीके और डिवाइस कैटगरी के लिए हर कर्व को बदला जा सकता है.
एक्सएमएल इन्क्लूज़न (XInclude) तरीके का इस्तेमाल करके, ऑडियो से जुड़ी नीति के कॉन्फ़िगरेशन की जानकारी को शामिल किया जा सकता है. यह जानकारी अन्य एक्सएमएल फ़ाइलों में मौजूद होती है. शामिल की गई सभी फ़ाइलों में, ऊपर बताया गया स्ट्रक्चर होना चाहिए. साथ ही, इन पाबंदियों का पालन करना ज़रूरी है:
फ़ाइलों में सिर्फ़ टॉप-लेवल के एलिमेंट शामिल किए जा सकते हैं.
फ़ाइलों में XInclude एलिमेंट नहीं होने चाहिए.
इसमें शामिल करें का इस्तेमाल, सभी ऑडियो नीति कॉन्फ़िगरेशन फ़ाइलों में स्टैंडर्ड Android ओपन सोर्स प्रोजेक्ट (AOSP) ऑडियो एचएएल मॉड्यूल कॉन्फ़िगरेशन की जानकारी कॉपी करने से बचने के लिए किया जाता है. ऐसा करने से, गड़बड़ियां होने की आशंका कम हो जाती है. ऑडियो HAL के लिए, स्टैंडर्ड ऑडियो नीति कॉन्फ़िगरेशन वाली एक्सएमएल फ़ाइल उपलब्ध कराई गई है. ये ऑडियो HAL इस तरह हैं:
A2DP:a2dp_audio_policy_configuration.xml
सबमिक्स को फिर से रूट करना:rsubmix_audio_policy_configuration.xml
यूएसबी:usb_audio_policy_configuration.xml
ऑडियो नीति के कोड का संगठन
AudioPolicyManager.cpp को कई मॉड्यूल में बांटा गया है, ताकि इसे आसानी से मैनेज और कॉन्फ़िगर किया जा सके. frameworks/av/services/audiopolicy के संगठन में ये मॉड्यूल शामिल हैं.
मॉड्यूल
ब्यौरा
/managerdefault
इसमें सामान्य इंटरफ़ेस और व्यवहार लागू करने की सुविधा शामिल होती है, जो सभी ऐप्लिकेशन में उपलब्ध होती है. यह AudioPolicyManager.cpp के जैसा ही है. इसमें इंजन की फ़ंक्शनैलिटी और सामान्य कॉन्सेप्ट को अलग कर दिया गया है.
/common
यह बेस क्लास तय करता है. जैसे, इनपुट आउटपुट ऑडियो स्ट्रीम प्रोफ़ाइलों, ऑडियो डिवाइस डिस्क्रिप्टर, ऑडियो पैच, और ऑडियो पोर्ट के लिए डेटा स्ट्रक्चर. इसे पहले AudioPolicyManager.cpp में तय किया गया था.
/engine
यह कुकी, उन नियमों को लागू करती है जिनसे यह तय होता है कि किसी इस्तेमाल के उदाहरण के लिए, किस डिवाइस और वॉल्यूम का इस्तेमाल किया जाना चाहिए. यह सामान्य हिस्से के साथ एक स्टैंडर्ड इंटरफ़ेस लागू करता है. जैसे, किसी दिए गए प्लेबैक या कैप्चर के इस्तेमाल के उदाहरण के लिए सही डिवाइस पाना या कनेक्ट किए गए डिवाइसों या बाहरी स्थिति (यानी, कॉल की स्थिति) को सेट करना. इससे राउटिंग के फ़ैसले में बदलाव किया जा सकता है.
नीति इंजन को लागू करने के लिए, पैरामीटर फ़्रेमवर्क का इस्तेमाल किया जाता है. इसके बारे में यहां बताया गया है.
कॉन्फ़िगरेशन, पैरामीटर फ़्रेमवर्क पर आधारित होता है. साथ ही, नीति को एक्सएमएल फ़ाइलों से तय किया जाता है.
/enginedefault
नीति इंजन को लागू करने की सुविधा, Android Audio Policy Manager को लागू करने की पिछली सुविधाओं पर आधारित है. यह डिफ़ॉल्ट सेटिंग है. इसमें हार्ड कोड किए गए ऐसे नियम शामिल होते हैं जो Nexus और AOSP के लागू करने के तरीके से मेल खाते हैं.
/service
इसमें बाइंडर इंटरफ़ेस, थ्रेडिंग, और फ़्रेमवर्क के बाकी हिस्सों के साथ इंटरफ़ेस के लिए लॉकिंग लागू करना शामिल है.
पैरामीटर फ़्रेमवर्क का इस्तेमाल करके कॉन्फ़िगरेशन
ऑडियो नीति के कोड को इस तरह से व्यवस्थित किया गया है कि इसे समझना और बनाए रखना आसान हो. साथ ही, यह कॉन्फ़िगरेशन फ़ाइलों से पूरी तरह से तय की गई ऑडियो नीति के साथ काम करता है. संगठन और ऑडियो नीति का डिज़ाइन, Intel के पैरामीटर फ़्रेमवर्क पर आधारित है. यह पैरामीटर को मैनेज करने के लिए, प्लगिन और नियम पर आधारित फ़्रेमवर्क है.
ऑडियो से जुड़ी नीति को कॉन्फ़िगर करने की सुविधा का इस्तेमाल करके, वेंडर और ओईएम ये काम कर सकते हैं:
किसी सिस्टम की संरचना और उसके पैरामीटर के बारे में एक्सएमएल में बताएं.
बताए गए पैरामीटर को ऐक्सेस करने के लिए, C++ में बैकएंड (प्लगिन) लिखें या उसका फिर से इस्तेमाल करें.
उन शर्तों/नियमों को तय करें (एक्सएमएल या डोमेन के हिसाब से तय की गई भाषा में), जिनके आधार पर किसी पैरामीटर को कोई वैल्यू असाइन की जानी चाहिए.
AOSP में, ऑडियो नीति कॉन्फ़िगरेशन फ़ाइल का एक उदाहरण शामिल है. यह Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml पर पैरामीटर फ़्रेमवर्क का इस्तेमाल करती है. ज़्यादा जानकारी के लिए, पैरामीटर फ़्रेमवर्क के बारे में Intel का दस्तावेज़ देखें.
Android 10 या इससे पहले के वर्शन में, कॉन्फ़िगर की जा सकने वाली ऑडियो नीति को बिल्ड विकल्प USE_CONFIGURABLE_AUDIO_POLICY का इस्तेमाल करके चुना जाता है.
Android 11 या इसके बाद के वर्शन में, ऑडियो नीति इंजन का वर्शन audio_policy_configuration.xml फ़ाइल में चुना जाता है.
कॉन्फ़िगर की जा सकने वाली ऑडियो नीति इंजन को चुनने के लिए, globalConfiguration एलिमेंट के engine_library एट्रिब्यूट की वैल्यू को configurable पर सेट करें. उदाहरण के लिए:
Android 6.0 में, सार्वजनिक Enumeration और Selection API लॉन्च किया गया था. यह ऑडियो पैच/ऑडियो पोर्ट इंफ़्रास्ट्रक्चर के ऊपर काम करता है. इससे ऐप्लिकेशन डेवलपर, कनेक्ट किए गए ऑडियो रिकॉर्ड या ट्रैक के लिए, किसी खास डिवाइस के आउटपुट या इनपुट को प्राथमिकता दे सकते हैं.
Android 7.0 में, CTS टेस्ट से Enumeration and Selection API की पुष्टि की जाती है. साथ ही, इसे नेटिव C/C++ (OpenSL ES) ऑडियो स्ट्रीम के लिए राउटिंग की सुविधा शामिल करने के लिए बढ़ाया जाता है.
नेटिव स्ट्रीम की राउटिंग अब भी Java में की जाती है. इसमें एक AudioRouting इंटरफ़ेस जोड़ा गया है. यह AudioTrack और AudioRecord क्लास के लिए खास तौर पर बनाए गए, साफ़ तौर पर राउटिंग के तरीकों को बदलता है, उन्हें जोड़ता है, और उन्हें बंद करता है.
Enumeration and Selection API के बारे में जानकारी के लिए, Android कॉन्फ़िगरेशन इंटरफ़ेस और OpenSLES_AndroidConfiguration.h देखें.
ऑडियो रूटिंग के बारे में ज़्यादा जानने के लिए, AudioRouting देखें.
मल्टी-चैनल की सुविधा
अगर आपका हार्डवेयर और ड्राइवर, एचडीएमआई के ज़रिए मल्टीचैनल ऑडियो की सुविधा के साथ काम करता है, तो ऑडियो स्ट्रीम को सीधे ऑडियो हार्डवेयर पर आउटपुट किया जा सकता है. इससे AudioFlinger मिक्सर बायपास हो जाता है. इसलिए, इसे दो चैनलों में डाउनमिक्स नहीं किया जाता. ऑडियो HAL को यह बताना होगा कि आउटपुट स्ट्रीम प्रोफ़ाइल, मल्टीचैनल ऑडियो की सुविधाओं के साथ काम करती है या नहीं. अगर HAL अपनी सुविधाएं उपलब्ध कराता है, तो डिफ़ॉल्ट नीति मैनेजर, एचडीएमआई पर मल्टीचैनल प्लेबैक की अनुमति देता है. लागू करने से जुड़ी जानकारी के लिए, device/samsung/tuna/audio/audio_hw.c देखें.
अगर आपको यह बताना है कि आपके प्रॉडक्ट में मल्टीचैनल ऑडियो आउटपुट की सुविधा है, तो ऑडियो नीति कॉन्फ़िगरेशन फ़ाइल में बदलाव करें. इससे आपके प्रॉडक्ट के लिए मल्टीचैनल आउटपुट के बारे में जानकारी दी जा सकेगी. frameworks/av/services/audiopolicy/config/primary_audio_policy_configuration_tv.xml के इस उदाहरण में, डाइनैमिक चैनल मास्क दिखाया गया है. इसका मतलब है कि ऑडियो नीति मैनेजर, एचडीएमआई सिंक से कनेक्ट होने के बाद, एचडीएमआई सिंक के साथ काम करने वाले चैनल मास्क के बारे में क्वेरी करता है.
आपके पास स्टैटिक चैनल मास्क भी तय करने का विकल्प होता है. जैसे, AUDIO_CHANNEL_OUT_5POINT1. जब ऑडियो डिवाइस पर मल्टीचैनल ऑडियो की सुविधा काम नहीं करती है, तो AudioFlinger का मिक्सर, कॉन्टेंट को अपने-आप स्टीरियो में डाउनमिक्स कर देता है.
मीडिया कोडेक
पक्का करें कि आपके प्रॉडक्ट के लिए, आपके हार्डवेयर और ड्राइवर के साथ काम करने वाले ऑडियो कोडेक सही तरीके से बताए गए हों. ज़्यादा जानकारी के लिए, कोडेक को फ़्रेमवर्क के लिए उपलब्ध कराना लेख पढ़ें.
इस पेज पर मौजूद कॉन्टेंट और कोड सैंपल कॉन्टेंट के लाइसेंस में बताए गए लाइसेंस के हिसाब से हैं. Java और OpenJDK, Oracle और/या इससे जुड़ी हुई कंपनियों के ट्रेडमार्क या रजिस्टर किए हुए ट्रेडमार्क हैं.
आखिरी बार 2026-06-18 (UTC) को अपडेट किया गया.
[[["समझने में आसान है","easyToUnderstand","thumb-up"],["मेरी समस्या हल हो गई","solvedMyProblem","thumb-up"],["अन्य","otherUp","thumb-up"]],[["वह जानकारी मौजूद नहीं है जो मुझे चाहिए","missingTheInformationINeed","thumb-down"],["बहुत मुश्किल है / बहुत सारे चरण हैं","tooComplicatedTooManySteps","thumb-down"],["पुराना","outOfDate","thumb-down"],["अनुवाद से जुड़ी समस्या","translationIssue","thumb-down"],["सैंपल / कोड से जुड़ी समस्या","samplesCodeIssue","thumb-down"],["अन्य","otherDown","thumb-down"]],["आखिरी बार 2026-06-18 (UTC) को अपडेट किया गया."],[],[]]