27 মার্চ, 2025 থেকে, আমরা AOSP তৈরি করতে এবং অবদান রাখতে aosp-main
এর পরিবর্তে android-latest-release
ব্যবহার করার পরামর্শ দিচ্ছি। আরও তথ্যের জন্য, AOSP-তে পরিবর্তনগুলি দেখুন।
অ্যাপ্লিকেশন স্যান্ডবক্স
সেভ করা পৃষ্ঠা গুছিয়ে রাখতে 'সংগ্রহ' ব্যবহার করুন
আপনার পছন্দ অনুযায়ী কন্টেন্ট সেভ করুন ও সঠিক বিভাগে রাখুন।
অ্যান্ড্রয়েড প্ল্যাটফর্ম অ্যাপ সংস্থানগুলি সনাক্ত করতে এবং বিচ্ছিন্ন করতে Linux ব্যবহারকারী-ভিত্তিক সুরক্ষার সুবিধা নেয়। এটি একে অপরের থেকে অ্যাপগুলিকে বিচ্ছিন্ন করে এবং অ্যাপ এবং সিস্টেমকে ক্ষতিকারক অ্যাপ থেকে রক্ষা করে। এটি করার জন্য, অ্যান্ড্রয়েড প্রতিটি অ্যান্ড্রয়েড অ্যাপকে একটি অনন্য ব্যবহারকারী আইডি (ইউআইডি) বরাদ্দ করে এবং এটি নিজস্ব প্রক্রিয়ায় চালায়।
একটি কার্নেল-স্তরের অ্যাপ্লিকেশন স্যান্ডবক্স সেট আপ করতে Android UID ব্যবহার করে। কার্নেল প্রসেস লেভেলে অ্যাপ্লিকেশান এবং সিস্টেমের মধ্যে সিকিউরিটি এনফোর্স করে স্ট্যান্ডার্ড লিনাক্স সুবিধার মাধ্যমে যেমন ইউজার এবং গ্রুপ আইডি যেগুলি অ্যাপগুলিতে বরাদ্দ করা হয়। ডিফল্টরূপে, অ্যাপগুলি একে অপরের সাথে ইন্টারঅ্যাক্ট করতে পারে না এবং OS এ সীমিত অ্যাক্সেস থাকতে পারে। যদি অ্যাপ A দূষিত কিছু করার চেষ্টা করে, যেমন অ্যাপ B-এর ডেটা পড়া বা অনুমতি ছাড়াই ফোন ডায়াল করা, তাহলে এটি করা থেকে বিরত থাকে কারণ এটির যথাযথ ডিফল্ট ব্যবহারকারীর অধিকার নেই৷ স্যান্ডবক্সটি সহজ, নিরীক্ষাযোগ্য এবং কয়েক দশক-পুরাতন ইউনিক্স-স্টাইল ব্যবহারকারীর প্রক্রিয়া এবং ফাইলের অনুমতিগুলির পৃথকীকরণের উপর ভিত্তি করে।
অ্যাপ্লিকেশন স্যান্ডবক্স কার্নেলে থাকার কারণে, এই নিরাপত্তা মডেলটি নেটিভ কোড এবং OS অ্যাপ উভয়েই প্রসারিত। কার্নেলের উপরের সমস্ত সফ্টওয়্যার, যেমন OS লাইব্রেরি, অ্যাপ ফ্রেমওয়ার্ক, অ্যাপ রানটাইম এবং সমস্ত অ্যাপ, অ্যাপ্লিকেশন স্যান্ডবক্সের মধ্যে চলে। কিছু প্ল্যাটফর্মে, ডেভেলপাররা একটি নির্দিষ্ট ডেভেলপমেন্ট ফ্রেমওয়ার্ক, এপিআই-এর সেট বা ভাষাতে সীমাবদ্ধ থাকে। অ্যান্ড্রয়েডে, নিরাপত্তা জোরদার করার জন্য প্রয়োজনীয় একটি অ্যাপ কীভাবে লেখা যাবে তার উপর কোনো বিধিনিষেধ নেই; এই ক্ষেত্রে, নেটিভ কোডটি ব্যাখ্যা করা কোডের মতো স্যান্ডবক্সযুক্ত।
সুরক্ষা
সাধারণত, সঠিকভাবে কনফিগার করা ডিভাইসে অ্যাপ্লিকেশন স্যান্ডবক্স থেকে বেরিয়ে আসতে, একজনকে অবশ্যই লিনাক্স কার্নেলের নিরাপত্তার সাথে আপস করতে হবে। যাইহোক, অন্যান্য নিরাপত্তা বৈশিষ্ট্যের মতো, অ্যাপ স্যান্ডবক্স প্রয়োগকারী স্বতন্ত্র সুরক্ষাগুলি অরক্ষিত নয়, তাই OS বা অন্যান্য অ্যাপগুলির আপস থেকে একক দুর্বলতাগুলি প্রতিরোধ করার জন্য প্রতিরক্ষা-ইন-ডেপ্থ গুরুত্বপূর্ণ।
অ্যাপ্লিকেশান স্যান্ডবক্স প্রয়োগ করতে Android অনেকগুলি সুরক্ষার উপর নির্ভর করে৷ এই প্রয়োগগুলি সময়ের সাথে সাথে চালু করা হয়েছে এবং মূল UID-ভিত্তিক ডিসক্রিশনারি অ্যাক্সেস কন্ট্রোল (DAC) স্যান্ডবক্সকে উল্লেখযোগ্যভাবে শক্তিশালী করেছে। পূর্ববর্তী অ্যান্ড্রয়েড রিলিজে নিম্নলিখিত সুরক্ষাগুলি অন্তর্ভুক্ত ছিল:
- অ্যান্ড্রয়েড 5.0-এ, SELinux সিস্টেম এবং অ্যাপের মধ্যে বাধ্যতামূলক অ্যাক্সেস কন্ট্রোল (MAC) বিচ্ছেদ প্রদান করেছে। যাইহোক, সমস্ত তৃতীয় পক্ষের অ্যাপ একই SELinux প্রসঙ্গে চলে তাই ইন্টার-অ্যাপ আইসোলেশন প্রাথমিকভাবে UID DAC দ্বারা প্রয়োগ করা হয়েছিল।
- অ্যান্ড্রয়েড 6.0-এ, SELinux স্যান্ডবক্স প্রতি-ভৌত-ব্যবহারকারীর সীমানা জুড়ে অ্যাপগুলিকে বিচ্ছিন্ন করার জন্য প্রসারিত করা হয়েছিল। এছাড়াও, অ্যান্ড্রয়েড অ্যাপ ডেটার জন্য আরও নিরাপদ ডিফল্ট সেট করে:
targetSdkVersion >= 24
সহ অ্যাপগুলির জন্য, একটি অ্যাপের হোম ডির-এ ডিফল্ট DAC অনুমতি 751 থেকে 700 এ পরিবর্তিত হয়েছে। এটি ব্যক্তিগত অ্যাপ ডেটার জন্য নিরাপদ ডিফল্ট প্রদান করেছে (যদিও অ্যাপগুলি এই ডিফল্টগুলিকে ওভাররাইড করতে পারে)। - অ্যান্ড্রয়েড 8.0-এ, সমস্ত অ্যাপ একটি
seccomp-bpf
ফিল্টার দিয়ে চালানোর জন্য সেট করা হয়েছিল যা অ্যাপগুলিকে ব্যবহার করার অনুমতি দেওয়া syscalls সীমিত করে, এইভাবে অ্যাপ/কার্নেল সীমানাকে শক্তিশালী করে। - Android 9-এ
targetSdkVersion >= 28
সহ সমস্ত অ-সুবিধাপ্রাপ্ত অ্যাপগুলিকে অবশ্যই পৃথক SELinux স্যান্ডবক্সে চলতে হবে, প্রতি-অ্যাপের ভিত্তিতে MAC প্রদান করে। এই সুরক্ষা অ্যাপ বিচ্ছেদ উন্নত করে, নিরাপদ ডিফল্ট ওভাররাইডিং প্রতিরোধ করে এবং (সবচেয়ে উল্লেখযোগ্যভাবে) অ্যাপগুলিকে তাদের ডেটা বিশ্ব অ্যাক্সেসযোগ্য করতে বাধা দেয়। - অ্যান্ড্রয়েড 10 অ্যাপে /sdcard/DCIM-এর মতো পাথগুলিতে সরাসরি অ্যাক্সেস ছাড়াই ফাইল সিস্টেমের একটি সীমিত কাঁচা দৃশ্য রয়েছে। যাইহোক, অ্যাপ্লিকেশানগুলি তাদের প্যাকেজ-নির্দিষ্ট পাথগুলিতে সম্পূর্ণ অপ্রচলিত অ্যাক্সেস বজায় রাখে, যেমন Context.getExternalFilesDir() প্রযোজ্য পদ্ধতি দ্বারা ফিরে আসে।
ফাইল শেয়ার করার জন্য নির্দেশিকা
বিশ্বের অ্যাক্সেসযোগ্য হিসাবে অ্যাপ ডেটা সেট করা একটি দুর্বল নিরাপত্তা অনুশীলন। অ্যাক্সেস প্রত্যেকের জন্য মঞ্জুর করা হয়েছে এবং শুধুমাত্র অভিপ্রেত প্রাপক(দের) অ্যাক্সেস সীমাবদ্ধ করা সম্ভব নয়। এই অনুশীলনটি তথ্য প্রকাশের ফাঁস এবং বিভ্রান্ত ডেপুটি দুর্বলতার দিকে পরিচালিত করেছে এবং এটি ম্যালওয়্যারের জন্য একটি প্রিয় লক্ষ্য যা সংবেদনশীল ডেটা (যেমন ইমেল ক্লায়েন্ট) সহ অ্যাপগুলিকে লক্ষ্য করে। Android 9 এবং উচ্চতর সংস্করণে, targetSdkVersion>=28
সহ অ্যাপগুলির জন্য এইভাবে ফাইলগুলি ভাগ করা স্পষ্টভাবে অনুমোদিত নয়।
অ্যাপ ডেটা বিশ্ব-অ্যাক্সেসযোগ্য করার পরিবর্তে, ফাইলগুলি ভাগ করার সময় নিম্নলিখিত নির্দেশিকাগুলি ব্যবহার করুন:
- আপনার অ্যাপকে অন্য অ্যাপের সাথে ফাইল শেয়ার করার প্রয়োজন হলে, একটি বিষয়বস্তু প্রদানকারী ব্যবহার করুন। বিষয়বস্তু প্রদানকারীরা সঠিক কণিকা সহ এবং বিশ্ব-অভিগম্য UNIX অনুমতিগুলির অনেকগুলি ডাউনসাইড ছাড়াই ডেটা ভাগ করে (বিশদ বিবরণের জন্য, বিষয়বস্তু প্রদানকারীর মৌলিক বিষয়গুলি পড়ুন)।
- যদি আপনার অ্যাপে এমন ফাইল থাকে যা সত্যিকার অর্থে বিশ্বের কাছে অ্যাক্সেসযোগ্য হওয়া উচিত (যেমন ফটো), সেগুলি অবশ্যই মিডিয়া-নির্দিষ্ট হতে হবে (শুধুমাত্র ফটো, ভিডিও এবং অডিও ফাইল) এবং মিডিয়াস্টোর ক্লাস ব্যবহার করে সংরক্ষণ করা উচিত। (কীভাবে একটি মিডিয়া আইটেম যুক্ত করবেন সে সম্পর্কে আরও বিশদ বিবরণের জন্য, শেয়ার্ড স্টোরেজ থেকে মিডিয়া ফাইল অ্যাক্সেস করুন দেখুন।)
স্টোরেজ রানটাইম অনুমতি মিডিয়াস্টোরের মাধ্যমে দৃঢ়ভাবে টাইপ করা সংগ্রহগুলিতে অ্যাক্সেস নিয়ন্ত্রণ করে। PDF এবং MediaStore.Downloads ক্লাসের মতো দুর্বলভাবে টাইপ করা ফাইলগুলি অ্যাক্সেস করার জন্য, অ্যাপগুলিকে অবশ্যই ACTION_OPEN_DOCUMENT
ইন্টেন্টের মতো ইন্টেন্ট ব্যবহার করতে হবে৷
Android 10 আচরণ সক্ষম করতে, requestLegacyExternalStorage
ম্যানিফেস্ট অ্যাট্রিবিউট ব্যবহার করুন এবং অ্যাপ অনুমতির সর্বোত্তম অনুশীলনগুলি অনুসরণ করুন।
- ম্যানিফেস্ট ফ্ল্যাগ ডিফল্ট মানটি Android 9 এবং তার নিচের দিকে লক্ষ্য করা অ্যাপগুলির জন্য
true
। - অ্যান্ড্রয়েড 10 টার্গেট করা অ্যাপ্লিকেশানগুলির জন্য ডিফল্ট মানটি মিথ্যা৷ Android 10 টার্গেট করা অ্যাপ্লিকেশানগুলিতে অস্থায়ীভাবে ফিল্টার করা স্টোরেজ ভিউ থেকে অপ্ট আউট করতে, ম্যানিফেস্ট পতাকার মানটিকে
true
সেট করুন৷ - সীমাবদ্ধ অনুমতি ব্যবহার করে, ইনস্টলার ননস্যান্ডবক্সড স্টোরেজের জন্য অনুমোদিত অ্যাপগুলিকে অনুমতি দেয়৷ অননুমোদিত অ্যাপস স্যান্ডবক্স করা হয়.
এই পৃষ্ঠার কন্টেন্ট ও কোডের নমুনাগুলি Content License-এ বর্ণিত লাইসেন্সের অধীনস্থ। Java এবং OpenJDK হল Oracle এবং/অথবা তার অ্যাফিলিয়েট সংস্থার রেজিস্টার্ড ট্রেডমার্ক।
2025-07-29 UTC-তে শেষবার আপডেট করা হয়েছে।
[[["সহজে বোঝা যায়","easyToUnderstand","thumb-up"],["আমার সমস্যার সমাধান হয়েছে","solvedMyProblem","thumb-up"],["অন্যান্য","otherUp","thumb-up"]],[["এতে আমার প্রয়োজনীয় তথ্য নেই","missingTheInformationINeed","thumb-down"],["খুব জটিল / অনেক ধাপ","tooComplicatedTooManySteps","thumb-down"],["পুরনো","outOfDate","thumb-down"],["অনুবাদ সংক্রান্ত সমস্যা","translationIssue","thumb-down"],["নমুনা / কোড সংক্রান্ত সমস্যা","samplesCodeIssue","thumb-down"],["অন্যান্য","otherDown","thumb-down"]],["2025-07-29 UTC-তে শেষবার আপডেট করা হয়েছে।"],[],[],null,["# Application Sandbox\n\nThe Android platform takes advantage of the Linux user-based protection to\nidentify and isolate app resources. This isolates apps from each other and\nprotects apps and the system from malicious apps. To do this, Android assigns a\nunique user ID (UID) to each Android app and runs it in its own\nprocess.\n\nAndroid uses the UID to set up a kernel-level Application Sandbox. The\nkernel enforces security between apps and the system at the process level\nthrough standard Linux facilities such as user and group IDs that are assigned\nto apps. By default, apps can't interact with each other and have limited\naccess to the OS. If app A tries to do something malicious, such as read\napp B's data or dial the phone without permission, it's prevented from\ndoing so because it doesn't have the appropriate default user privileges. The\nsandbox is simple, auditable, and based on decades-old UNIX-style user\nseparation of processes and file permissions.\n\nBecause the Application Sandbox is in the kernel, this security model\nextends to both native code and OS apps. All of the software above the\nkernel, such as OS libraries, app framework, app runtime, and\nall apps, run within the Application Sandbox. On some platforms,\ndevelopers are constrained to a specific development framework, set of APIs, or\nlanguage. On Android, there are no restrictions on how an app can be\nwritten that are required to enforce security; in this respect, native code is\nas sandboxed as interpreted code.\n\nProtections\n-----------\n\n\nGenerally, to break out of the Application Sandbox in a properly configured\ndevice, one must compromise the security of the Linux kernel. However, similar\nto other security features, individual protections enforcing the app\nsandbox are not invulnerable, so defense-in-depth is important to prevent\nsingle vulnerabilities from leading to compromise of the OS or other apps.\n\n\nAndroid relies on a number of protections to enforce the app\nsandbox. These enforcements have been introduced over time and have\nsignificantly strengthened the original UID-based discretionary access control\n(DAC) sandbox. Previous Android releases included the following\nprotections:\n\n- In Android 5.0, SELinux provided mandatory access control (MAC) separation between the system and apps. However, all third-party apps ran within the same SELinux context so inter-app isolation was primarily enforced by UID DAC.\n- In Android 6.0, the SELinux sandbox was extended to isolate apps across the per-physical-user boundary. In addition, Android also set safer defaults for app data: For apps with `targetSdkVersion \u003e= 24`, default DAC permissions on an app's home dir changed from 751 to 700. This provided safer default for private app data (although apps can override these defaults).\n- In Android 8.0, all apps were set to run with a `seccomp-bpf` filter that limited the syscalls that apps were allowed to use, thus strengthening the app/kernel boundary.\n- In Android 9 all nonprivileged apps with `targetSdkVersion \u003e=\n 28` must run in individual SELinux sandboxes, providing MAC on a per-app basis. This protection improves app separation, prevents overriding safe defaults, and (most significantly) prevents apps from making their data world accessible.\n- In Android 10 apps have a limited raw view of the filesystem, with no direct access to paths like /sdcard/DCIM. However, apps retain full raw access to their package-specific paths, as returned by any applicable methods, such as [Context.getExternalFilesDir()](https://developer.android.com/reference/android/content/Context.html#getExternalFilesDir(jav%20a.lang.String)).\n\nGuidelines for sharing files\n----------------------------\n\nSetting app data as world accessible is a poor security practice. Access\nis granted to everyone and it's not possible to limit access to only the intended\nrecipient(s). This practice has led to information disclosure leaks and confused\ndeputy vulnerabilities, and is a favorite target for malware that targets apps\nwith sensitive data (such as email clients). In Android 9 and higher, sharing\nfiles this way is explicitly disallowed for apps with\n`targetSdkVersion\u003e=28`.\n\n\nInstead of making app data world-accessible, use the following guidelines\nwhen sharing files:\n\n- If your app needs to share files with another app, use a [content provider](https://developer.android.com/guide/topics/providers/content-provider-basics.html). Content providers share data with the proper granularity and without the many downsides of world-accessible UNIX permissions (for details, refer to [Content provider basics](https://developer.android.com/guide/topics/providers/content-provider-basics.html)).\n- If your app has files that genuinely should be accessible to the world (such as photos), they must be media-specific (photos, videos, and audio files only) and stored using the [MediaStore](https://developer.android.com/reference/android/provider/MediaStore) class. (For more details on how to add a media item, see [Access media files from shared storage](https://developer.android.com/training/data-storage/shared/media#add-item).)\n\nThe **Storage** runtime permission controls access\nto strongly-typed collections through **MediaStore** .\nFor accessing weakly typed files such as PDFs and the [MediaStore.Downloads](https://developer.android.com/reference/android/provider/MediaStore.Downloads) class, apps must use\nintents like the [`ACTION_OPEN_DOCUMENT`](https://developer.android.com/reference/android/content/Intent.html#ACTION_OPEN_DOCUMENT) intent.\n\nTo enable Android 10 behavior, use the\n[requestLegacyExternalStorage](https://developer.android.com/training/data-storage/files/external-scoped#opt-out-of-%20filtered-view) manifest\nattribute, and follow [App permissions best practices](https://developer.android.com/training/permissions/usage-notes).\n\n- The manifest flag default value is `true` for apps targeting Android 9 and lower.\n- The default value is false for apps targeting Android 10. To temporarily opt out of the filtered storage view in apps targeting Android 10, set the manifest flag's value to `true`.\n- Using restricted permissions, the installer allowlists apps permitted for nonsandboxed storage. Nonallowlisted apps are sandboxed."]]