एंड्रॉइड कैसे काम करता है, भाग 4

सभी को नमस्कार! हमने आंतरिक एंड्रॉइड डिवाइस के बारे में लेखों की एक श्रृंखला जारी रखने के लिए समय लिया। इस लेख में, मैं एंड्रॉइड बूट प्रक्रिया के बारे में बात करूंगा, फाइल सिस्टम की सामग्री के बारे में, उपयोगकर्ता और एप्लिकेशन डेटा कैसे संग्रहीत किया जाता है, रूट एक्सेस के बारे में, एंड्रॉइड बिल्ड की पोर्टेबिलिटी के बारे में और विखंडन समस्या के बारे में।

श्रृंखला लेख:

• एंड्रॉइड कैसे काम करता है, भाग 1
• एंड्रॉइड कैसे काम करता है, भाग 2
• एंड्रॉइड कैसे काम करता है, भाग 3
• एंड्रॉइड कैसे काम करता है, भाग 4
• ...

संकुल

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

जैसा कि नाम से पता चलता है कि “पैकेज मैनेजर”, इस स्तर पर अनुप्रयोगों को अक्सर पैकेज कहा जाता है । पैकेज एपीके प्रारूप (एंड्रॉइड पैकेज) - विशेष ज़िप अभिलेखागार में वितरित किए जाते हैं। प्रत्येक पैकेज का एक नाम (जिसे एप्लिकेशन आईडी के रूप में भी जाना जाता है) है जो विशिष्ट रूप से इस एप्लिकेशन की पहचान करता है (लेकिन इसका विशिष्ट संस्करण नहीं है - इसके विपरीत, पैकेज के विभिन्न संस्करणों के नाम मेल खाना चाहिए, अन्यथा उन्हें अलग पैकेज माना जाएगा)। पैकेज के नाम आमतौर पर रिवर्स DNS नाम के अंकन में लिखे जाते हैं - उदाहरण के लिए, YouTube एप्लिकेशन पैकेज नाम com.google.android.youtube का उपयोग करता है। अक्सर पैकेज का नाम उसके जावा कोड में उपयोग किए जाने वाले नामस्थान से मेल खाता है, लेकिन एंड्रॉइड को इसकी आवश्यकता नहीं होती है (इसके अलावा, एप्लिकेशन की एपीके फ़ाइलों में आमतौर पर तीसरे पक्ष के पुस्तकालय शामिल होते हैं, जिनमें से नामस्थान का निश्चित रूप से पैकेज नामों से कोई लेना-देना नहीं है। जो उनका उपयोग करते हैं)।

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

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

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

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

फाइल सिस्टम

फ़ाइल सिस्टम डिवाइस ऑपरेटिंग सिस्टम की वास्तुकला में सबसे महत्वपूर्ण और दिलचस्प मुद्दों में से एक है, और एंड्रॉइड में फाइल सिस्टम डिवाइस कोई अपवाद नहीं है।

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

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

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

• /home स्टोर यूजर होम फोल्डर; यहां, विभिन्न छिपे हुए फ़ोल्डर ( .cache , .cache , .config और अन्य) में, प्रोग्राम उपयोगकर्ता के लिए विशिष्ट अपनी सेटिंग्स, डेटा और कैश को स्टोर करते हैं,
• /boot स्टोर लिनक्स कर्नेल और इनट्राम्राम्स इमेज (विशेष बूट फाइल सिस्टम),
• /usr (यह कॉल /system लिए अधिक तार्किक होगा) /system के मुख्य भाग को स्वयं संग्रहीत करता है, जिसमें लाइब्रेरी, निष्पादन योग्य फाइलें, कॉन्फ़िगरेशन फाइलें, साथ ही साथ संसाधन - इंटरफ़ेस, आइकन, सिस्टम मैनुअल की सामग्री, आदि के लिए थीम शामिल हैं।
• /etc (यह कॉल /config करने के लिए अधिक तार्किक होगा) सिस्टम-वाइड सेटिंग्स को संग्रहीत करता है,
• /dev स्टोर डिवाइस फाइल्स और अन्य विशेष फाइलें (उदाहरण के लिए, सॉकेट /dev/log ),
• /var भंडार परस्पर डेटा - लॉग, सिस्टम कैश, डेटाबेस सामग्री, आदि।

एंड्रॉइड एक समान लेकिन बिल्कुल अलग फाइल सिस्टम लेआउट का उपयोग करता है। यहाँ इसके कुछ सबसे महत्वपूर्ण भाग दिए गए हैं:

• /data स्टोर करने योग्य डेटा,
• कर्नेल और इनट्राम्राम्स छवि को एक अलग फ़्लैश विभाजन पर संग्रहीत किया जाता है, जिसे मुख्य फाइल सिस्टम पर नहीं रखा जा सकता है।
• /system मैच /usr और सिस्टम को स्टोर करता है,
• /vendor - इस Android असेंबली के लिए विशिष्ट फ़ाइलों के लिए डिज़ाइन किया गया /system का एक एनालॉग, और "मानक" एंड्रॉइड में शामिल नहीं है:
• /dev , जैसा कि "सामान्य लिनक्स" में है, डिवाइस फ़ाइलों और अन्य विशेष फ़ाइलों को संग्रहीत करता है।

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

 # mount | grep /system /dev/block/mmcblk0p14 on /system type ext4 (ro,seclabel,relatime,data=ordered) # mount | grep /data /dev/block/mmcblk0p24 on /data type ext4 (rw,seclabel,nosuid,nodev,noatime,noauto_da_alloc,data=writeback) 

एप्लिकेशन - जिनके नाम, उनकी एपीके, ओडेक्स फाइलें (आगे का जावा कोड संकलित) और ईएलएफ लाइब्रेरी - /system/app (सिस्टम के साथ दिए गए /system/app लिए) या /data/app (उपयोगकर्ता द्वारा स्थापित) के लिए स्थापित हैं अनुप्रयोग)। एंड्रॉइड असेंबली बनाते समय, प्रत्येक प्रीइंस्टॉल्ड एप्लिकेशन को फॉर्म /system/app/Terminal के नाम के साथ एक फ़ोल्डर आवंटित किया जाता है, और स्थापना के दौरान उपयोगकर्ता द्वारा इंस्टॉल किए गए एप्लिकेशन के लिए, फ़ोल्डर बनाए जाते हैं जिनके नाम उनके पैकेज नाम से शुरू होते हैं। उदाहरण के लिए, किसी YouTube एप्लिकेशन को फ़ोल्डर में /data/app/com.google.android.youtube-bkJAtUtbTuzvAioW-LEStg==/ जैसे नाम से /data/app/com.google.android.youtube-bkJAtUtbTuzvAioW-LEStg==/ ।

 # pm path com.android.egg package:/system/app/EasterEgg/EasterEgg.apk 

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

पूर्वस्थापित अनुप्रयोगों की एक और विशेषता यह है कि वे विशेष "सिस्टम" अनुमति प्राप्त कर सकते हैं। उदाहरण के लिए, तृतीय-पक्ष एप्लिकेशन को DELETE_PACKAGES अनुमति नहीं मिलती है, जो आपको अन्य अनुप्रयोगों को हटाने की अनुमति देता है, DELETE_PACKAGES , जो आपको सिस्टम को फिर से शुरू करने की अनुमति देता है, और READ_FRAME_BUFFER , जो स्क्रीन की सामग्री तक सीधे पहुंच की अनुमति देता है। इन अनुमतियों में एक हस्ताक्षर सुरक्षा स्तर होता है , अर्थात् , उन्हें एक्सेस करने की कोशिश करने वाले एप्लिकेशन को उसी कुंजी के साथ हस्ताक्षरित किया जाना चाहिए, जिस पर वे लागू होते हैं या जिस सेवा में लागू होते हैं - इस मामले में, चूंकि ये अनुमतियाँ सिस्टम द्वारा कार्यान्वित की जाती हैं, जिस कुंजी के साथ यह हस्ताक्षरित है। Android निर्माण

परिवर्तनशील डेटा को संग्रहीत करने के लिए, प्रत्येक एप्लिकेशन को /data/data (उदाहरण के लिए, /data/data/com.google.android.youtube लिए एक फ़ोल्डर आवंटित किया जाता है)। केवल एप्लिकेशन को ही इस फ़ोल्डर तक पहुंच है - अर्थात, केवल यूआईडी जिसके तहत यह एप्लिकेशन लॉन्च किया गया है (यदि एप्लिकेशन कई यूआईडी का उपयोग करता है, या यदि कई एप्लिकेशन एक सामान्य यूआईडी का उपयोग करते हैं, तो सब कुछ अधिक जटिल हो सकता है)। इस फ़ोल्डर में, एप्लिकेशन सेटिंग्स, कैशे ( shared_prefs और cache सबफ़ोल्डर्स में क्रमशः) और किसी भी अन्य डेटा को सेव करते हैं जो उनकी मदद करते हैं

 # ls /data/data/com.google.android.youtube/ cache code_cache databases files lib no_backup shared_prefs # cat /data/data/com.google.android.youtube/shared_prefs/youtube.xml <?xml version='1.0' encoding='utf-8' standalone='yes' ?> <map> <string name="user_account">username@gmail.com</string> <boolean name="h264_main_profile_supported7.1.2" value="true" /> <int name="last_manual_video_quality_selection_max" value="-2" /> <...> </map> 

सिस्टम cache फ़ोल्डर के अस्तित्व के बारे में जानता है और पर्याप्त जगह न होने पर इसे अपने आप साफ कर सकता है। जब आप किसी एप्लिकेशन को हटाते हैं, तो इस एप्लिकेशन का संपूर्ण फ़ोल्डर पूरी तरह से हटा दिया जाता है, और एप्लिकेशन कोई निशान नहीं छोड़ता है। वैकल्पिक रूप से, दोनों उपयोगकर्ता सेटिंग्स में स्पष्ट रूप से कर सकते हैं:

प्रत्येक एप्लिकेशन को आवंटित इस डेटा स्टोरेज को इंटरनल स्टोरेज कहा जाता है।

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

 # ls /sdcard Alarms Download Podcasts Android Movies Ringtones Books Music Subtitles DCIM Notifications bluetooth Documents Pictures 

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

कई एप्लिकेशन अपनी कुछ आंतरिक फ़ाइलों को सहेजना पसंद करते हैं, जो कि बड़े (उदाहरण के लिए, डाउनलोड की गई छवियों और ऑडियो फ़ाइलों का एक कैश) बाहरी भंडारण में हैं। ऐसा करने के लिए, एंड्रॉइड बाहरी संग्रहण फ़ोल्डर में एप्लिकेशन को Android/data/com.google.android.youtube नाम के साथ आवंटित करता है। एप्लिकेशन को स्वयं को इस तरह के फ़ोल्डर तक पहुंचने के लिए पूरे बाहरी संग्रहण तक पहुंचने की अनुमति की आवश्यकता नहीं है (क्योंकि इसका यूआईडी इस फ़ोल्डर के मालिक के रूप में सेट है), लेकिन किसी भी अन्य एप्लिकेशन के पास यह अनुमति इस फ़ोल्डर तक पहुंच सकती है, इसलिए यह वास्तव में उपयोग करने लायक है केवल सार्वजनिक और गैर-महत्वपूर्ण डेटा संग्रहीत करने के लिए। जब आप एप्लिकेशन को अनइंस्टॉल करते हैं, तो सिस्टम बाहरी भंडारण में अपने विशेष फ़ोल्डर को भी हटा देगा; लेकिन उनके विशेष फ़ोल्डर के बाहर बाहरी भंडारण में अनुप्रयोगों द्वारा बनाई गई फ़ाइलों को उपयोगकर्ता से संबंधित माना जाता है और उन्हें बनाए गए एप्लिकेशन को हटाने के बाद जगह में रहता है।

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

इसलिए, आधुनिक एंड्रॉइड में, लगभग हमेशा आंतरिक और बाह्य दोनों भंडारण आंतरिक मेमोरी में स्थित होते हैं। वास्तविक पथ जिसके साथ फ़ाइल सिस्टम में बाहरी संग्रहण स्थित है, वह प्रपत्र /data/media/0 लेता है (प्रत्येक डिवाइस उपयोगकर्ता के लिए एक अलग बाहरी संग्रहण बनाया जाता है , और पथ में संख्या उपयोगकर्ता संख्या से मेल खाती है)। अनुकूलता प्रयोजनों के लिए, बाहरी संग्रहण को /sdcard , /mnt/sdcard , /storage/self/primary , /storage/emulated/0 पथों के माध्यम से भी एक्सेस किया जा सकता है, कई रास्ते /mnt/runtime/ , और कुछ अन्य से शुरू होते हैं।

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

आप इस सब के बारे में अधिक पढ़ सकते हैं, उदाहरण के लिए, इस पोस्ट में और एप्लिकेशन डेवलपर्स और एंड्रॉइड असेंबली रचनाकारों के लिए आधिकारिक दस्तावेज में।

लदान

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

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

डिवाइस पर भौतिक पहुँच प्राप्त करने वाले हमलावर के विरुद्ध सुरक्षा के साथ स्थिति को बेहतर बनाने का प्रयास करने के दो तरीके हैं:

• सबसे पहले, डिस्क पर संग्रहीत डेटा को एन्क्रिप्ट करना संभव है, जिससे किसी हमलावर को डेटा तक पहुंच प्राप्त करने से रोका जा सके, भले ही उसके पास डिस्क की सामग्री तक पहुंच हो।
• दूसरे, डिवाइस पर मनमाने ढंग से ऑपरेटिंग सिस्टम को लोड करने की क्षमता को सीमित करना संभव है , एक हमलावर को स्थापित सिस्टम में प्रमाणीकरण और प्राधिकरण प्रक्रियाओं से गुजरने के लिए मजबूर करता है।

यह सुरक्षा के इन दो क्षेत्रों के साथ है जो एंड्रॉइड सुरक्षित बूट मॉडल से जुड़ा हुआ है।

सत्यापित बूट

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

सबसे पहले, एंड्रॉइड डिवाइस, "डेस्कटॉप" कंप्यूटरों के विपरीत, आमतौर पर किसी उपयोगकर्ता (या हमलावर) को बाहरी माध्यम से बूट करने की अनुमति नहीं देते हैं; इसके बजाय, डिवाइस पर स्थापित बूटलोडर (बूटलोडर) तुरंत शुरू होता है। बूटलोडर एक अपेक्षाकृत सरल कार्यक्रम है जिसके कार्यों (सामान्य मोड में लोड होने पर) में शामिल हैं:

• विश्वसनीय निष्पादन पर्यावरण का आरंभीकरण और विन्यास (जैसे एआरएम ट्रस्टज़ोन),
• लिनक्स कर्नेल छवियों और initramfs को संग्रहीत करने वाली आंतरिक मेमोरी के विभाजन को खोजना,
• उनकी अखंडता (अखंडता) का सत्यापन - अन्यथा डाउनलोड एक त्रुटि संदेश के साथ बाधित है - निर्माता के डिजिटल हस्ताक्षर को सत्यापित करके,
• मेमोरी में कर्नेल और इनट्राम्राम्स लोड करना और कर्नेल पर नियंत्रण स्थानांतरित करना।

फ्लैशिंग, अनलॉकिंग, फास्टबूट और रिकवरी

इसके अलावा, बूटलोडर सिस्टम को अपडेट करने और पुनर्स्थापित करने के लिए अतिरिक्त कार्यक्षमता का समर्थन करता है।

-, (Android) , recovery . recovery, Android- , , Android recovery .

«» bootloader', — ( flashing ) . bootloader , fastboot mode ( bootloader mode), bootloader' fastboot ( fastboot Android SDK ).

bootloader' . , Samsung, bootloader'a (Loke) (Odin). Odin Samsung ( Odin), Heimdall .

bootloader' ( ), recovery Android, , :

 $ fastboot flash recovery recovery.img $ fastboot flash boot boot.img $ fastboot flash system system.img 

; : , , bootloader' Android, , , , .

, bootloader' (unlocking the bootloader, OEM unlock) — bootloader' recovery, ( ). Android, LineageOS ( CyanogenMod ), Paranoid Android , AOKP , OmniROM .

bootloader' - , ( data ) . , , (, Google ), — , .

recovery bootloader , .

bootloader' :

recovery, «» (flashaholics) — TWRP (Team Win Recovery Project). - «», zip-, :

Android ( file-based encryption ). ext4 , Linux ( fscrypt ), .

, data , , (credential encrypted storage). , , . , , .

credential encrypted storage Android device encrypted storage — , ( Trusted Execution Environment). , , , . , Direct Boot : ; ( ) device encrypted storage, , . , Direct Boot , , - .

Root

root- — « root» (UID 0, ). , root — Unix-, — — , .

, Android , root- . , « », Android « », root- «», :

• — , APK ,
• : -, email-, , , , , , ( activity intent', ),
• (icon packs),
• , ,
• ( Android-) ,
• , Android, .

, , , root- . root- ( ), Android root . , , Unix-; shell, adb shell , Unix- shell .

, , root :

• -, root- Android — Android Studio QEMU, .
• -, root- Android ( pre-rooted ROMs).
• -, bootloader' root- Android , , su , bootloader.
• , -, , , root-, ( root- ). , 2016 , root- Dirty Cow .

? , root- . , root-, , , . — , . , , system ( ).

, root- — , .

root-

With great power comes great responsibility.

, . , root- .

, , . , root- , , , root- . root, , , , — , , , ..

, Unix, Android , — . root- , , . , root- Android, .

, , root- , . , , , , , . , — , Google Pay ( Android Pay) — root- , .

, - Pokémon GO root- , , .

Google Play root-

Google Google Play Store Google Play Services , root- , Android , , , , . Play Store — ( , ) Android, . ( — , Amazon Android Fire OS — Echo, Fire TV, Fire Phone, Kindle Fire Tablet — Google). root- Android-.

, Google , root-, Google Play ( Open GApps ); Google , .

Device manufacturers work with Google to certify that Android devices with Google apps installed are secure and will run apps correctly. To be certified, a device must pass Android compatibility tests. If you are unable to add a Google Account on your Android device, your Android device software might not have passed Android compatibility tests, or the device manufacturer has not submitted the results to Google to seek approval. As a result, your device is uncertified. This means that your device might not be secure.

If you are a User wanting to use custom ROMs on your device, please register your device by submitting your Google Services Framework Android ID below.

root

«» Linux, Unix-, root- ( sudo su ) ( , Unix- root, ) (, ). , root-.

su Android Open Source Project , Unix- shell ( root), root-. su , , , .

, su . su , root-. , SuperSU ; Magisk .

Magisk

Magisk — , , /system , system ( systemless-ly ), «» Linux . Magisk Hide — root-, root- Magisk — - Google Pay, root- . Magisk Hide root-, SafetyNet Google.

, , Google Pay root- — root- . , root-, - Google Pay. , .

Magisk systemless- «» Magisk Modules , Magisk. , , root- Xposed ViPER , .

SoC,

, «», , — , — (, Wi-Fi ).

, Android- (system on a chip, SoC). — , , -, , LTE-, Bluetooth- Wi-Fi- .. — . , , , , , .

, , . , «», , , , . , , -, , , , .

— Android — SoC . , , — LTE- — . , ; , , .

SoC (, Qualcomm) Android- (, Sony LG), Android, Android Open Source Project. , Android, , , .

Android Android-. , Android. Android , , . .

, : Android — , . Android, .

, , , Android. .

-, . , . , , , , .

-, Android — developer experience (DX, user experience/UX). , Android, API — Android Framework, OpenGL/Vulkan — . , , , Android — , , .

Don't Stop Thinking About Tomorrow

Android- . , Google Nexus Pixel , Android. Android , , , .

, , Android, SoC. Android «» (, , Android-x86 RemixOS ). Android ChromeOS, Chromebook' Android- Linux- -. — Android — Anbox , Android- «» Linux-. (, Android- x86-, , Java, .)

, Android — , Android .

— Android. , , . , , Android .

. 2017 Google Project Treble — , ( HAL, hardware abstraction layer) ( , ) . Treble , , , — — .

Treble . Treble (Sony, Nokia, OnePlus, Oppo, Xiaomi, Essential Vivo — Google) - Android Pie. Treble Essential Android Pie Essential Phone Android Pie. Android — - — , Treble, , SoC.

Treble . Java «write once, run everywhere» — Android- . Treble — , Android SoC. , , Treble. , Android- .

userspace Android: init, Zygote, Binder, props.