एंड्रॉइड डेवलपमेंट के पहले इंप्रेशन - हैंड्सफ्री लिखें

अभी हाल ही में, मुझे एक एंड्रॉइड (एलजी ऑप्टिमस) मिला और उसने इसके लिए सॉफ्टवेयर लिखने में अपना हाथ आजमाने का फैसला किया। प्लेटफ़ॉर्म डिवाइस के बारे में पढ़ने के बाद, सबसे पहले मैं इसकी सादगी, सुविधा और तर्क के लिए बहुत खुश था। लेकिन व्यवहार में, सब कुछ इतने रसदार से दूर हो गया ...



एक परीक्षण के रूप में, पेन ने एक एप्लिकेशन लिया, जो हेडसेट कनेक्ट होने पर स्वचालित रूप से इनकमिंग कॉल का जवाब देगा। यह अजीब है, निश्चित रूप से, इस तरह के एक साधारण कार्य "बॉक्स से बाहर" प्रणाली में मौजूद नहीं है। हां, और बाजार में केवल एक आवेदन था जो ऐसा कर सकता है, और बहुत विश्वसनीय नहीं है। आइए इस गलतफहमी को ठीक करने की कोशिश करते हैं।



पहली नज़र में, आवेदन बहुत सरल होना चाहिए:

1. मैनिफ़ेस्ट में, पंक्ति की स्थिति ( TelephonyManager.ACTION_PHONE_STATE_CHANGED ) और आने वाली कॉल की निगरानी के बारे में संदेशों के लिए रिसीवर लटकाएं।
2. जब कोई कॉल आती है, तो हम यह जांचते हैं कि हेडसेट कनेक्ट है या नहीं। मैं मुख्य रूप से ब्लूटूथ में रुचि रखता था, लेकिन एक वायर्ड हेडसेट का ट्रैक रखना अच्छा होगा।
3. यदि हेडसेट जुड़ा हुआ है, तो हम फोन को कॉल का जवाब देने के लिए कहते हैं।

पहले पैराग्राफ के साथ कोई विशेष समस्याएं नहीं थीं। लेकिन अन्य दो इतने तुच्छ नहीं थे।

एक कॉल का उत्तर दें

मैं तीसरे पैराग्राफ से शुरू करता हूँ। इनकमिंग कॉल का जवाब देने के लिए Android के पास API नहीं है। यदि संस्करणों में 1.x अभी भी कुछ अनिर्दिष्ट वर्गों और तरीकों की अनुमति देता है जो इसे अनुमति देते हैं, तो मेरे 2.2 में ये सभी छेद मज़बूती से बंद थे। सुंदर googling ने एक ही तरह से पाया: हेडसेट पर एक बटन प्रेस चित्रित करें ( Intent.ACTION_MEDIA_BUTTON , KeyEvent.KEYCODE_HEADSETHOOK )। सच है, सूक्ष्मताएं हैं। इस घटना को sendOrderedBroadcast (नहीं sendBroadcast ) के माध्यम से भेजा जाना चाहिए। अन्यथा, यह सभी रिसीवर्स को टक्कर देगा, और उनमें से, उदाहरण के लिए, एक ऑडियो प्लेयर हो सकता है, जो अगर कुछ करने के लिए खेलता है तो वह तुरंत शुरू हो जाएगा। दिलचस्प बात यह है कि एमुलेटर में, ऑर्डर किए गए प्रसारण का उपयोग करने पर भी खिलाड़ी शुरू हो जाता है, हालांकि यह सब कुछ उसी तरह काम करता है जैसा कि फोन पर होना चाहिए। एमुलेटर और लोहे के बीच एक और अंतर: पहले में, यह बटन जारी करने के बारे में एक संदेश भेजने के लिए पर्याप्त है (वैसे, खिलाड़ी केवल दबाने के संदेश से शुरू होता है)। फोन में, एक क्लिक और एक रिलीज़ दोनों उत्पन्न करना आवश्यक है। वे कहते हैं कि 1.x में यह इंजेक्टीन फ़ंक्शन (या कुछ इसी तरह) के निचले हिस्से में जाना संभव था और यह अधिक सही होगा। लेकिन 2.2 में, इस फ़ंक्शन की सुरक्षा की मरम्मत की गई थी और यह उपलब्ध नहीं है।

हेडसेट की स्थिति

अब सबसे कठिन भाग 2 है। जांचें कि क्या हेडसेट जुड़ा हुआ है। समस्या समान है - एंड्रॉइड में कोई तैयार एपीआई नहीं है जो आपको पता लगाने की अनुमति देता है। और इससे भी अधिक दिलचस्प, वायर्ड और वायरलेस हेडसेट के लिए कार्य अलग-अलग होंगे।



सिद्धांत रूप में, दोनों हेडसेट के लिए आप कनेक्शन / वियोग संदेश को ट्रैक कर सकते हैं, जो कि मैंने शुरू किया है। वायर्ड के लिए, यह Intent.ACTION_HEADSET_PLUG है (हेडसेट की स्थिति को एक अतिरिक्त पैरामीटर के रूप में पारित किया गया है), वायरलेस के लिए, BluetoothDevice.ACTION_ACL_CONNECTED और BluetoothDevice.ACTION_ACL_DISCONNECTED संदेशों की एक जोड़ी।



पहली बात यह है कि आप इन संदेशों के प्राप्तकर्ताओं को सीधे प्रकट में पंजीकृत करना चाहते हैं ताकि आप कुछ भी याद न करें। वायरलेस हेडसेट के साथ, यह संख्या पास हो जाती है, लेकिन ACTION_HEADSET_PLUG किसी कारण से ध्वज FLAG_RECEIVER_Rector_ONLY के साथ भेजा जाता है, अर्थात , प्रकट से प्राप्तकर्ताओं को यह प्राप्त नहीं होता है (प्रलेखन इसके बारे में कुछ नहीं कहता है, इसलिए यह एक त्रुटि की तरह दिखता है)। उन्हें कोड में पंजीकृत करना आवश्यक है। और इसका मतलब है कि आपको एक सेवा शुरू करनी होगी जो प्रोग्राम को वांछित रिसीवर को पंजीकृत करती है और हर समय चलती रहेगी। यहां, हालांकि, एक रेक भी है: ऐसी सेवा को सिस्टम द्वारा किसी भी समय मारा जा सकता है (जो परीक्षण प्रक्रिया के दौरान हुआ था), जिसके परिणामस्वरूप हम कुछ संदेशों को छोड़ सकते हैं। जाहिर है, बाजार से उस एकल एप्लिकेशन में एक समान दृष्टिकोण का उपयोग किया गया था, जिसका मैंने लेख की शुरुआत में उल्लेख किया था - यह हमेशा समय में हेडसेट के कनेक्शन का निर्धारण नहीं करता था। मुझे इसे अपने हाथों से चलाना था।



बाहर निकलने का रास्ता मिल गया था। तथ्य यह है कि ACTION_HEADSET_PLUG संदेश चिपचिपा है बचाव के लिए आता है। यही है, नवीनतम हेडसेट की स्थिति सभी नए पंजीकृत श्रोताओं को बताई गई है। यह पता चलता है कि वायरलेस हेडसेट की स्थिति किसी भी समय रजिस्टरराइवर (नल, हेडसेटप्लगफिल्टर) को कॉल करके और लौटे हुए इरादे की जांच करके की जा सकती है। यह प्रसन्न करता है। सेवा की आवश्यकता नहीं है, वायर्ड हेडसेट के लिए बिंदु 2 कार्यान्वित किया जाता है।



हम वायरलेस हेडसेट की ओर मुड़ते हैं। यहां आपको पहले से ही कनेक्शन / डिस्कनेक्शन संदेशों की निगरानी करना होगा - किसी भी समय हेडसेट की वर्तमान स्थिति की जांच नहीं की जा सकती है। लेकिन आप रिसीवर को पंजीकृत करने के लिए मैनिफ़ेस्ट का उपयोग कर सकते हैं। एक और नुकसान यह है कि वर्तमान स्थिति को कहीं संग्रहीत करने की आवश्यकता है, लेकिन आप इसके लिए सामान्य चर का उपयोग नहीं कर सकते, क्योंकि कॉल के बीच कोई कोड निष्पादित नहीं होता है। मैंने इस उद्देश्य के लिए आवेदन सेटिंग्स में एक छिपे हुए पैरामीटर को चुना। इस अर्थ में छिपा हुआ है कि यह सेटिंग्स विंडो में प्रकट नहीं होता है (मैं इस विंडो पर विचार नहीं करूंगा - वहां सब कुछ सरल है)।

प्रतीक्षा को बुलाओ

मैं एक और महत्वपूर्ण बिंदु के बारे में भूल गया। यदि कोई व्यक्ति पहले से ही फोन पर बात कर रहा है, तो सबसे अधिक संभावना है, उसे स्वचालित रूप से उत्तर देने के लिए नई इनकमिंग कॉल की आवश्यकता नहीं है। मैंने सेटिंग्स में इसके लिए एक अलग विकल्प बनाया। तदनुसार, जवाब देने से पहले, हमें यह देखना होगा कि क्या कॉल के समय हमारी सक्रिय बातचीत हुई थी। फिर, एपीआई इसके लिए कोई साधन प्रदान नहीं करता है। सभी उपलब्ध है कि कॉल के लिए पहले से ही काम कर रहे रिसीवर उपलब्ध है। हम ऑफहूक या बेकार में फोन की स्थिति में बदलाव को ट्रैक कर सकते हैं। लेकिन इस राज्य (जैसे वायरलेस हेडसेट की स्थिति) के भंडारण के लिए एप्लिकेशन सेटिंग्स का उपयोग करना काफी महंगा हो सकता है। इसलिए, हमें फिर से एक काम करने वाली सेवा की आवश्यकता है जो ऑफहूक स्थिति को स्मृति में संग्रहीत करेगी। और गलत समय पर सिस्टम को मारने वाली सेवा की संभावना को कम करने के लिए, आप इसे अस्थायी रूप से startForeground के माध्यम से शुरू कर सकते हैं। जब कॉल पूरी हो जाती हैं, तो स्टॉपफोरग्राउंड कॉल करके सेवा को रोका जा सकता है।

छापों

नतीजतन, योजना को लागू किया गया था, हालांकि इसके लिए मुझे योजना से अधिक कोड लिखना पड़ा, और परिणाम बहुत साफ नहीं दिखता है। ईमानदारी से, मुझे अभी भी समझ में नहीं आया है कि एपीआई के पास आइसहेडसेटकनेक्टेड और answerCall जैसे तैयार कार्य क्यों नहीं हैं, जो जीवन को बहुत सरल बना देगा।



वैसे, मेरी मूल योजना में TextToSpeech का उपयोग करके कॉलर को घोषित करने का एक और विकल्प था। लेकिन यह पता चला कि आप कॉल के समय टीटीएस से वायरलेस हेडसेट में ध्वनि को पुनर्निर्देशित नहीं कर सकते हैं (यदि किसी को रास्ता पता है, तो इसे साझा करें), लेकिन आपकी जेब में फोन में बात करने का कोई मतलब नहीं है। मैंने परेशान नहीं किया - मैंने इस समारोह को पूरी तरह से फेंक दिया। हालांकि, निश्चित रूप से, थोड़ा खेद है।



सामान्य तौर पर, प्लेटफ़ॉर्म की सुविधा अब तक केवल एक सिद्धांत बन गई है। व्यवहार में, आप लगातार अजीब और अतार्किक प्रतिबंधों में भागते हैं, और हमेशा उनके आसपास रहना संभव नहीं है। लेकिन विचार अच्छा है। देखते हैं आगे क्या होता है। मुझे आशा है कि वे एपीआई को दिमाग में लाएंगे और इसका उपयोग वास्तव में अच्छा होगा।