ओक्टोडॉन: गहरे भूमिगत जा रहा है

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


^{पैट्रिक प्लुल / एएफपी / गेटी इमेज द्वारा फोटो}

... और परिणाम शायद ही सुरुचिपूर्ण है।

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

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

यह संभव है कि हम क्या कर रहे हैं की एक और पूरी तस्वीर बनाने के लिए, आपको हमारे नेता एलेक्सिसेंको द्वारा लिखित पिछली पोस्ट को पढ़ने में रुचि होगी: राइट क्लिक की खोज में ओकटोडन कीबोर्ड

प्रोटोटाइप नंबर 1 - ब्लूटूथ

हमारे पहले प्रोटोटाइप ने ब्लूटूथ शेयरिंग का इस्तेमाल किया। ऐसा लगता है कि कीबोर्ड और फोन को जोड़ने के लिए और अधिक सुविधाजनक तकनीक नहीं हो सकती है, और विश्वास था कि सब कुछ बॉक्स से बाहर काम करेगा। लेकिन ऐसा हो नहीं पाया।
इस तथ्य के साथ पहली समस्या उत्पन्न हुई कि, 2.3 संस्करण के साथ शुरू, एंड्रॉइड ने सिस्टम में बीटी-कीबोर्ड के लिए अंतर्निहित समर्थन किया था। जैसे ही सिस्टम ने "युग्मित" कीबोर्ड का पता लगाया, उसने तुरंत इसे पकड़ लिया और इसे इनपुट टूल के रूप में उपयोग करना शुरू कर दिया। चूँकि हम ऐसा ही करने जा रहे थे, इसलिए हम ओकेडॉन जॉयस्टिक के एक क्लिक के साथ दो अक्षर - "हमारा" और "सिस्टम" को अनिवार्य रूप से प्रिंट करेंगे। किसी भी तरह अत्यधिक बातूनी एंड्रॉइड को मफल करना आवश्यक था। फोन "रुटेड" था, और कर्नेल और सिस्टम लाइब्रेरी के स्रोत कोड में खुदाई शुरू हुई ताकि आप कीबोर्ड कनेक्शन को अनदेखा कर सकें। यह स्थान कामवासना पुस्तकालय बन गया।
प्रपत्र की एक गंदी हैक को open_device फ़ंक्शन में पेश किया गया था:

if ((id.vendor == 0x05AC && id.product == 0x0239)) // VID  PID   { LOGI("Ignoring device %04x %04x", id.vendor, id.product); close(fd); fd = -1; return -1; } 

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

 private static BluetoothSocket createBluetoothSocket(int type, int fd, boolean auth, boolean encrypt, String address, int port) { try { Class[] parameterTypes = new Class[] { Integer.TYPE, // type Integer.TYPE, // fd Boolean.TYPE, // auth Boolean.TYPE, // encrypt String.class, // address Integer.TYPE // port }; Constructor<BluetoothSocket> constructor = BluetoothSocket.class.getDeclaredConstructor(parameterTypes); constructor.setAccessible(true); Object[] parameters = new Object[] { Integer.valueOf(type), Integer.valueOf(fd), Boolean.valueOf(auth), Boolean.valueOf(encrypt), address, Integer.valueOf(port), }; return (BluetoothSocket)constructor.newInstance(parameters); } catch (Exception ex) { return null; } } BluetoothSocket intrSocket = createBluetoothSocket(3 /* TYPE_L2CAP */, -1, false, false, "DC:2C:26:A0:C2:50" /* MAC-address */, 0x13 /* INTR port */); 

प्रकार के एक निजी निर्माता को बुला रहा है! जब कोड का प्रस्तुत टुकड़ा लिया और तुरंत अर्जित किया तो आश्चर्य और भी बढ़ गया। समझें कि क्या, कैसे और क्यों कोई समय नहीं था, इसलिए कोड को उस रूप में सही छोड़ दिया गया था। यह निम्न-स्तरीय विकास की कमियों में से एक है - आपको अक्सर इस तथ्य के साथ आना पड़ता है कि कोड का हिस्सा "जादुई रूप से" काम करता है: कोई नहीं जानता कि यह क्यों काम करता है, और कोई नहीं जानता कि अधिक सामान्य समाधान काम करने से इनकार क्यों करता है - सौभाग्य से, हमने जल्दी से इसे छोड़ दिया। ब्लूटूथ-कीबोर्ड, केवल एक प्रोटोटाइप के उपयोग के साथ बनाया गया था, इसलिए यह जादू जल्द ही समाप्त हो गया था।

प्रोटोटाइप # 2 - यूएसबी छिपाई कीबोर्ड

जैसे ही यह स्पष्ट हो गया कि तैयार उपकरणों का उपयोग हमें बहुत सीमित करता है, यह हमारे स्वयं के विकास के लिए तय किया गया था। इस समय हमने जिस मुख्य स्मार्टफोन पर ध्यान केंद्रित किया, वह सैमसंग गैलेक्सी एस 2 था। उसके पास एक सामान्य और स्थिर यूएसबी-होस्ट था, जिसे हम कनेक्ट करने जा रहे थे। टेनेसी 1.0 को नियंत्रक के रूप में लिया गया था। यह बहुत गलत निकला कि हमारे पास कुछ अवसर थे, और यह कि हाल के संस्करण, 2.0 को लिया जाना चाहिए। अंतर पुस्तकालयों में छिपा-संगत उपकरणों को बनाने के लिए था। यदि 1.0 केवल एक छिपकली कीबोर्ड या माउस होने का दिखावा कर सकता है, तो 2.0 पर हमारे अपने प्रोटोकॉल का उपयोग करके अधिक सार्वभौमिक रॉ छिपाई डिवाइस को लागू करना संभव था। लेकिन क्या करना है, पहले क्या था के साथ संतोष करना पड़ा। HID- कीबोर्ड का अनुकरण करते समय, ऊपर वर्णित समस्या फिर से उत्पन्न हुई - जब कनेक्ट होती है, तो सिस्टम ने इसे एक इनपुट डिवाइस के रूप में कैप्चर किया, और भेजे गए अक्षर दो बार - हमारे और ओएस द्वारा मुद्रित किए गए।

ऊपर वर्णित समाधान अब उपयुक्त नहीं था - उन्होंने फैसला किया कि हमारे पास पर्याप्त सिस्टम परिवर्तन थे। यदि हम एक उपकरण बनाना चाहते हैं जो बाजार में जारी किया जा सकता है, तो इसे किसी भी गैलेक्सी एस 2 पर काम करना चाहिए, इसमें चमकती की आवश्यकता नहीं होनी चाहिए।

एस 2 से जुड़े एक नियमित यूएसबी कीबोर्ड के साथ प्रयोग करने की प्रक्रिया में, यह पता चला कि किसी कारण से स्मार्टफोन कीबोर्ड के डिजिटल हिस्से में बटन प्रेस का जवाब नहीं देता है। यह एक गंभीर मदद बन गई, क्योंकि हमारी टेनीस किसी तरह ऑक्टोडन जॉयस्टिक्स के विचलन को सांख्यिक बटन दबाने में संलग्न कर सकती थी। जॉयस्टिक की स्थिति में प्रत्येक परिवर्तन के लिए, हमने 3 बाइट्स के पैकेज भेजने शुरू किए:

1. स्कैन कोड "Num 0" ... "Num 9" जॉयस्टिक की संख्या है जिसकी स्थिति हम प्रेषित कर रहे हैं।
2. स्कैन कोड "Num 0" ... "Num 4" - जॉयस्टिक विचलन की दिशा। 0 - बाईं ओर, 1 - नीचे, ..., 4 - केंद्रीय दबाव।
3. "Num +" यदि कोई प्रेस या "Num -" है तो जारी किया गया।

इस प्रकार, बाईं ओर पहले जॉयस्टिक के एक सरल धक्का ने हमें "00+" का अनुक्रम दिया, "00-" को जारी किया। एक जॉयस्टिक जारी किए बिना, आप दूसरे को अस्वीकार कर सकते हैं - इस तरह आप कई बटन के एक साथ दबाने को एन्कोड कर सकते हैं, जिसे हमें शिफ्ट मोड के लिए वास्तव में आवश्यक था।

फिर भी, वहाँ अभी भी किसी भी तरह से प्रेषित scancodes प्राप्त करने के लिए एक कार्य था। सिस्टम एपीआई ने उन्हें नजरअंदाज किया, इसलिए मुझे गहराई तक जाना पड़ा। सौभाग्य से हमारे लिए, Android * nix है, और यह एक फ़ाइल है। वांछित फ़ाइल / देव / इनपुट में थी, और आकाश में तारों के स्थान के आधार पर, इसे इवेंट 7 या ईवेंट 8 कहा जाता था। केवल रूट की पहुंच थी, इसलिए डिवाइस को रूट होना था, लेकिन वह सब था और सीमित था - एक फ्लैशिंग की आवश्यकता नहीं थी। एंड्रॉइड में रूट का उपयोग करना एक दिलचस्प काम है, क्योंकि एपीआई के माध्यम से उचित अधिकार प्राप्त करने का कोई तरीका नहीं है (या हम इसे नहीं ढूंढ सके)। इसलिए, हम टर्मिनल के माध्यम से सीधे सब कुछ करते हैं:

 Process root = Runtime.getRuntime().exec("su"); //   su DataOutputStream shellStream = new DataOutputStream(root.getOutputStream()); shellStream.writeBytes("cat /dev/input/event7 & && cat /dev/input/event8 &"); //     ,    ,    InputStream inputStream = root.getInputStream(); InputStream errorStream = root.getErrorStream(); //  16-    byte[] buf = new byte[16]; if (inputStream.available() > 15) { int data = inputStream.read(buf, 0, 16); } 

इस तरह से काम करने वाला प्रोटोटाइप लंबे समय से अस्तित्व में है, कई प्रदर्शनियों को पारित किया है, और अभी भी जीवित है। समय के साथ, कोड को एन्बोल्ड किया गया, और हार्डकोड के बजाय डिवाइस फ़ाइल नाम को कॉन्फ़िगर फ़ाइल के माध्यम से निर्दिष्ट किया जाने लगा।

खैर, फिर आया स्वर्ण युग। गैलेक्सी एस 2 के लिए 4 वां एंड्रॉइड निकला, और टेनी 2.0 का ऑर्डर हमारे पास आया। नए OS में दिखाई देने वाले USB होस्ट API के साथ नए रॉ HID कंट्रोलर के आधार पर विकसित डिवाइस का डॉकिंग इतना स्मूद था कि समस्याओं के बारे में बात करने के लिए बनाए गए इस निबंध के ढांचे में फिट नहीं बैठता। एक पुराना सपना सच हुआ, ऑक्टोडन इसके साथ कुछ भी किए बिना "स्टॉक" स्मार्टफोन पर काम करने में सक्षम था। हमें छोटे पैमाने पर नमूनों का उत्पादन करने का अवसर मिला जो बस काम करते हैं, और उन्हें एक फ़ाइल के साथ ध्यान में लाने की आवश्यकता नहीं है। लेकिन बैसाखी के बिना सुंदर समाधान एक अलग लेख के लिए एक विषय है, खासकर जब से हबर के पृष्ठों पर ऐसा लगता है कि उन्होंने यूएसबी पर यूएसबी होस्ट एपीआई के साथ काम करने के बारे में कभी बात नहीं की। तो जारी रखा जाए!