Android ऐप इंस्टॉलेशन हुड के तहत कैसे काम करता है

A smartphone on engineering blueprints with gears, illustrating how app installation works

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

इस लेख में, हम Android इंस्टॉलेशन पाइपलाइन के हर प्रमुख चरण के बारे में जानेंगे, जिस क्षण से सिस्टम को APK प्राप्त होता है उस बिंदु तक जहां ऐप लॉन्च होने के लिए तैयार है।

चरण 1: इंस्टालेशन आरंभ करना

स्रोत के आधार पर स्थापना प्रक्रिया अलग-अलग तरीके से शुरू होती है:

  • खेल स्टोर: प्ले स्टोर ऐप APK (या स्प्लिट APK) डाउनलोड करता है और सिस्टम के पैकेज इंस्टॉलर को विशेष विशेषाधिकारों के साथ कॉल करता है जो कुछ उपयोगकर्ता पुष्टिकरणों को बायपास करता है।
  • साइड लोड किया जाना: जब आप एक APK फ़ाइल खोलते हैं, तो Android पैकेज इंस्टॉलर गतिविधि लॉन्च करता है। Android 8.0 और उसके बाद के संस्करण पर, इंस्टॉल करने वाले ऐप के पास अपने विशिष्ट स्रोत के लिए "अज्ञात ऐप्स इंस्टॉल करें" अनुमति होनी चाहिए।
  • ADB: adb install कमांड ग्राफिकल इंस्टॉलर को पूरी तरह से दरकिनार करते हुए USB पर पैकेज मैनेजर सेवा के साथ सीधे संचार करता है।

स्रोत चाहे जो भी हो, सभी इंस्टॉलेशन अंततः एक ही सिस्टम सेवा तक पहुंचते हैं: पैकेज प्रबंधक सेवा (PMS)। यह Android पर सभी पैकेज संचालन के लिए केंद्रीय प्राधिकरण है।

चरण 2: पैकेज पार्सिंग

किसी भी अन्य चीज़ से पहले, सिस्टम को यह समझने की आवश्यकता है कि वह क्या स्थापित करने वाला है। पैकेजमैनेजरसर्विस APK फ़ाइल को पढ़ने और उसका मेटाडेटा निकालने के लिए पैकेज पार्सर को आमंत्रित करता है।

पार्सर APK के भीतर से AndroidManifest.xml फ़ाइल को पढ़ता है। इस बाइनरी XML फ़ाइल में महत्वपूर्ण जानकारी है:

  • पैकेज का नाम: ऐप के लिए विशिष्ट पहचानकर्ता (जैसे, com.example.myapp)
  • संस्करण कोड और नाम: यह निर्धारित करने के लिए उपयोग किया जाता है कि यह अपग्रेड है या ताज़ा इंस्टॉल है
  • न्यूनतम और लक्ष्य SDK संस्करण: डिवाइस के साथ अनुकूलता निर्धारित करता है
  • घोषित अनुमतियाँ: ऐप अनुरोधित अनुमतियाँ और उसके द्वारा परिभाषित कस्टम अनुमतियाँ दोनों
  • अवयव: गतिविधियाँ, सेवाएँ, प्रसारण रिसीवर और सामग्री प्रदाता ऐप पंजीकृत करता है
  • हार्डवेयर और सॉफ्टवेयर विशेषताएं: आवश्यकताएँ जैसे कैमरा, जीपीएस, या विशिष्ट ओपनजीएल संस्करण

यदि मेनिफेस्ट विकृत है या APK संरचना अमान्य है, तो इंस्टॉलेशन "पार्स त्रुटि" संदेश के साथ इस चरण में विफल हो जाता है। यह सबसे आम कारणों में से एक है कि साइडलोडेड APK इंस्टॉल नहीं हो पाते हैं।

चरण 3: संगतता जाँच

एक बार मैनिफ़ेस्ट पार्स हो जाने के बाद, सिस्टम संगतता जाँचों की एक श्रृंखला निष्पादित करता है:

  • SDK संस्करण: यदि ऐप का minSdkVersion डिवाइस के एपीआई स्तर से अधिक है, तो इंस्टॉलेशन अस्वीकार कर दिया गया है।
  • ABI अनुकूलता: यदि APK में मूल लाइब्रेरी शामिल हैं, तो सिस्टम जांचता है कि क्या वे डिवाइस के सीपीयू आर्किटेक्चर से मेल खाते हैं। केवल armeabi-v7a लाइब्रेरी वाला APK केवल x86 डिवाइस पर इंस्टॉल नहीं होगा।
  • आवश्यक विशेषताएं: यदि ऐप आवश्यक हार्डवेयर सुविधाओं (जैसे android.hardware.telephony) की घोषणा करता है, तो सिस्टम सत्यापित करता है कि डिवाइस उनका समर्थन करता है।
  • उपलब्ध भंडार: सिस्टम जांच करता है कि ऐप इंस्टॉल करने के लिए पर्याप्त खाली जगह है या नहीं, जिसमें निकाली गई मूल लाइब्रेरी और अनुकूलित DEX फ़ाइलों के लिए जगह शामिल है।

चरण 4: हस्ताक्षर सत्यापन

यह इंस्टॉलेशन प्रक्रिया में सबसे महत्वपूर्ण चरणों में से एक है। Android APK की अखंडता और प्रामाणिकता सुनिश्चित करने के लिए उसके क्रिप्टोग्राफ़िक हस्ताक्षर का सत्यापन करता है।

सत्यापन प्रक्रिया इस बात पर निर्भर करती है कि कौन सी हस्ताक्षर योजनाएं मौजूद हैं:

V1 हस्ताक्षर (JAR हस्ताक्षर)

सिस्टम हस्ताक्षर फ़ाइलों (.SF, .RSA या .DSA के लिए META-INF/ निर्देशिका की जाँच करता है)। APK में प्रत्येक फ़ाइल को मेनिफेस्ट में सूचीबद्ध डाइजेस्ट के विरुद्ध सत्यापित किया जाता है। यह धीमा है क्योंकि प्रत्येक फ़ाइल को व्यक्तिगत रूप से हैश किया जाना चाहिए।

V2 हस्ताक्षर (APK हस्ताक्षर योजना v2)

Android 7.0 में पेश की गई, यह योजना संपूर्ण APK को बाइनरी ब्लॉब के रूप में चिह्नित करती है। हस्ताक्षर ब्लॉक को ज़िप केंद्रीय निर्देशिका और केंद्रीय-निर्देशिका रिकॉर्ड के अंत के बीच डाला गया है। सत्यापन बहुत तेज़ है क्योंकि यह व्यक्तिगत प्रविष्टियों को डीकंप्रेस किए बिना कच्चे बाइट्स पर काम करता है।

V3 हस्ताक्षर (कुंजी रोटेशन)

Android 9.0 से उपलब्ध, V3 कुंजी रोटेशन के समर्थन के साथ V2 का विस्तार करता है। इसमें एक प्रूफ-ऑफ-रोटेशन संरचना शामिल है जो पुरानी और नई हस्ताक्षर कुंजी को जोड़ती है, जिससे डेवलपर्स को अद्यतन अनुकूलता बनाए रखते हुए अपनी हस्ताक्षर कुंजी बदलने की अनुमति मिलती है।

V4 हस्ताक्षर (वृद्धिशील)

Android 11 ने वृद्धिशील इंस्टॉलेशन के लिए V4 पेश किया। यह एक मर्कल ट्री-आधारित हस्ताक्षर प्रदान करता है जो डिवाइस पर स्ट्रीम होने पर व्यक्तिगत ब्लॉकों के सत्यापन की अनुमति देता है।

यदि किसी भी कारण से हस्ताक्षर सत्यापन विफल हो जाता है, तो स्थापना तुरंत निरस्त कर दी जाती है। आप हमारे APK सत्यापनकर्ता उपकरण का उपयोग करके इंस्टॉलेशन से पहले APK के हस्ताक्षर की जांच कर सकते हैं।

हस्ताक्षर मिलान अद्यतन करें

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

चरण 5: उपयोगकर्ता पुष्टिकरण

साइडलोडेड इंस्टॉलेशन के लिए, सिस्टम एक इंस्टॉलेशन पुष्टिकरण संवाद प्रदर्शित करता है:

  • ऐप का नाम और आइकन (APK के संसाधनों से निकाला गया)
  • ऐप अनुरोधित अनुमतियाँ (पुराने Android संस्करणों पर)
  • चाहे यह नया इंस्टालेशन हो या अपडेट
  • ऐप के स्रोत या संभावित जोखिमों के बारे में कोई चेतावनी

Android 12 और उसके बाद के संस्करण पर, पुष्टिकरण स्क्रीन सरल है क्योंकि रनटाइम अनुमतियां व्यक्तिगत रूप से तब दी जाती हैं जब ऐप को इंस्टॉल समय के बजाय पहली बार उनकी आवश्यकता होती है।

चरण 6: फ़ाइल निष्कर्षण और प्लेसमेंट

एक बार जब उपयोगकर्ता पुष्टि कर देता है (या प्ले स्टोर इंस्टॉल के लिए, स्वचालित रूप से), तो सिस्टम फ़ाइलें निकालना और रखना शुरू कर देता है:

APK स्टोरेज

APK फ़ाइल स्वयं /data/app/[package-name]-[random]/base.apk पर कॉपी की गई है। स्प्लिट APK इंस्टॉलेशन के लिए, split_config.arm64_v8a.apk जैसी अतिरिक्त फाइलें बेस APK के साथ रखी जाती हैं। डाउनलोड फ़ोल्डर में मूल APK को संशोधित या हटाया नहीं गया है।

मूल पुस्तकालय निष्कर्षण

यदि APK में मूल लाइब्रेरीज़ (lib/ निर्देशिका में) हैं, तो उन्हें /data/app/[package-name]-[random]/lib/[abi]/ में निकाला जाता है। नए Android संस्करणों पर, ऐप्स APK के भीतर मूल पुस्तकालयों को संपीड़ित रखने और उन्हें android:extractNativeLibs="false" का उपयोग करके सीधे लोड करने का विकल्प चुन सकते हैं, जो भंडारण स्थान बचाता है।

डेटा निर्देशिका निर्माण

सिस्टम /data/data/[package-name]/ (या बहु-उपयोगकर्ता उपकरणों पर /data/user/0/[package-name]/ पर ऐप की निजी डेटा निर्देशिका बनाता है)। यह निर्देशिका ऐप को निर्दिष्ट एक अद्वितीय लिनक्स यूआईडी के स्वामित्व में है, जो यह सुनिश्चित करती है कि कोई भी अन्य ऐप रूट विशेषाधिकारों के बिना इसे एक्सेस नहीं कर सकता है।

चरण 7: DEX अनुकूलन

यह चरण वह है जहां Android ऐप के बाइटकोड को डिवाइस के विशिष्ट हार्डवेयर के लिए अनुकूलित प्रारूप में बदल देता है। Android के इतिहास में यह प्रक्रिया महत्वपूर्ण रूप से विकसित हुई है:

दल्विक युग (Android 4.4 और इससे पहले का संस्करण)

मूल दल्विक वर्चुअल मशीन जस्ट-इन-टाइम (जेआईटी) संकलन का उपयोग करती थी। स्थापना के दौरान, classes.dex फ़ाइल को ODEX फ़ाइल में अनुकूलित किया गया था जिसमें सत्यापित और अनुकूलित बाइटकोड शामिल था। यह अपेक्षाकृत तेज़ था लेकिन इसका मतलब था कि ऐप रनटाइम पर धीमी गति से चलता था क्योंकि अधिकांश कोड की अभी भी व्याख्या की गई थी।

एओटी के साथ एआरटी (Android 5.0 से 6.0)

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

प्रोफ़ाइल-निर्देशित संकलन (Android 7.0+)

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

संकलित कोड को /data/dalvik-cache/ में या APK के साथ .odex, .vdex, और .art फ़ाइलों के रूप में संग्रहीत किया जाता है। .vdex फ़ाइल में सत्यापित DEX कोड होता है, .odex फ़ाइल में संकलित मूल कोड होता है, और .art फ़ाइल में तेज़ स्टार्टअप के लिए पूर्व-प्रारंभिक ढेर छवियां होती हैं।

चरण 8: अनुमति पंजीकरण

PackageManagerService सिस्टम के साथ ऐप की घोषित अनुमतियों और घटकों को पंजीकृत करता है:

  • इंस्टॉल-समय अनुमतियाँ (जैसे INTERNET या VIBRATE उपयोगकर्ता की सहभागिता के बिना स्वचालित रूप से प्रदान किए जाते हैं)।
  • रनटाइम अनुमतियाँ (जैसे CAMERA या LOCATION पंजीकृत हैं लेकिन प्रदान नहीं किए गए हैं)। ऐप को रनटाइम पर उनसे अनुरोध करना होगा।
  • इरादा फ़िल्टर पंजीकृत हैं इसलिए सिस्टम को पता है कि कौन से ऐप्स कौन से कार्यों को संभाल सकते हैं (जैसे यूआरएल खोलना या सामग्री साझा करना)।
  • सामग्री प्रदाता उनके अधिकारियों के साथ पंजीकृत हैं ताकि अन्य ऐप्स उनसे पूछताछ कर सकें।

चरण 9: सिस्टम एकीकरण

अंतिम चरण ऐप को Android सिस्टम में एकीकृत करता है:

  • पैकेज डेटाबेस अद्यतन: सिस्टम के पैकेज डेटाबेस (/data/system/packages.xml) को नए ऐप की जानकारी के साथ अपडेट किया जाता है, जिसमें इसकी निर्दिष्ट यूआईडी, अनुमतियां और घटक घोषणाएं शामिल हैं।
  • लॉन्चर अधिसूचना: होम स्क्रीन लॉन्चर को नए ऐप के बारे में सूचित किया जाता है ताकि यह ऐप आइकन प्रदर्शित कर सके।
  • प्रसारण: सिस्टम एक PACKAGE_ADDED प्रसारण भेजता है, जिससे अन्य ऐप्स को नए इंस्टॉलेशन पर प्रतिक्रिया करने की अनुमति मिलती है (उदाहरण के लिए, बैकअप ऐप्स बैकअप शेड्यूल कर सकते हैं)।
  • SELinux संदर्भ: ऐप की फ़ाइलों को उसके लक्ष्य SDK संस्करण और घोषित अनुमतियों के आधार पर उपयुक्त SELinux सुरक्षा संदर्भ के साथ लेबल किया गया है।

इंस्टालेशन विफल क्यों होते हैं

इंस्टॉलेशन पाइपलाइन को समझने से सामान्य विफलताओं का निदान करने में मदद मिलती है:

  • "पार्स त्रुटि": APK दूषित है, अधूरा है, या विकृत मैनिफ़ेस्ट है। ऐसा अक्सर अधूरे डाउनलोड या अनुचित रूप से परिवर्तित फ़ाइलों के साथ होता है।
  • "ऐप इंस्टॉल नहीं है" (हस्ताक्षर बेमेल): आप एक अलग कुंजी द्वारा हस्ताक्षरित APK के साथ एक ऐप को अपडेट करने का प्रयास कर रहे हैं। आपको पहले मौजूदा संस्करण को अनइंस्टॉल करना होगा।
  • "अपर्याप्त भंडारण": APK, निकाली गई लाइब्रेरी और DEX अनुकूलन आउटपुट के लिए पर्याप्त जगह नहीं है। आवश्यक वास्तविक स्थान आम तौर पर APK आकार का 2-3x होता है।
  • "पैकेज मौजूदा पैकेज के साथ विरोध करता है": समान पैकेज नाम लेकिन अलग हस्ताक्षर। Play Store और साइडलोडेड संस्करणों के बीच स्विच करते समय सामान्य।
  • संस्करण डाउनग्रेड अवरुद्ध: डिफ़ॉल्ट रूप से, Android पुराने संस्करण को नए संस्करण पर इंस्टॉल करने से रोकता है। ADB इसे adb install -d के साथ ओवरराइड कर सकता है।

स्प्लिट APK इंस्टालेशन

स्प्लिट APK (ऐप बंडल से) इंस्टॉल करते समय, प्रक्रिया थोड़ी अलग होती है। सिस्टम सत्र-आधारित स्थापना API का उपयोग करता है:

  1. एक नया इंस्टॉलेशन सत्र बनाया गया है
  2. प्रत्येक स्प्लिट APK सत्र में लिखा जाता है
  3. पूर्ण सत्यापन पाइपलाइन को ट्रिगर करते हुए, सत्र प्रतिबद्ध है
  4. सभी स्प्लिट्स में मेल खाने वाले पैकेज नाम, संस्करण कोड और हस्ताक्षरित प्रमाणपत्र होने चाहिए

यह मल्टी-फ़ाइल इंस्टॉलेशन को संभालने के लिए XAPK इंस्टॉलर्स और हमारे APKS से APK विलय जैसे टूल द्वारा उपयोग किया जाने वाला तंत्र है।

ADB के माध्यम से स्थापना

जब आप adb install का उपयोग करते हैं, तो प्रक्रिया ग्राफ़िकल इंस्टॉलर को बायपास करती है लेकिन उसी आंतरिक पाइपलाइन का अनुसरण करती है। ADB सॉकेट कनेक्शन के माध्यम से पैकेज मैनेजर सेवा के साथ संचार करता है। यह अतिरिक्त झंडों का समर्थन करता है जो GUI के माध्यम से उपलब्ध नहीं हैं:

  • -r: मौजूदा ऐप बदलें (पुनः इंस्टॉल करने की अनुमति दें)
  • -d: संस्करण डाउनग्रेड की अनुमति दें
  • -g: सभी रनटाइम अनुमतियाँ तुरंत प्रदान करें
  • -t: केवल परीक्षण APK की स्थापना की अनुमति दें
  • --install-multiple: एक ही सत्र में स्प्लिट APK इंस्टॉल करें

अनइंस्टॉलेशन के दौरान क्या होता है

पूर्णता के लिए, यहां बताया गया है कि जब कोई ऐप हटा दिया जाता है तो क्या होता है:

  1. ऐप की प्रक्रियाएँ समाप्त हो गई हैं
  2. APK और निकाली गई लाइब्रेरीज़ को /data/app/ से हटा दिया गया है
  3. ऐप की निजी डेटा निर्देशिका हटा दी गई है (जब तक कि उपयोगकर्ता डेटा रखना नहीं चुनता)
  4. संकलित DEX कैश फ़ाइलें हटा दी गई हैं
  5. पैकेज डेटाबेस अद्यतन किया गया है
  6. एक PACKAGE_REMOVED प्रसारण भेजा जाता है
  7. लॉन्चर ऐप आइकन हटा देता है

ध्यान दें कि बाहरी स्टोरेज पर ऐप-विशिष्ट फ़ाइलें (/Android/data/[package]/ और /Android/obb/[package]/ Android 10 और उसके बाद के संस्करण पर भी हटा दी जाती हैं, स्कोप्ड स्टोरेज प्रवर्तन के लिए धन्यवाद)।

पैकेजमैनेजर को समझने से डिबगिंग समय की बचत क्यों होती है?

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

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

एमएसटी शेफेल द्वारा इंजीनियर और प्रलेखित लीड डेवलपर और Android पैकेज आर्किटेक्ट • Android 12-15 पर सत्यापित

Mst Shaefale xapktoapk.com पर क्लाइंट-साइड XAPK/APKS मर्जर, बाइनरी मेनिफेस्ट पार्सर और APK v1+v2 साइनिंग टूल्स का रखरखाव करता है। क्या आपको कोई पुराना कमांड या OS परिवर्तन दिखाई देता है? एक संपादकीय नोट भेजें.