Android सीपीयू आर्किटेक्चर (ABI) को समझना: क्यों arm64-v8a, armeabi-v7a, और एक्स86 मायने रखते हैं

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

ABI क्या है

ABI का मतलब एप्लीकेशन बाइनरी इंटरफ़ेस है। व्यावहारिक रूप से, यह निर्देश सेट है जिसे एक चिप समझती है - कच्चे मशीन कोड प्रारूप को एक प्रोसेसर सीधे निष्पादित कर सकता है। अधिकांश Android ऐप, जावा या कोटलिन में लिखे गए हिस्से, Android रनटाइम (एआरटी) के अंदर चलने वाले बाइटकोड में संकलित हो जाते हैं, और एआरटी को विशेष रूप से परवाह नहीं होती है कि यह किस चिप पर बैठा है। वह परत डिज़ाइन द्वारा वास्तुकला-अज्ञेयवादी है, जो इस बात का एक बड़ा हिस्सा है कि Android ऐप्स आमतौर पर हार्डवेयर की इतनी विस्तृत श्रृंखला में "बस काम" क्यों करते हैं।

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

आप जिन आर्किटेक्चर में भाग लेंगे

इस स्थान में अधिक विविधता हुआ करती थी (सादा armeabi, या MIPS याद रखें?), लेकिन 2026 तक यह क्षेत्र चार ABI तक सीमित हो गया है जो जानने लायक हैं:

यदि आपके पास पिछले पांच या छह वर्षों में कभी भी खरीदा गया फोन है, तो यह लगभग निश्चित रूप से arm64-v8a है। याद रखने योग्य अपवाद एमुलेटर और क्रोमबुक हैं, जो अक्सर x86_64 पर चलते हैं, क्योंकि यह अंतर्निहित लैपटॉप या डेस्कटॉप सीपीयू से मेल खाता है।

आखिर ऐप्स एकाधिक बिल्ड की शिपिंग में परेशानी क्यों लाते हैं?

एक स्पष्ट प्रश्न यह है कि डेवलपर्स प्रत्येक आर्किटेक्चर की मूल लाइब्रेरी को एक ही APK में क्यों नहीं भर देते हैं और उससे काम क्यों नहीं चलाते हैं। कुछ ऐप्स बिल्कुल ऐसा ही करते हैं, और इसे यूनिवर्सल या "फ़ैट" APK कहा जाता है। नकारात्मक पक्ष आकार है. Arm64-v8a, Armeabi-v7a, x86, और x86_64 के लिए मूल पुस्तकालयों के साथ एक गेम जो सभी को एक साथ बंडल किया गया है, आपके डिवाइस के लिए आवश्यक केवल एक आर्किटेक्चर वाले बिल्ड की तुलना में आकार में आसानी से दोगुना या तिगुना हो सकता है। इसे लाखों इंस्टॉल में गुणा करें और आप उस कोड के लिए बर्बाद बैंडविड्थ और स्टोरेज की वास्तव में महत्वपूर्ण मात्रा देख रहे हैं जो उस डिवाइस पर कभी नहीं चलेगा।

उस बर्बादी से बचने के लिए, Google Play और Android ऐप बंडल प्रारूप ने एक ऐप को एक छोटे बेस APK और कॉन्फ़िगरेशन APK की एक श्रृंखला में विभाजित किया है, जिनमें से एक आर्किटेक्चर के लिए समर्पित है। जब आपका फ़ोन ऐप के लिए अनुरोध करता है, तो Play Store बेस APK को केवल आर्किटेक्चर स्प्लिट के साथ वितरित करता है जो आपके चिप से मेल खाता है, साथ ही स्क्रीन-घनत्व और भाषा विभाजन से मेल खाता है। आप एक ऐसे इंस्टॉल के साथ समाप्त होते हैं जो एक एकल ऐप की तरह व्यवहार करता है लेकिन पर्दे के पीछे कई उद्देश्य-निर्मित टुकड़ों से इकट्ठा किया जाता है।

स्प्लिट APK और ऐप बंडल इसका उपयोग कैसे करते हैं

यदि आपने कभी .apks या .xapk पैकेज खोला है और base.apk के बगल में split_config.arm64_v8a.apk, split_config.armeabi_v7a.apk, split_config.xxhdpi.apk, और split_config.en.apk जैसे फ़ाइल नाम देखे हैं, तो वास्तव में यह सिस्टम क्रियाशील है, प्ले स्टोर द्वारा चुपचाप वितरित किए जाने के बजाय फ़ाइलों के एक सेट के रूप में निर्यात किया जाता है। घनत्व और भाषा विभाजन आमतौर पर अंधाधुंध रूप से स्थापित करना सुरक्षित होता है क्योंकि एक फ़ोन उन संसाधनों को अनदेखा कर देगा जिनकी उसे आवश्यकता नहीं है। आर्किटेक्चर विभाजन अलग है: गलत इंस्टॉल करें, या मेल खाने वाला इंस्टॉल करने में विफल रहें, और आप वास्तविक परेशानी में पड़ जाएंगे।

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

क्या होता है जब वास्तुकला मेल नहीं खाती

अलग-अलग जानने लायक दो अलग-अलग विफलता मोड हैं, क्योंकि वे एक नियमित उपयोगकर्ता के लिए अलग दिखते और महसूस करते हैं।

पहला पूर्णतः इंस्टॉल विफलता है. यदि कोई ऐप लगभग पूरी तरह से मूल कोड के आसपास बिना किसी सार्थक फ़ॉलबैक के बनाया गया है, तो Android का पैकेज मैनेजर इसे इंस्टॉल करने से इंकार कर देगा, आमतौर पर INSTALL_FAILED_NO_MATCHING_ABIS जैसी त्रुटि सामने आएगी। आपको कभी भी ऐप खोलने का मौका नहीं मिलेगा; इंस्टॉलर आपको दरवाजे पर रोक देता है।

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

अपने फ़ोन का आर्किटेक्चर कैसे जांचें

अधिकांश लोगों के लिए यह सरल है: यदि आपका फ़ोन 2019 या उसके बाद का है, तो Arm64-v8a मान लें और आगे बढ़ें। यदि आप निश्चित होना चाहते हैं, या आप किसी पुराने या असामान्य उपकरण के साथ काम कर रहे हैं, तो कुछ व्यावहारिक विकल्प:

• अपने फ़ोन का सटीक चिपसेट मॉडल देखें (बॉक्स पर, मैनुअल में, या GSMArena जैसी साइट पर दिखाई दे) और खोजें कि क्या वह चिपसेट 32-बिट या 64-बिट ARM है।
• एक हल्का सिस्टम-सूचना ऐप इंस्टॉल करें जो सीधे सीपीयू आर्किटेक्चर की रिपोर्ट करता है, विशेष रूप से इस उद्देश्य के लिए कई निःशुल्क ऐप मौजूद हैं।
• जांचें कि क्या फ़ोन Android 9 या उसके बाद के संस्करण के साथ मूल ओएस संस्करण के रूप में भेजा गया है; उस युग के आसपास Google की 64-बिट आवश्यकताएं arm64-v8a को किसी भी योग्य चीज़ पर अनिवार्य रूप से गारंटी देती हैं।

कैसे जांचें कि APK किस आर्किटेक्चर का समर्थन करता है

Play Store के बाहर से किसी फ़ाइल को इंस्टॉल करने से पहले, अनुमान लगाने के बजाय यह पुष्टि करना उचित है कि उसके अंदर क्या है। APK की मूल लाइब्रेरी lib/ निर्देशिका के अंदर उनके आर्किटेक्चर के नाम पर फ़ोल्डर्स में रहती हैं, जैसे lib/arm64-v8a/ या lib/armeabi-v7a/। कोई भी उपकरण जो APK की आंतरिक संरचना का निरीक्षण कर सकता है वह आपको बता सकता है कि इनमें से कौन सा फ़ोल्डर मौजूद है, जो आपको बताता है कि फ़ाइल किन उपकरणों पर चलेगी।

यूनिवर्सल APK बनाम सिंगल-ABI APK: आपको किसका उपयोग करना चाहिए?

स्प्लिट पैकेज के साथ लोग सामान्य गलतियाँ करते हैं

• यह मानते हुए कि प्रत्येक विभाजन वैकल्पिक है। घनत्व और भाषा विभाजन आमतौर पर होते हैं, लेकिन वास्तुकला विभाजन नहीं होता है; मर्ज के दौरान इसे कभी न छोड़ें।
• दर्पण स्थल से विभाजित केवल एक वास्तुकला को पकड़ना। यदि कोई तृतीय-पक्ष डाउनलोड केवल प्रदान करता है, उदाहरण के लिए, Armeabi-v7a स्लाइस, तो यह आसानी से उस डिवाइस पर विफल हो सकता है जिसके लिए Arm64-v8a की आवश्यकता होती है, भले ही ऐप स्वयं वैध हो।
• यह भूल जाना कि टैबलेट और Chromebook हमेशा ARM नहीं होते हैं। Android ऐप चलाने वाले बहुत सारे Chromebook और कुछ पुराने टैबलेट ARM के बजाय x86 या x86_64 हैं।
• x86 एमुलेटर के अंदर केवल एआरएम APK का परीक्षण करना। कुछ पुराने एमुलेटर बिल्ड x86 पर चलते हैं, और एक APK जो केवल एआरएम देशी पुस्तकालयों को शिप करता है, उनके अंदर लॉन्च नहीं होगा, भले ही APK को कैसे पैक किया गया हो।
• "सार्वभौमिक" को "एकल-ABI" के साथ भ्रमित करना। एक सार्वभौमिक APK जानबूझकर बड़ा है क्योंकि इसमें सब कुछ शामिल है; एकल-ABI APK छोटा है और जानबूझकर एक चिप परिवार तक सीमित है।

अक्सर पूछे जाने वाले प्रश्न (FAQ)

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