मैसाचुसेट्स इंस्टीट्यूट ऑफ टेक्नोलॉजी। व्याख्यान पाठ्यक्रम # 6.858। "कंप्यूटर सिस्टम की सुरक्षा।" निकोलाई ज़ेल्डोविच, जेम्स मिकेंस। 2014 साल
कंप्यूटर सिस्टम सुरक्षा सुरक्षित कंप्यूटर सिस्टम के विकास और कार्यान्वयन पर एक कोर्स है। व्याख्यान खतरे के मॉडल को कवर करते हैं, हमले जो सुरक्षा से समझौता करते हैं, और हाल के वैज्ञानिक कार्यों के आधार पर सुरक्षा तकनीक। विषयों में ऑपरेटिंग सिस्टम (OS) सुरक्षा, सुविधाएँ, सूचना प्रवाह प्रबंधन, भाषा सुरक्षा, नेटवर्क प्रोटोकॉल, हार्डवेयर सुरक्षा और वेब अनुप्रयोग सुरक्षा शामिल हैं।
व्याख्यान 1: "परिचय: खतरे के मॉडल"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 2: "हैकर हमलों का नियंत्रण"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 3: "बफर ओवरफ्लो: शोषण और संरक्षण"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 4: "पृथक्करण का पृथक्करण"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 5: "सुरक्षा प्रणालियाँ कहाँ से आती हैं?"
भाग 1 /
भाग 2व्याख्यान 6: "अवसर"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 7: "मूल ग्राहक सैंडबॉक्स"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 8: "नेटवर्क सुरक्षा मॉडल"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 9: "वेब अनुप्रयोग सुरक्षा"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 10: "प्रतीकात्मक निष्पादन"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 11: "उर / वेब प्रोग्रामिंग भाषा"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 12: नेटवर्क सुरक्षा
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 13: "नेटवर्क प्रोटोकॉल"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 14: "एसएसएल और एचटीटीपीएस"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 15: "मेडिकल सॉफ्टवेयर"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 16: "साइड चैनल हमलों"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 17: "उपयोगकर्ता प्रमाणीकरण"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 18: "निजी ब्राउज़िंग इंटरनेट"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 19: "बेनामी नेटवर्क"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 20: "मोबाइल फोन सुरक्षा"
भाग 1 /
भाग 2 /
भाग 3 छात्र: अब कई अनुप्रयोगों में अनुमतियाँ हटाने का कोई तरीका नहीं है।
प्रोफेसर: हाँ, एंड्रॉइड के नए संस्करण में यह नहीं है, बस अनुमति विवरण हैं। लेकिन आप एंड्रॉइड परमिशन मैनेजर, या एंड्रॉइड अनुमति प्रबंधक का उपयोग कर सकते हैं, जो आपको प्रत्येक एप्लिकेशन के लिए सभी अनुमतियों की एक सूची देखने और विशेष रूप से उन लोगों को हटाने की अनुमति देता है जिन्हें आप अनावश्यक मानते हैं। लेकिन मुझे नहीं पता कि यह बात उपयोगकर्ताओं के बीच लोकप्रिय कैसे है।
छात्र: यदि लेबल को उन अनुमतियों से मेल नहीं खाता है, जिनके लिए आवेदन की आवश्यकता है, तो क्या इससे कोई गंभीर त्रुटि होती है या क्या सब कुछ ठीक काम जारी रहता है?
प्रोफेसर: मुझे लगता है कि यह इस बात पर निर्भर करता है कि आवेदन क्या करने की कोशिश कर रहा है और लेबल क्या अनुमति देता है। उदाहरण के लिए, यदि कोई एप्लिकेशन इंटेंट को भेजने जा रहा है और इस आशय को भेजने के लिए DIALPERM प्रकार के एक निश्चित लेबल की आवश्यकता है, तो यह सबसे पहले लिंक मॉनिटर पर जाता है, जो कहता है: "दुर्भाग्य से, सिस्टम में ऐसा एप्लिकेशन नहीं है जो आपके संदेश को प्राप्त करने के लिए तैयार हो।" और इस एप्लिकेशन के जवाब में, यह कुछ उचित कदम उठा रहा है।
अन्यथा, उदाहरण के लिए, जब नेटवर्क तक पहुंच हो। यदि आपके पास नेटवर्क तक पहुंच नहीं है, और आप सॉकेट खोलने जा रहे हैं या आईपी पते से कनेक्ट करने के लिए कमांड दे रहे हैं, तो कर्नेल आपको संदेश EPERM, "ऑपरेशन की अनुमति नहीं है" के साथ जवाब देगा, अर्थात, आप ऐसा नहीं कर सकते। और कौन जानता है कि इस मामले में आवेदन क्या करने जा रहा है? यह संभव है कि यह किसी तरह एक शून्य सूचक अपवाद को फेंक देगा या ऐसा कुछ करेगा।
इसके विरुद्ध एक तर्क यह है कि एंड्रॉइड एप्लिकेशन, कम से कम शुरुआत में, उनके कुछ कॉल के विफल होने की उम्मीद नहीं करते थे, क्योंकि उन्हें बताया गया था कि मेनिफेस्ट सभी या कुछ भी नहीं है, अर्थात, या तो उपयोगकर्ता अनुमोदन करता है एप्लिकेशन इंस्टॉल करना या नहीं। इसलिए एप्लिकेशन डेवलपर्स ने कोड को सही ढंग से लिखा है, जो कि अगर उपयोग से वंचित है तो क्रैश या कुछ अप्रत्याशित करता है। शायद इसकी आवश्यकता के उपयोग की अनुमति से वंचित करके, आप इसके संचालन की विफलता को भड़काते हैं।
मान लीजिए कि आपके पास एक एप्लिकेशन है जिसे कैमरे तक पहुंच की आवश्यकता है। और यदि आप उसकी पहुंच को सही तरीके से हटाते हैं, तो चित्र टेम्पलेट केवल स्मार्टफोन स्क्रीन पर दिखाई देगा, या शायद एप्लिकेशन क्रैश हो जाएगा। यह बहुत अच्छा नहीं है। संभवतः, अधिक जटिल प्रणाली बनाना संभव होगा, जो कैमरे तक पहुंच से वंचित होने की स्थिति में हर समय एक काली स्क्रीन प्रदर्शित करेगा। एंड्रॉइड ऐसा नहीं करता है, लेकिन आप उन वैकल्पिक स्थितियों की कल्पना कर सकते हैं जिनमें ऐसा हो सकता है।
इसलिए, हमने जांच की कि एंड्रॉइड एप्लिकेशन लेबल में ये लाइनें कहां से आती हैं। लेकिन जो इन पंक्तियों को परिभाषित करता है, वे कहाँ से अर्थ प्राप्त करते हैं? आप मेनिफ़ेस्ट फ़ाइल में सभी प्रकार की पंक्तियों को सूचीबद्ध कर सकते हैं, लेकिन आप कैसे तय करते हैं कि कौन सी रेखाएँ मायने रखती हैं, इंटरनेट या FRIENDVIEW लाइनें कहाँ से आती हैं? कौन उन्हें व्यवस्था में अर्थ देता है?
मुझे लगता है कि आपके पास कोई विचार नहीं है। मुझे लगता है कि इनमें से कोई भी रेखा कुछ जादुई या पूर्व निर्धारित नहीं होनी चाहिए। इनमें से लगभग सभी लाइनें मूल रूप से दो अनुप्रयोगों के बीच के समझौते हैं, जब अनुप्रयोगों में से एक कुछ लेबल लाइन के संरक्षण के तहत कुछ प्रदान करने के लिए तैयार है, और दूसरा अनुप्रयोग इस घटक को प्रदान करने वाले एप्लिकेशन के साथ बात करने की अनुमति का अनुरोध करना चाहता है।
इसलिए, इन लेबल को आमतौर पर एक एप्लिकेशन द्वारा परिभाषित किया जाता है जो कुछ सेवाएं प्रदान करता है। यदि आपके पास DIALPERM की अनुमति है, तो इसे एप्लिकेशन में परिभाषित किया जाना चाहिए, जो परिभाषित करता है कि फोन नंबर डायल करने का क्या मतलब है। जाहिरा तौर पर, आपके फोन पर कॉल करने के लिए आवेदन इस लाइन को परिभाषित करता है और कहता है कि, हां, यह DIALPERM चीज मौजूद है, और मेरे घटक इसके द्वारा सुरक्षित रहेंगे। फिर अन्य एप्लिकेशन जो कॉलिंग एप्लिकेशन के साथ बातचीत करना चाहते हैं, वे अपने लिए इस DIALPERM अनुमति का अनुरोध कर सकेंगे।
बेशक, कुछ अंतर्निहित चीजें हैं, जैसे कि इंटरनेट का उपयोग करने की अनुमति, एक कैमरा, और इसी तरह। लेकिन आप उन्हें एंड्रॉइड रनटाइम के स्रोत अनुप्रयोगों के रूप में देख सकते हैं, जो इस संसाधन तक पहुंच प्रदान करने के लिए जिम्मेदार है और इस संसाधन की रक्षा करने वाली रेखा को परिभाषित करता है।
इसका क्या मतलब है? एंड्रॉइड में लेबल के साथ और क्या जुड़ा है, इस तथ्य के अलावा कि यह एप्लिकेशन द्वारा उपयोग किया जाता है जब इसे अनुमति का अनुरोध करने की आवश्यकता होती है? यह पता चला है कि कई चीजें हैं जो लेबल के साथ जुड़ी हुई हैं। स्ट्रिंग के अलावा, लेबल में कई दिलचस्प गुण हैं। विशेष रूप से, एंड्रॉइड में 3 प्रकार के टैग हैं। पहला नियमित अनुमतियाँ है, दूसरा असुरक्षित अनुमतियाँ है, और तीसरा हस्ताक्षरित अनुमतियाँ है।
सबसे पहले इस अनुमति को निर्धारित करने वाले एप्लिकेशन को लेबल के लिए प्रकार और अन्य सभी क्षेत्रों का चयन करने का अवसर मिलता है, जिसके बारे में हम एक सेकंड में बात करेंगे। तो ये टैग प्रकार क्या हैं? एंड्रॉइड लेबल को प्रकारों की आवश्यकता क्यों है?
छात्र: क्या वे उपयोगकर्ता के लिए एक चेतावनी के रूप में कार्य करते हैं?
प्रोफेसर: बिल्कुल। फिर असुरक्षित प्रकार के सभी टैग क्यों नहीं बनाए गए? इन प्रकारों का शब्दार्थ क्या है? सीधे शब्दों में कहें, "खतरनाक" लेबल का उपयोग किसी एप्लिकेशन को अनुमति देने के लिए किया जाता है जो कुछ बर्बाद कर सकता है। यह एप्लिकेशन इंस्टॉल करते समय उपयोगकर्ताओं को चेतावनी देता है जब आवेदन एक असुरक्षित अनुमति तक पहुंच का अनुरोध करता है। उसी समय, उपयोगकर्ता को इस संदेश को देखना चाहिए और कहना चाहिए: "हां, मैं इस नए एप्लिकेशन को असुरक्षित अनुमति देने के लिए तैयार हूं।" यदि एप्लिकेशन सामान्य प्रकार के लेबल का अनुरोध करते हैं, तो उपयोगकर्ता को इस कार्रवाई के लिए अनुमति देने की आवश्यकता के बारे में संदेश नहीं मिलता है। यदि सभी एप्लिकेशन उन्हें प्राप्त करते हैं तो सामान्य अनुमतियों का क्या अर्थ है? क्या कोई कारण है कि हमें नियमित प्रकार के लेबल का उपयोग करना चाहिए?
एंड्रॉइड में एक विशिष्ट रिज़ॉल्यूशन का एक उदाहरण ऑन-स्क्रीन वॉलपेपर सेट कर रहा है। यदि आपके पास एक एप्लिकेशन है जो वॉलपेपर स्थापित करने जा रहा है, तो मैं, एप्लिकेशन डेवलपर के रूप में, मेरे प्रकट में इंगित कर सकता हूं कि मैं सिर्फ आपके लिए वॉलपेपर स्थापित करना चाहता हूं। और यदि आप इंस्टॉल पर क्लिक करते हैं, तो कुछ भी दिलचस्प नहीं होगा, क्योंकि आपको इस एप्लिकेशन को किसी भी अनुमति देने की आवश्यकता नहीं है।
छात्र: लेकिन इन अनुमतियों को आमतौर पर आपसे पुष्टि की आवश्यकता होती है, है ना? यदि एप्लिकेशन डेस्कटॉप वॉलपेपर बदलना चाहता है, तो सिस्टम आपसे पूछेगा कि क्या आप वॉलपेपर बदलना चाहते हैं।
प्रोफेसर: नहीं।
छात्र: नहीं?
प्रोफेसर: नहीं, यह सिर्फ वॉलपेपर बदल देगा क्योंकि यह सिर्फ एपीआई कॉल तक पहुंच है। अगर मेरे पास इसकी अनुमति है, तो मैं सिर्फ एक एपीआई कॉल करता हूं।
छात्र: शायद एप्लिकेशन डेवलपर यह सुनिश्चित करना चाहता है कि उपयोगकर्ता दुर्घटना से ऐसा न करें?
प्रोफेसर: हाँ, मुझे लगता है कि यह एक कारण है कि आपको इन अनुमतियों की आवश्यकता हो सकती है, डेवलपर की गलतियों से बचने में मदद करने की इच्छा है। यदि आप चिंतित हैं कि आपका आवेदन गलती से कुछ गलत कर सकता है या इसमें त्रुटियां हो सकती हैं, जिसका उपयोग किया जा सकता है, तो अनुमतियों के एक सेट का अस्तित्व जो आपको प्राप्त हो सकता है या नहीं, आपके आवेदन के दुरुपयोग की संभावना को कम करेगा। इसलिए यदि आपके पास एक हानिरहित एप्लिकेशन है जिसे किसी भी वॉलपेपर को स्थापित करने की आवश्यकता नहीं है, तो आपको किसी भी अनुमति के लिए पूछने की आवश्यकता नहीं होगी, क्योंकि यह उस उपयोगकर्ता के लिए बेहतर है जिसके फोन पर यह इंस्टॉल किया गया है। कुछ हद तक, यह एक प्रकार का विशेषाधिकार है।
एक और बात यह है कि सामान्य प्रकार के लेबल का अस्तित्व आपको किसी भी प्रकार का ऑडिट करने की अनुमति देता है, दोनों डेवलपर की तरफ से और उपयोगकर्ता की ओर से। यदि आपका फोन हर सेकंड स्क्रीन पर वॉलपेपर बदलता है, तो आप अंदर जा सकते हैं और देख सकते हैं कि इसके लिए किस एप्लिकेशन की अनुमति है। यहां तक कि अगर आपने ऐसी अनुमति देने का अनुमोदन नहीं किया, तो भी आप जा सकते हैं और जांच सकते हैं कि वर्तमान में कौन सा एप्लिकेशन वॉलपेपर बदलने में लगा हुआ है।
इस प्रकार, ये सामान्य अनुमतियां एक अच्छा सुरक्षा उपाय प्रतीत होती हैं, या, अधिक हद तक, एप्लिकेशन गतिविधि को ऑडिट करने का एक अच्छा अवसर है। आमतौर पर इस तरह के लेबल का उपयोग वास्तव में महत्वपूर्ण चीजों के लिए नहीं किया जाता है, जैसे कि डेटा के साथ काम करना या सेवाओं तक पहुंचना जो पैसे खर्च करते हैं।
तीसरे प्रकार के लेबल पर हस्ताक्षर की अनुमति है। एंड्रॉइड की एक दिलचस्प संपत्ति केवल उन अनुप्रयोगों तक पहुंच प्रदान करने की क्षमता है जो उसी डिजिटल हस्ताक्षर के साथ हस्ताक्षर किए जाते हैं जिसमें आवेदन सही पहुंच घोषित किया जाता है। व्याख्यान लेख FRIENDVIEW के साथ एक उदाहरण का वर्णन करता है। अगर दोस्तों को इस प्रकार के टैग के साथ अनुमति को परिभाषित किया गया है, तो उसी डेवलपर कुंजी के साथ हस्ताक्षर किए गए एप्लिकेशन उसी अनुमति को प्राप्त करने में सक्षम होंगे। इस बात का क्या मतलब है? सिर्फ उन्हें असुरक्षित क्यों नहीं चिह्नित करें? हमें तीसरे प्रकार के लेबल की आवश्यकता क्यों है?
छात्र: क्या यह एक डेवलपर के लिए उनके अनुप्रयोगों का प्रबंधन करना आसान बनाता है?
प्रोफेसर: हाँ। यह हो सकता है कि इस डेवलपर के पास आंतरिक एपीआई है जिसे वह तीसरे पक्ष के कार्यक्रमों के प्रभावों से अलग करना चाहता है, लेकिन साथ ही उत्पादक बातचीत के लिए अपने स्वयं के अनुप्रयोगों को एक साथ बंडल करना चाहता है। हाइपोथेटिक रूप से, फेसबुक के निर्माता कई एप्लिकेशन लिख सकते थे। उनके पास एक एप्लिकेशन हो सकता है जो फेसबुक सर्वर से सामग्री को प्री लोड करता है, एक अन्य एप्लिकेशन उस सामग्री को मिलाता है, एक तीसरा आपके स्थान को ट्रैक करता है और ये सभी घटक एक दूसरे के साथ बातचीत करते हैं। ऐसे मामले के लिए, वे एक हस्ताक्षरित परमिट का उपयोग कर सकते हैं।
जिन कारणों से आप इस एप्लिकेशन को निर्दिष्ट नहीं करना चाहते हैं, उनमें से एक यह है कि असुरक्षित निम्नलिखित है। यदि आप वास्तव में जानते हैं कि यह अनुमति कौन प्राप्त कर सकता है, तो आप नहीं चाहते कि उपयोगकर्ता हस्तक्षेप करे। क्योंकि दुर्भावनापूर्ण एप्लिकेशन को अनुमति देने के लिए उपयोगकर्ता को हमेशा धोखा दिया जा सकता है, इसलिए यह बेहतर है कि वह कुछ अनुप्रयोगों के लिए आंतरिक विशेषाधिकारों के प्रावधान में हस्तक्षेप नहीं करता है। तो इस अर्थ में हस्ताक्षरित अनुमतियों का उपयोग करना बेहतर है।
लेबल में उपयोगकर्ता अनुमतियों का विवरण भी होता है। यह एक अनुमति क्या है, इसका विवरण है। यह विवरण तब प्रकट होता है जब आपको एक नया एप्लिकेशन इंस्टॉल करने के लिए प्रेरित किया जाता है।
इस प्रकार, एंड्रॉइड रनटाइम उस एप्लिकेशन के प्रकट होने में लेबल की सभी पंक्तियों को देखेगा जिसे आप स्थापित करने जा रहे हैं, और उपयोगकर्ता को इन सभी चिह्नित लाइनों के विवरणों के साथ प्रदर्शित करते हैं, उदाहरण के लिए: "आप इस एप्लिकेशन को डायल करने का विशेषाधिकार देने जा रहे हैं, या अपनी ओर से एसएमएस भेजने की अनुमति दें" और इतने पर।
एक दिलचस्प सवाल: अगर कोई दुर्भावनापूर्ण एप्लिकेशन किसी अन्य एप्लिकेशन के लिए लेबल बदलता है तो क्या होगा? आखिरकार, ये निशान सिर्फ फ्री-फॉर्म स्ट्रिंग्स हैं। तो क्या होता है यदि आप एक दुर्भावनापूर्ण एप्लिकेशन हैं जो कहता है: "ओह, मेरे पास यह नया, बड़ा संकल्प है! इसे DIALPERM कहा जाता है। ” इसका कोई असुरक्षित लेबल नहीं है, और इसका विवरण कुछ भी नहीं देता है। क्या यह खतरनाक है?
छात्र: यह संभवतः एप्लिकेशन के डोमेन नाम की संरचना को प्रभावित करने में सक्षम नहीं होगा।
प्रोफेसर: हाँ, यह उम्मीद की जा सकती है, लेकिन, दुर्भाग्य से, यह अनिवार्य नहीं है। आमतौर पर, सभी अनुमति स्ट्रिंग में जावा-शैली डोमेन नाम होना चाहिए, लेकिन उन लेबलों के बीच कोई सख्त संबंध नहीं है जो एप्लिकेशन को परिभाषित करता है और जावा-शैली एप्लिकेशन का अपना नाम है। जावा-स्टाइल एप्लिकेशन नाम को किसी चीज़ से बंधे होने के लिए मजबूर करने के लिए कुछ भी नहीं है, इसलिए हमारे पास यह पता लगाने का अवसर नहीं है कि डेवलपर सार्वजनिक कुंजी जो विशिष्ट एप्लिकेशन को com.google.something या edu पर कुछ से मेल खाता है। mit.something।
एंड्रॉइड में एक खामी है, या कम से कम अस्तित्व में है जब मैंने हाल ही में इस प्रश्न में देरी की है। इसलिए, लेबलों को परिभाषित करते समय, सिद्धांत "जो पहले आया था, सेवा की जाती है"। यही है, जब आप एप्लिकेशन इंस्टॉल करते हैं, तो यह एक विशिष्ट लेबल को परिभाषित करता है, और आप तय कर सकते हैं कि किस प्रकार का लेबल है और इसका विवरण क्या है। सिस्टम अनुमतियों के लिए, यह संभवतः एक बड़ी समस्या नहीं है, क्योंकि सिस्टम अनुमतियाँ या एम्बेडेड अनुप्रयोग, जैसे डायलर, शुरुआत में परिभाषित होते हैं। लेकिन बाद में स्थापित किए गए एप्लिकेशन अनुमतियों को ओवरराइड नहीं कर सकते, क्योंकि यह फ्रेमवर्क के कारण है।
समस्या यह है कि यदि आप पहली बार एक दुर्भावनापूर्ण एप्लिकेशन इंस्टॉल करते हैं, और फिर कुछ महत्वपूर्ण एप्लिकेशन, तो दुर्भावनापूर्ण एप्लिकेशन संभावित रूप से अच्छी तरह से उपयोग किए गए लेबलों को बाद में विकृत कर सकता है। व्याख्यान लेख एक ऐसे मामले का वर्णन करता है जहां एक हमलावर उपयोगकर्ता को एक दुर्भावनापूर्ण एप्लिकेशन इंस्टॉल करने के लिए मजबूर करता है जो FRIENDVIEW एप्लिकेशन के लिए लेबल प्रकार को एक विवरण पंक्ति के साथ एक सामान्य प्रकार में बदल देता है जैसे "बिल्कुल भी दिलचस्प नहीं है।" बाद में, जब आप FRIENDVIEW एप्लेट स्थापित करते हैं, तो यह अब इस लेबल को ओवरराइड नहीं कर सकता है, क्योंकि यह पहले से ही परिभाषित है, और अब उपयोगकर्ता अन्य एप्लिकेशन को मित्रों को अनुमति देखने का उपयोग करने से नहीं रोक पाएगा।
छात्र: शायद सिस्टम संकल्प बदलने के प्रयासों की चेतावनी दे सकता है?
प्रोफेसर: सिद्धांत रूप में, ढांचा इसके लिए सक्षम है, लेकिन जब मैंने ऐसा करने की कोशिश की, तो कोई संदेश जारी नहीं किया गया। यदि आप एक एप्लिकेशन इंस्टॉल करते हैं जो एक लेबल को परिभाषित करता है जो पहले से ही परिभाषित है, तो सिस्टम कुछ भी नहीं करता है, यह केवल नए लेबल परिभाषा को अनदेखा करता है और पुराने का उपयोग करता है। शायद यही समस्या है, जिसके कारण सब कुछ गलत हो सकता है। बहुत कम से कम, सिस्टम को कहना होगा: "मैं इस एप्लिकेशन को स्थापित करने से इनकार करता हूं क्योंकि इसमें एक लेबल परिभाषा है जो पहले से मौजूद है।"
छात्र: ... और किसी अन्य एप्लिकेशन से संबंधित है।
प्रोफेसर: हाँ, और यहां तक कि दूसरी कुंजी से संबंधित हो सकता है। फिर कम से कम संभावित रूप से सब कुछ ठीक करने का मौका है। मैंने इस समस्या को ट्रैक नहीं किया है, शायद यह पहले से ही तय हो गया है। किसी भी मामले में, यह एक दिलचस्प समस्या है, जब आपको वास्तव में इन नामों पर नज़र रखना है और यह पता लगाना है कि इस नाम का मालिक कौन है, और ऐसे कार्यों को करने का अधिकार प्राप्त करना वास्तव में बहुत महत्वपूर्ण है।
एक और दिलचस्प एंड्रॉइड मुद्दा ब्रॉडकास्ट रिसीवर या प्रसारण संदेशों के रिसीवर से संबंधित है। यह अन्य अनुप्रयोगों के संदेशों को प्राप्त करने और प्रतिक्रिया देने की क्षमता बनाता है, कुछ अनुप्रयोगों को लागू करने जैसे संदेश भेजना। पहले मुझे वर्णन करना होगा कि ये संदेश रिसीवर के साथ कैसे बातचीत करते हैं। प्रसारण रिसीवर का उपयोग एक आवेदन के लिए किया जाता है, जो सिस्टम में किसी अन्य अनुप्रयोग के लिए कुछ घटनाओं की घोषणा करने में सक्षम है।
जैसा कि हम जानते हैं, इरादे आमतौर पर एक विशिष्ट घटक को संबोधित करते हैं, उदाहरण के लिए, जेपीईजी छवि दर्शक। लेकिन सिस्टम लोडिंग या "मेरे मित्र आस-पास" जैसी घटनाओं के बारे में, आप हर उस एप्लिकेशन की घोषणा कर सकते हैं जो इसकी चिंता करता है। यह ब्रॉडकास्ट रिसीवर के लिए है।
दो चीजें हैं जो आपको चिंतित करती हैं। सबसे पहले, संदेश के स्रोत का प्रमाणीकरण, यानी आप जानना चाहते हैं कि यह संदेश किसने भेजा है और क्या आप इस पर भरोसा कर सकते हैं। दूसरे, आप यह नियंत्रित करना चाहते हैं कि यह संदेश किसको संबोधित है और इसे कौन प्राप्त कर सकता है।
यह मुझे लगता है कि एंड्रॉइड डेवलपर्स ने इन चीजों को सही तरीके से लागू नहीं किया। किसी भी स्थिति में, एंड्रॉइड के शुरुआती संस्करण में, जब आप सिस्टम के अन्य सभी घटकों को प्रसारण संदेश भेजते हैं, तो ये एप्लिकेशन इस संदेश का समर्थन कर सकते हैं या नहीं भी कर सकते हैं। इसलिए, यदि आपके पास फ्रेंड्स व्यूअर एप्लिकेशन है, तो यह इन्टेंट इंटेंस फ़िल्टर में उपयुक्त घटकों जैसे कि एक्शन या डेट / माइम का उपयोग करके इन संदेशों का समर्थन करेगा। लेकिन अधिकांश एप्लिकेशन हमेशा सिस्टम में सभी प्रसारण घटनाओं का समर्थन कर सकते हैं, और आप फोन पर होने वाली हर चीज को देख सकते हैं, या वह सब कुछ जो प्रसारण होता है।
इस प्रकार, एंड्रॉइड फ्रेमवर्क ने अनुप्रयोगों के लिए एक अतिरिक्त तर्क जोड़ा, जो यह बताता है कि प्रसारण संदेश को देखने में सक्षम कौन है।
, , – , , . , , , , .
, , , , , , . Android, , , , .
, ? , « » , . , ? ?
: ? ?
: , . App 1 RM, , , App 2, , . , App 1 , ? Android ?
, . , , . , . ? , « »?
: , , ?
: . , — . , , « ».
Broadcast receiver, , , . , , , Label.
. Android , . « », . , . , , , .
RPC , RPC-, , . , .
: ?
: , , .
: , …
: , . – . . : « ».
: ?
: .
: , ?
: , , . . , , , . , — . , : « , », , , Dangerous Description.
, : „ , ». , , , , . , Android , .
, , Android. , , . , «», « ». , , .
, , . , , , , , . , Java. , , , , .
Android . - , , , , . «» , RPC . , .
, , . , Android , 5 6 . , , , - «». , , .
, Android , , Apple . , Apple iPhone , .
«», «», , , , , , , . , . , , Android, . , - .
, Android .
.
, . ? ? ,
30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? ( RAID1 RAID10, 24 40GB DDR4).
VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps ,
.
Dell R730xd 2 ? 2 x Intel डोडेका-कोर Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps नीदरलैंड और अमरीका में $ 249 से 100 टीवी ! इन्फ्रास्ट्रक्चर Bldg बनाने के तरीके के बारे में पढ़ें । एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग?