ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release
แทน aosp-main
เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
แซนด์บ็อกซ์แอปพลิเคชัน
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
แพลตฟอร์ม Android ใช้ประโยชน์จากการปกป้องตามผู้ใช้ของ Linux เพื่อระบุและแยกทรัพยากรของแอป ซึ่งจะแยกแอปออกจากกัน และปกป้องแอปและระบบจากแอปที่เป็นอันตราย โดย Android จะกําหนดรหัสผู้ใช้ที่ไม่ซ้ำกัน (UID) ให้กับแอป Android แต่ละแอปและทํางานในแอปนั้นๆ ด้วยกระบวนการของตัวเอง
Android ใช้ UID เพื่อตั้งค่าแซนด์บ็อกซ์ระดับเคอร์เนลของแอปพลิเคชัน แกนหลักจะบังคับใช้ความปลอดภัยระหว่างแอปกับระบบที่ระดับกระบวนการผ่านสิ่งอํานวยความสะดวกมาตรฐานของ Linux เช่น รหัสผู้ใช้และกลุ่มที่กําหนดให้กับแอป โดยค่าเริ่มต้น แอปจะโต้ตอบกันไม่ได้และเข้าถึงระบบปฏิบัติการได้แบบจํากัด หากแอป ก พยายามทำสิ่งที่เป็นอันตราย เช่น อ่านข้อมูลของแอป ข หรือโทรออกโดยไม่ได้รับอนุญาต ระบบจะป้องกันไม่ให้แอปดังกล่าวดำเนินการดังกล่าวเนื่องจากไม่มีสิทธิ์เริ่มต้นที่เหมาะสมของผู้ใช้ Sandbox นั้นใช้งานง่าย ตรวจสอบได้ และอิงตามการแยกกระบวนการและสิทธิ์ของไฟล์ของผู้ใช้สไตล์ UNIX ที่ใช้กันมานานหลายทศวรรษ
เนื่องจากแซนด์บ็อกซ์แอปพลิเคชันอยู่ในเคอร์เนล รูปแบบความปลอดภัยนี้จึงขยายผลไปยังทั้งโค้ดเนทีฟและแอประบบปฏิบัติการ ซอฟต์แวร์ทั้งหมดที่อยู่เหนือเคอร์เนล เช่น ไลบรารีระบบปฏิบัติการ เฟรมเวิร์กแอป รันไทม์ของแอป และแอปทั้งหมดจะทำงานภายในแซนด์บ็อกซ์แอปพลิเคชัน ในบางแพลตฟอร์ม นักพัฒนาซอฟต์แวร์ต้องจำกัดตัวเองให้ใช้เฟรมเวิร์กการพัฒนา ชุด API หรือภาษาที่เจาะจง ใน Android ไม่มีข้อจำกัดเกี่ยวกับวิธีเขียนแอปที่จำเป็นต่อการบังคับใช้ความปลอดภัย ในแง่นี้ โค้ดเนทีฟจะอยู่ในแซนด์บ็อกซ์เช่นเดียวกับโค้ดที่ตีความ
การป้องกัน
โดยทั่วไปแล้ว หากต้องการออกจากแซนด์บ็อกซ์แอปพลิเคชันในอุปกรณ์ที่กําหนดค่าอย่างถูกต้อง ผู้ใช้จะต้องประนีประนอมความปลอดภัยของเคอร์เนล Linux อย่างไรก็ตาม การป้องกันแต่ละรายการที่บังคับใช้แซนด์บ็อกซ์ของแอปก็ไม่สามารถป้องกันได้ทั้งหมด เช่นเดียวกับฟีเจอร์ด้านความปลอดภัยอื่นๆ ดังนั้นการป้องกันแบบหลายชั้นจึงมีความสำคัญเพื่อป้องกันไม่ให้ช่องโหว่เดียวนำไปสู่การประนีประนอมระบบปฏิบัติการหรือแอปอื่นๆ
Android ใช้การป้องกันหลายอย่างเพื่อบังคับใช้แซนด์บ็อกซ์ของแอป เราเริ่มใช้การบังคับใช้เหล่านี้เมื่อเวลาผ่านไป และทำให้แซนด์บ็อกซ์การควบคุมการเข้าถึงแบบมีสิทธิ์ (DAC) เดิมตาม UID มีประสิทธิภาพมากขึ้นอย่างมาก Android เวอร์ชันก่อนหน้ามีการป้องกันต่อไปนี้
- ใน Android 5.0 SELinux ได้แยกการควบคุมการเข้าถึงแบบบังคับ (MAC) ระหว่างระบบกับแอป อย่างไรก็ตาม แอปของบุคคลที่สามทั้งหมดจะทำงานภายในบริบท SELinux เดียวกัน ดังนั้นการแยกระหว่างแอปจึงบังคับใช้โดย UID DAC เป็นหลัก
- ใน Android 6.0 เราได้ขยายแซนด์บ็อกซ์ SELinux เพื่อแยกแอปตามขอบเขตผู้ใช้จริง นอกจากนี้ Android ยังตั้งค่าเริ่มต้นที่ปลอดภัยยิ่งขึ้นสำหรับข้อมูลแอปด้วย โดยสำหรับแอปที่มี
targetSdkVersion >= 24
สิทธิ์ DAC เริ่มต้นในไดเรกทอรีหลักของแอปจะเปลี่ยนจาก 751 เป็น 700 ซึ่งทำให้ข้อมูลแอปส่วนตัวมีค่าเริ่มต้นที่ปลอดภัยยิ่งขึ้น (แม้ว่าแอปจะลบล้างค่าเริ่มต้นเหล่านี้ได้ก็ตาม)
- ใน Android 8.0 แอปทั้งหมดได้รับการตั้งค่าให้ทำงานด้วย
seccomp-bpf
- ใน Android 9 แอปที่ไม่มีสิทธิ์ทั้งหมดที่มี
targetSdkVersion >=
28
ต้องทำงานในแซนด์บ็อกซ์ SELinux แต่ละรายการ โดยระบุ MAC ตามแอป การปกป้องนี้ช่วยปรับปรุงการแยกแอป ป้องกันการลบล้างค่าเริ่มต้นที่ปลอดภัย และที่สำคัญที่สุดคือป้องกันไม่ให้แอปทำให้ข้อมูลเข้าถึงได้ทั่วโลก
- ใน Android 10 แอปจะมีมุมมองไฟล์ระบบแบบไฟล์ดิบแบบจำกัด โดยไม่มีสิทธิ์เข้าถึงเส้นทางโดยตรง เช่น /sdcard/DCIM อย่างไรก็ตาม แอปจะยังคงมีสิทธิ์เข้าถึงแบบไฟล์ดิบอย่างเต็มรูปแบบไปยังเส้นทางเฉพาะแพ็กเกจตามที่แสดงผลโดยเมธอดที่เกี่ยวข้อง เช่น Context.getExternalFilesDir()
หลักเกณฑ์การแชร์ไฟล์
การตั้งค่าข้อมูลแอปให้เข้าถึงได้ทั่วโลกเป็นแนวทางปฏิบัติด้านความปลอดภัยที่ไม่เหมาะสม ระบบจะให้สิทธิ์เข้าถึงแก่ทุกคนและไม่สามารถจำกัดสิทธิ์เข้าถึงเฉพาะผู้รับที่ต้องการได้ แนวทางปฏิบัตินี้ทําให้เกิดการรั่วไหลของข้อมูลและช่องโหว่ของตัวแทนที่ทําให้สับสน และเป็นเป้าหมายที่มัลแวร์ชอบโจมตีแอปที่มีข้อมูลที่ละเอียดอ่อน (เช่น โปรแกรมรับส่งอีเมล) ใน Android 9 ขึ้นไป ระบบจะไม่อนุญาตให้แอปที่มีtargetSdkVersion>=28
แชร์ไฟล์ด้วยวิธีนี้
โปรดใช้หลักเกณฑ์ต่อไปนี้เมื่อแชร์ไฟล์แทนที่จะทำให้ข้อมูลแอปเข้าถึงได้ทั่วโลก
สิทธิ์รันไทม์ Storage จะควบคุมการเข้าถึงคอลเล็กชันที่มีการระบุประเภทอย่างเข้มงวดผ่าน MediaStore
สําหรับการเข้าถึงไฟล์ที่มีการจัดประเภทแบบไม่เข้มงวด เช่น PDF และคลาส MediaStore.Downloads แอปต้องใช้ Intent เช่น Intent ACTION_OPEN_DOCUMENT
หากต้องการเปิดใช้ลักษณะการทํางานของ Android 10 ให้ใช้แอตทริบิวต์ requestLegacyExternalStorage
manifest และทําตามแนวทางปฏิบัติแนะนําเกี่ยวกับสิทธิ์ของแอป
- ค่าเริ่มต้นของ Flag ไฟล์ Manifest คือ
true
สำหรับแอปที่กำหนดเป้าหมายเป็น Android 9 หรือต่ำกว่า
- ค่าเริ่มต้นคือเท็จสําหรับแอปที่กําหนดเป้าหมายเป็น Android 10 หากต้องการเลือกไม่ใช้มุมมองพื้นที่เก็บข้อมูลที่กรองชั่วคราวในแอปที่กำหนดเป้าหมายเป็น Android 10 ให้ตั้งค่า Flag ของไฟล์ Manifest เป็น
true
- เมื่อใช้สิทธิ์ที่จํากัด โปรแกรมติดตั้งจะเพิ่มแอปที่อนุญาตสําหรับพื้นที่เก็บข้อมูลที่ไม่ใช้แซนด์บ็อกซ์ลงในรายการที่อนุญาต ระบบจะจัดเก็บแอปที่ไม่ใช่รายการที่อนุญาตไว้ในแซนด์บ็อกซ์
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา Java และ OpenJDK เป็นเครื่องหมายการค้าหรือเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-07-27 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-27 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."]]