कीबोर्ड डिवाइस

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

Android, कई तरह के कीबोर्ड डिवाइसों के साथ काम करता है. इनमें खास फ़ंक्शन वाले कीपैड (वॉल्यूम और पावर कंट्रोल), छोटे एम्बेड किए गए QWERTY कीबोर्ड, और सभी सुविधाओं वाले पीसी स्टाइल के बाहरी कीबोर्ड शामिल हैं.

इस दस्तावेज़ में सिर्फ़ फ़िज़िकल कीबोर्ड के बारे में बताया गया है. सॉफ़्ट कीबोर्ड (इनपुट मेथड एडिटर) के बारे में जानकारी के लिए, Android SDK टूल देखें.

कीबोर्ड की कैटगरी तय करना

किसी इनपुट डिवाइस को कीबोर्ड के तौर पर तब माना जाता है, जब इनमें से कोई एक शर्त पूरी होती है:

• इनपुट डिवाइस, कीबोर्ड पर इस्तेमाल किए जाने वाले किसी भी Linux की कोड की मौजूदगी की जानकारी देता है. इसमें 0 से 0xff या KEY_OK से KEY_MAX तक के कोड शामिल हैं.

• इनपुट डिवाइस, जॉयस्टिक और गेमपैड पर इस्तेमाल किए जाने वाले किसी भी Linux की कोड की मौजूदगी की जानकारी देता है. इनमें BTN_0 से BTN_9, BTN_TRIGGER से BTN_DEAD या BTN_A से BTN_THUMBR तक के कोड शामिल हैं.

फ़िलहाल, जॉयस्टिक को कीबोर्ड के तौर पर वर्गीकृत किया जाता है, क्योंकि जॉयस्टिक और गेमपैड बटन को EV_KEY इवेंट की मदद से उसी तरह रिपोर्ट किया जाता है जिस तरह कीबोर्ड बटन को रिपोर्ट किया जाता है. इसलिए, जॉयस्टिक और गेमपैड भी कॉन्फ़िगरेशन के लिए, बटन मैप फ़ाइलों का इस्तेमाल करते हैं.

किसी इनपुट डिवाइस को कीबोर्ड के तौर पर कैटगरी में बांटने के बाद, सिस्टम उस कीबोर्ड के लिए इनपुट डिवाइस कॉन्फ़िगरेशन फ़ाइल और कीबोर्ड लेआउट लोड करता है.

इसके बाद, सिस्टम डिवाइस की अन्य विशेषताओं का पता लगाने की कोशिश करता है.

• अगर इनपुट डिवाइस में कोई ऐसी बटन है जो KEYCODE_Q पर मैप की गई है, तो डिवाइस में अक्षर वाला कीपैड माना जाता है, न कि अंकों वाला. अंग्रेज़ी के अक्षरों वाले कीपैड की सुविधा को, संसाधन Configuration ऑब्जेक्ट में KEYBOARD_QWERTY के तौर पर रिपोर्ट किया जाता है.

• अगर इनपुट डिवाइस में कोई ऐसी बटन मौजूद है जो KEYCODE_DPAD_UP, KEYCODE_DPAD_DOWN, KEYCODE_DPAD_LEFT, KEYCODE_DPAD_RIGHT, और KEYCODE_DPAD_CENTER (सभी मौजूद होने चाहिए) पर मैप की गई है, तो डिवाइस को डायरेक्शनल कीपैड माना जाता है. डायरेक्शनल कीपैड की सुविधा को संसाधन Configuration ऑब्जेक्ट में NAVIGATION_DPAD के तौर पर रिपोर्ट किया जाता है.

• अगर इनपुट डिवाइस में कोई ऐसी बटन है जो KEYCODE_BUTTON_A या गेमपैड से जुड़ी अन्य बटन पर मैप की गई है, तो डिवाइस में गेमपैड मौजूद माना जाता है.

कीबोर्ड ड्राइवर से जुड़ी ज़रूरी शर्तें

1. कीबोर्ड ड्राइवर को सिर्फ़ उन बटन के लिए बटन कोड रजिस्टर करने चाहिए जिन पर वे काम करते हैं. ज़रूरत से ज़्यादा की-कोड रजिस्टर करने से, डिवाइस के कैटगरी तय करने वाले एल्गोरिद्म को भ्रम हो सकता है. इसके अलावा, इससे सिस्टम को डिवाइस के कीबोर्ड की सुविधाओं का गलत पता चल सकता है.

2. कीबोर्ड ड्राइवर को बटन दबाने की जानकारी देने के लिए, EV_KEY का इस्तेमाल करना चाहिए. किसी बटन को छोड़ने के लिए 0 की वैल्यू, बटन दबाने के लिए 1 की वैल्यू, और बटन अपने-आप दबने के लिए 2 से ज़्यादा या उसके बराबर की वैल्यू का इस्तेमाल करें.

3. Android, कीबोर्ड के बटन को बार-बार दबाने की सुविधा अपने-आप चालू करता है. ड्राइवर में, ऑटो-रिपीट की सुविधा बंद होनी चाहिए.

4. कीबोर्ड ड्राइवर, MSC_SCANCODE के साथ EV_MSC भेजकर, एचआईडी के इस्तेमाल या कम-लेवल स्कैन कोड के बारे में बता सकते हैं. साथ ही, बटन दबाने पर, इस्तेमाल या स्कैन कोड की जानकारी देने वाली वैल्यू भी भेज सकते हैं. फ़िलहाल, Android इस जानकारी का इस्तेमाल नहीं करता.

5. डिवाइस में EV_LED लिखे जाने पर, कीबोर्ड ड्राइवर को एलईडी की स्थितियां सेट करने की सुविधा होनी चाहिए. hid-input ड्राइवर इसे अपने-आप मैनेज करता है. इस लेख को लिखने के समय, Android LED_CAPSLOCK, LED_SCROLLLOCK, और LED_NUMLOCK का इस्तेमाल करता है. इन एलईडी का इस्तेमाल सिर्फ़ तब किया जाना चाहिए, जब कीबोर्ड में इनसे जुड़ी इंडिकेटर लाइटें हों.

6. एम्बेड किए गए कीपैड (उदाहरण के लिए, जीपीआईओ मैट्रिक्स का इस्तेमाल करने वाले) के लिए कीबोर्ड ड्राइवर को यह पक्का करना चाहिए कि डिवाइस के स्लीप मोड में जाने के बाद भी दबाई गई किसी भी बटन के लिए, 0 की वैल्यू के साथ EV_KEY इवेंट भेजे जाएं. ऐसा न करने पर, हो सकता है कि बटन दबाए रहें और वे अपने-आप बार-बार दबते रहें.

कीबोर्ड से काम करना

यहां Android पर कीबोर्ड के काम करने के तरीके के बारे में खास जानकारी दी गई है.

1. EventHub, evdev ड्राइवर से रॉ इवेंट पढ़ता है और कीबोर्ड के बटन के लेआउट मैप का इस्तेमाल करके, Linux बटन कोड (जिन्हें कभी-कभी स्कैन कोड भी कहा जाता है) को Android बटन कोड में मैप करता है.

2. InputReader, रॉ इवेंट का इस्तेमाल करता है और मेटा बटन की स्थिति को अपडेट करता है. उदाहरण के लिए, अगर बाईं ओर मौजूद शिफ़्ट बटन को दबाया या छोड़ा जाता है, तो रीडर META_SHIFT_LEFT_ON और META_SHIFT_ON बिट को उसी के हिसाब से सेट या रीसेट कर देगा.

3. InputReader, मुख्य इवेंट के बारे में InputDispatcher को सूचना देता है.

4. InputDispatcher, WindowManagerPolicy से पूछता है कि WindowManagerPolicy.interceptKeyBeforeQueueing को कॉल करके, मुख्य इवेंट के साथ क्या करना है. यह तरीका, एक अहम पाथ का हिस्सा है. यह कुछ बटन दबाने पर, डिवाइस को चालू करने के लिए ज़िम्मेदार होता है. EventHub इस अहम पाथ के साथ, वॉकी लॉक को असरदार तरीके से बनाए रखता है, ताकि यह पूरी तरह से चल सके.

5. अगर कोई InputFilter फ़िलहाल इस्तेमाल में है, तो InputDispatcher उसे पासकोड इस्तेमाल करने या बदलने का मौका देता है. InputFilter का इस्तेमाल, पूरे सिस्टम के लिए कम-लेवल की सुलभता नीतियों को लागू करने के लिए किया जा सकता है.

6. InputDispatcher, डिस्पैच थ्रेड पर प्रोसेसिंग के लिए पासकोड को सूची में जोड़ता है.

7. जब InputDispatcher, बटन को डिसक्यू से हटाता है, तो वह WindowManagerPolicy को WindowManagerPolicy.interceptKeyBeforeDispatching को कॉल करके, मुख्य इवेंट को इंटरसेप्ट करने का दूसरा मौका देता है. यह तरीका, सिस्टम के शॉर्टकट और अन्य फ़ंक्शन को मैनेज करता है.

8. इसके बाद, InputDispatcher मुख्य इवेंट टारगेट (फ़ोकस की गई विंडो) की पहचान करता है और उसके तैयार होने का इंतज़ार करता है. इसके बाद, InputDispatcher ऐप्लिकेशन को मुख्य इवेंट डिलीवर करता है.

9. ऐप्लिकेशन में, मुख्य इवेंट व्यू की हैरारकी में नीचे की ओर, IME से पहले की जाने वाली बटन दबाने की कार्रवाई के लिए फ़ोकस किए गए व्यू तक भेजा जाता है.

10. अगर मुख्य इवेंट को IME डिस्पैच से पहले मैनेज नहीं किया जाता है और कोई IME इस्तेमाल में है, तो मुख्य इवेंट को IME पर डिलीवर किया जाता है.

11. अगर मुख्य इवेंट को IME ने इस्तेमाल नहीं किया है, तो मुख्य इवेंट, स्टैंडर्ड बटन डिस्पैच के लिए, व्यू की हैरारकी में सबसे नीचे मौजूद फ़ोकस किए गए व्यू तक पहुंच जाता है.

12. ऐप्लिकेशन, InputDispatcher को यह रिपोर्ट करता है कि मुख्य इवेंट का इस्तेमाल किया गया था या नहीं. अगर इवेंट का इस्तेमाल नहीं किया गया था, तो InputDispatcher "फ़ॉलबैक" व्यवहार लागू करने के लिए WindowManagerPolicy.dispatchUnhandledKey को कॉल करता है. फ़ॉलबैक ऐक्शन के आधार पर, किसी दूसरे मुख्य कोड का इस्तेमाल करके मुख्य इवेंट डिस्पैच साइकल को फिर से शुरू किया जा सकता है. उदाहरण के लिए, अगर कोई ऐप्लिकेशन KEYCODE_ESCAPE को हैंडल नहीं करता है, तो सिस्टम मुख्य इवेंट को KEYCODE_BACK के तौर पर फिर से डिस्पैच कर सकता है.

कीबोर्ड कॉन्फ़िगरेशन

कीबोर्ड के व्यवहार को कीबोर्ड के बटन लेआउट, बटन के वर्ण मैप, और इनपुट डिवाइस के कॉन्फ़िगरेशन से तय किया जाता है.

कीबोर्ड कॉन्फ़िगरेशन में हिस्सा लेने वाली फ़ाइलों के बारे में ज़्यादा जानकारी के लिए, यहां दिए गए सेक्शन देखें:

• मुख्य लेआउट फ़ाइलें
• मुख्य कैरेक्टर मैप फ़ाइलें
• डिवाइस की कॉन्फ़िगरेशन फ़ाइलें डालना

प्रॉपर्टी

इनपुट डिवाइस के कॉन्फ़िगरेशन की इन प्रॉपर्टी का इस्तेमाल, कीबोर्ड के लिए किया जाता है.

keyboard.layout

परिभाषा: keyboard.layout = <name>

इनपुट डिवाइस से जुड़ी कुंजी लेआउट फ़ाइल का नाम बताता है. इसमें .kl एक्सटेंशन शामिल नहीं है. अगर यह फ़ाइल नहीं मिलती है, तो इनपुट सिस्टम डिफ़ॉल्ट कीबोर्ड लेआउट का इस्तेमाल करेगा.

लुकअप के दौरान, नाम में मौजूद स्पेस को अंडरस्कोर में बदल दिया जाता है.

ज़्यादा जानकारी के लिए, मुख्य लेआउट फ़ाइल का दस्तावेज़ देखें.

keyboard.characterMap

परिभाषा: keyboard.characterMap = <name>

इनपुट डिवाइस से जुड़ी मुख्य वर्ण मैप फ़ाइल का नाम बताता है. इसमें .kcm एक्सटेंशन शामिल नहीं होता. अगर यह फ़ाइल नहीं मिलती है, तो इनपुट सिस्टम डिफ़ॉल्ट की कैरेक्टर मैप का इस्तेमाल करेगा.

लुकअप के दौरान, नाम में मौजूद स्पेस को अंडरस्कोर में बदल दिया जाता है.

ज़्यादा जानकारी के लिए, मुख्य कैरेक्टर मैप फ़ाइल के दस्तावेज़ देखें.

keyboard.orientationAware

परिभाषा: keyboard.orientationAware = 0 | 1

इससे यह तय होता है कि डिसप्ले के ओरिएंटेशन में बदलाव होने पर, कीबोर्ड को कैसे काम करना चाहिए.

• अगर वैल्यू 1 है, तो डिसप्ले के ओरिएंटेशन में बदलाव होने पर, डायरेक्शनल कीपैड की घुमाई जाती हैं.

• अगर वैल्यू 0 है, तो कीबोर्ड के डिसप्ले ओरिएंटेशन में बदलाव नहीं होता.

डिफ़ॉल्ट वैल्यू 0 है.

ऑरिएंटेशन से जुड़ी जानकारी का इस्तेमाल, डायरेक्शनल कीपैड बटन के रोटेशन के लिए किया जाता है. जैसे, Motorola Droid पर. उदाहरण के लिए, जब डिवाइस को उसके सामान्य ओरिएंटेशन से, घड़ी की सुई के उलट 90 डिग्री घुमाया जाता है, तो KEYCODE_DPAD_UP को KEYCODE_DPAD_RIGHT में बदल दिया जाता है. ऐसा इसलिए होता है, क्योंकि डिवाइस को उस ओरिएंटेशन में रखने पर, 'अप' बटन 'राइट' बटन की ओर इशारा करता है.

keyboard.builtIn

परिभाषा: keyboard.builtIn = 0 | 1

इससे पता चलता है कि कीबोर्ड, डिवाइस में पहले से मौजूद (फ़िज़िकली अटैच किया गया) कीबोर्ड है या नहीं.

अगर डिवाइस का नाम -keypad पर खत्म होता है, तो डिफ़ॉल्ट वैल्यू 1 होती है. अगर डिवाइस का नाम -keypad पर खत्म नहीं होता है, तो डिफ़ॉल्ट वैल्यू 0 होती है.

बिल्ट-इन कीबोर्ड को हमेशा 0 का डिवाइस आईडी असाइन किया जाता है. डिवाइस में पहले से मौजूद कीबोर्ड के अलावा, अन्य कीबोर्ड को यूनीक डिवाइस आईडी असाइन किए जाते हैं.

डिवाइस में पहले से मौजूद कीबोर्ड के लिए 0 का आईडी इस्तेमाल करना ज़रूरी है, ताकि KeyCharacterMap.BUILT_IN_KEYBOARD फ़ील्ड के साथ काम करना जारी रखा जा सके. इस फ़ील्ड में, डिवाइस में पहले से मौजूद कीबोर्ड का आईडी और 0 की वैल्यू दी जाती है. एपीआई में इस फ़ील्ड का इस्तेमाल बंद कर दिया गया है. हालांकि, हो सकता है कि पुराने ऐप्लिकेशन अब भी इसका इस्तेमाल कर रहे हों.

खास फ़ंक्शन वाला कीबोर्ड (जिसकी मुख्य वर्ण मैप में SPECIAL_FUNCTION का टाइप बताया गया हो) कभी भी डिफ़ॉल्ट कीबोर्ड के तौर पर रजिस्टर नहीं किया जाएगा. भले ही, इस प्रॉपर्टी की सेटिंग कुछ भी हो. ऐसा इसलिए है, क्योंकि खास फ़ंक्शन वाले कीबोर्ड का इस्तेमाल, आम तौर पर टाइपिंग के लिए नहीं किया जाता.

कॉन्फ़िगरेशन के उदाहरण

# This is an example input device configuration file for a built-in
# keyboard that has a DPad.

# The keyboard is internal because it is part of the device.
device.internal = 1

# The keyboard is the default built-in keyboard so it should be assigned
# an id of 0.
keyboard.builtIn = 1

# The keyboard includes a DPad which is mounted on the device.  As the device
# is rotated the orientation of the DPad rotates along with it, so the DPad must
# be aware of the display orientation.  This ensures that pressing 'up' on the
# DPad always means 'up' from the perspective of the user, even when the entire
# device has been rotated.
keyboard.orientationAware = 1

कंपैटिबिलिटी के बारे में अहम जानकारी

Honeycomb से पहले, कीबोर्ड इनपुट मैपर किसी भी कॉन्फ़िगरेशन प्रॉपर्टी का इस्तेमाल नहीं करता था. यह माना जाता था कि सभी कीबोर्ड, डिवाइस से फ़िज़िकली कनेक्ट होते हैं और उनके ओरिएंटेशन की जानकारी होती है. डिफ़ॉल्ट कीबोर्ड लेआउट और कीबोर्ड वर्ण मैप का नाम Generic के बजाय qwerty था. बटन के वर्ण मैप का फ़ॉर्मैट भी बहुत अलग था. साथ ही, फ़्रेमवर्क में पीसी स्टाइल के फ़ुल कीबोर्ड या बाहरी कीबोर्ड काम नहीं करते थे.

डिवाइसों को Honeycomb पर अपग्रेड करते समय, ज़रूरी कॉन्फ़िगरेशन और मुख्य मैप फ़ाइलें बनाना या अपडेट करना न भूलें.

एचआईडी के इस्तेमाल, Linux के कुंजी कोड, और Android के कुंजी कोड

सिस्टम, कई अलग-अलग आइडेंटिफ़ायर का इस्तेमाल करके, कुंजियों को रेफ़र करता है. यह इस बात पर निर्भर करता है कि एब्स्ट्रैक्शन की लेयर क्या है.

एचआईडी डिवाइसों के लिए, हर बटन से जुड़ा एचआईडी इस्तेमाल होता है. एचआईडी रिपोर्ट को पार्स करने और एचआईडी के इस्तेमाल को Linux के बटन कोड से मैप करने की ज़िम्मेदारी, Linux hid-input ड्राइवर और उससे जुड़े वेंडर और डिवाइस के हिसाब से एचआईडी ड्राइवर की होती है.

Android, Linux kernel से EV_KEY इवेंट पढ़ता है. साथ ही, डिवाइस की की लेआउट फ़ाइल के हिसाब से, हर Linux की कोड को उसके Android की कोड में बदल देता है.

जब मुख्य इवेंट किसी ऐप्लिकेशन को भेजा जाता है, तो android.view.KeyEvent इंस्टेंस, Linux कुंजी कोड को getScanCode() की वैल्यू के तौर पर और Android कुंजी कोड को getKeyCode() की वैल्यू के तौर पर रिपोर्ट करता है. फ़्रेमवर्क के मकसद के लिए, सिर्फ़ getKeyCode() की वैल्यू अहम है.

ध्यान दें कि Android खुद, HID के इस्तेमाल की जानकारी का इस्तेमाल नहीं करता या ऐप्लिकेशन को नहीं भेजता.

कोड टेबल

यहां दी गई टेबल से पता चलता है कि एचआईडी के इस्तेमाल, Linux के बटन कोड, और Android के बटन कोड एक-दूसरे से कैसे जुड़े हैं.

LKC कॉलम में, हैक्साडेसिमल में Linux पासकोड दिया गया है.

AKC कॉलम में, Android की कोड को हेक्साडेसिमल में दिखाया जाता है.

नोट कॉलम में, टेबल के बाद पोस्ट किए गए नोट दिखते हैं.

वर्शन कॉलम से पता चलता है कि Android प्लैटफ़ॉर्म के किस पहले वर्शन में, डिफ़ॉल्ट पासकोड मैप में यह पासकोड शामिल किया गया था. एक से ज़्यादा पंक्तियां तब दिखती हैं, जब वर्शन के बीच डिफ़ॉल्ट कीमैप बदल गया हो. सबसे पुराना वर्शन 1.6 है.

• Gingerbread (2.3) और उससे पहले की रिलीज़ में, डिफ़ॉल्ट की मैप qwerty.kl था. इस की मैप का मकसद सिर्फ़ Android एमुलेटर के साथ इस्तेमाल करना था. इसका मकसद, किसी भी तरह के बाहरी कीबोर्ड के साथ इस्तेमाल करना नहीं था. इसके बावजूद, कुछ OEM ने प्लैटफ़ॉर्म में ब्लूटूथ कीबोर्ड की सुविधा जोड़ी है. साथ ही, ज़रूरी कीबोर्ड मैपिंग देने के लिए qwerty.kl पर भरोसा किया है. इसलिए, इन पुरानी मैपिंग में दिलचस्पी उन OEM की हो सकती है जो इन डिवाइसों के लिए डिवाइसों से जुड़े उपकरण बना रहे हैं. ध्यान दें कि मैपिंग, मौजूदा मैपिंग से काफ़ी अलग हैं. खास तौर पर, HOME बटन के इस्तेमाल के मामले में. हमारा सुझाव है कि सभी नए डिवाइसों को, Honeycomb या हाल ही के की मैप (जैसे, स्टैंडर्ड HID) के हिसाब से डिज़ाइन किया जाए.

• Honeycomb (3.0) के बाद, डिफ़ॉल्ट की मैप Generic.kl है. इस की मैप को, पीसी स्टाइल के कीबोर्ड के साथ इस्तेमाल करने के लिए डिज़ाइन किया गया था. स्टैंडर्ड HID कीबोर्ड के ज़्यादातर फ़ंक्शन, बिना किसी सेटअप के काम करने चाहिए.

Linux kernel और Android के अलग-अलग वर्शन के लिए, की कोड मैपिंग अलग-अलग हो सकती है. जब Android के डिफ़ॉल्ट की मैप में बदलाव होते हैं, तो उनका पता वर्शन कॉलम में चलता है.

डिवाइस के हिसाब से HID ड्राइवर और बटन मैप, यहां बताई गई मैपिंग से अलग मैपिंग लागू कर सकते हैं.

एचआईडी कीबोर्ड और कीपैड पेज (0x07)

एचआईडी का सामान्य डेस्कटॉप पेज (0x01)

एचआईडी उपभोक्ता पेज (0x0c)

अतिरिक्त नॉन-एचआईडी मैपिंग

इन मैपिंग में उन फ़ंक्शन के बारे में बताया गया है जो एचआईडी में नहीं दिखते, लेकिन जिनके लिए Linux के बटन कोड मौजूद हैं.

काम न करने वाली लेगसी कुंजियां

ये मैपिंग, Android के पिछले वर्शन में दिखती थीं, लेकिन ये एचआईडी के साथ काम नहीं करती थीं या इनमें स्टैंडर्ड लिनक्स बटन कोड का इस्तेमाल नहीं किया जाता था. ये अब काम नहीं करते.

अहम जानकारी

1. कीबोर्ड के लेआउट और भाषा के आधार पर, अक्षर और अंकों वाली सामान्य और सिंबल वाली की के लिए Android की कोड अलग-अलग हो सकते हैं. पुरानी वजहों से, कीबोर्ड पर बटनों से जुड़े फ़िज़िकल स्कैन कोड और एचआईडी के इस्तेमाल को अक्सर उनकी जगह के हिसाब से तय किया जाता है. भले ही, उन बटनों पर प्रिंट किए गए लेबल एक भाषा से दूसरी भाषा में अलग-अलग हो सकते हैं.

   अमेरिकन इंग्लिश (QWERTY) कीबोर्ड पर, सबसे ऊपर बाईं ओर मौजूद अक्षर वाली बटन पर Q लेबल होता है. फ़्रेंच (AZERTY) कीबोर्ड पर, उसी जगह पर मौजूद बटन को A लेबल किया गया है. लेबल के बावजूद, दोनों कीबोर्ड पर सबसे ऊपर बाईं ओर मौजूद अक्षर वाली बटन को, एचआईडी इस्तेमाल 0x07 0x0014 का इस्तेमाल करके रेफ़र किया जाता है. इसे Linux कीबोर्ड कोड KEY_Q पर मैप किया गया है.

   जब Android को अमेरिकन इंग्लिश कीबोर्ड लेआउट के साथ कॉन्फ़िगर किया जाता है, तो Linux कीबोर्ड कोड KEY_Q को Android कीबोर्ड कोड KEYCODE_Q पर मैप किया जाएगा. साथ ही, 'Q' और 'q' वर्ण जनरेट होंगे. हालांकि, जब Android को फ़्रेंच कीबोर्ड लेआउट के साथ कॉन्फ़िगर किया जाता है, तो Linux कीबोर्ड कोड KEY_Q को Android कीबोर्ड कोड KEYCODE_A पर मैप किया जाएगा. साथ ही, 'A' और 'a' वर्ण जनरेट होंगे.

   आम तौर पर, Android कीवर्ड कोड में, भाषा के हिसाब से कीवर्ड का मतलब दिखता है. इसलिए, अलग-अलग भाषाओं के लिए, Android कीवर्ड कोड का इस्तेमाल किया जा सकता है.

2. 0x0c 0x022f AC Zoom को एचआईडी में लीनियर कंट्रोल के तौर पर परिभाषित किया गया है, लेकिन कर्नेल इसे बटन के तौर पर मैप करता है, जो शायद गलत है.

3. Linux फ़ंक्शन बटन KEY_FN_* को आसान की कोड पर मैप किया जाता है, लेकिन इन्हें META_FUNCTION मेटा स्टेटस बिट के 'सही है' पर सेट होने के साथ डिस्पैच किया जाता है.

4. Android Ice Cream Sandwich 4.0 से पहले, डिफ़ॉल्ट की लेआउट में कुछ अतिरिक्त की कोड के लिए मैपिंग शामिल थीं. ये कोड, मुख्य Linux kernel हेडर में तय नहीं किए गए थे. इन मैपिंग को तब से हटा दिया गया है, क्योंकि पहले से तय नहीं किए गए इन कुंजी कोड को, Linux kernel के नए वर्शन में अलग-अलग मतलब असाइन किए गए हैं.

सोर्स

1. यूएसबी एचआईडी के इस्तेमाल से जुड़ी टेबल का वर्शन 1.12
2. Linux 2.6.39 kernel: include/linux/input.h, drivers/hid/hid-input.c
3. Android ICS: qwerty.kl, Generic.kl, KeyEvent.java