自 2025 年 3 月 27 日起，我們建議您使用 android-latest-release 而非 aosp-main 建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
應用程式安全性最佳做法
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
本節提供建議，協助您確保 Android 裝置上應用程式的安全性。
原始碼審查
原始碼審查可偵測多種安全性問題，包括本文所述的安全性問題。Android 強烈建議您同時進行手動和自動化原始碼審查。
- 進行審查時，請遵循全面的安全指南，確保涵蓋所有範圍。使用相關的內部或外部標準，確保審查作業一致且完整。
- 針對使用 Android SDK 的所有應用程式程式碼執行 Lint 工具 (例如 Android Studio Lint 工具)，並修正任何已識別的問題。
- 使用可偵測記憶體管理問題 (例如緩衝區溢位和 off-by-one 錯誤) 的自動化工具分析原生程式碼。
- Android 建構系統支援許多 LLVM Sanitizer，例如 AddressSanitizer 和 UndefinedBehaviorSanitizer，可用於分析記憶體相關問題的執行階段。結合模糊測試 (Android 透過 libFuzzer 提供支援)，淨化器可找出需要進一步調查的異常邊緣案例。
- 具備專業知識的安全評估人員應審查風險較高的程式碼，例如加密、付款處理和 PII 處理。
自動化測試
自動化測試可協助偵測各種安全性問題，因此應定期執行。
- 在整個開發過程中，請定期執行最新版本的 CTS，以便及早偵測問題，縮短修正時間。Android 會在自動化建構程序中使用 CTS 做為持續整合的一部分，每天執行多次建構作業。
- 自動執行介面的安全性測試，包括使用格式錯誤的輸入內容進行測試 (模糊測試)。Android 的建構系統支援 libFuzzer，可用於編寫模糊測試。
安全漏洞掃描
安全漏洞掃描可確保預先安裝的應用程式沒有已知的安全漏洞。先進偵測功能可縮短解決這些安全漏洞所需的時間和成本，並防止使用者和裝置面臨風險。
- 使用業界認可的應用程式安全漏洞掃描工具掃描所有預先安裝的應用程式，並解決所偵測到的安全漏洞。
可能有害的應用程式
請務必確認裝置上預先安裝的應用程式不是潛在有害應用程式 (PHA)。您必須對裝置上所有應用程式的行為負責。在裝置推出前，掃描所有預先載入的應用程式，找出安全漏洞。
如要進一步瞭解 PHA 以及 Google 如何在 Play 商店中對抗 PHA，請參閱 Google Play 安全防護開發人員說明文件。
應用程式安裝和權限
預先安裝的應用程式擁有過多權限可能會造成安全風險。請將預先安裝的應用程式限制為最低必要權限，並確保這些應用程式無法存取不必要的權限或特權。應用程式權限會在 AndroidManifest.xml 中說明。
- 請勿向預先安裝的應用程式授予不必要的權限或特權。請仔細檢查具有系統權限的應用程式，因為這些應用程式可能具有非常敏感的權限。
- 請確認要求的所有權限與該特定應用程式的功能相關，且必要。
- 請務必為所有使用
INSTALL_PACKAGES 權限的預先安裝應用程式提供使用者揭露事項。
- 請確認開發人員在合約中同意不得以 UID 0 安裝任何應用程式。
- 評估所有應用程式在資訊清單中宣告的權限，這些應用程式會透過開發人員的網路安裝。
- 請確認開發人員在將應用程式提供給裝置前，必須依合約規定使用 Google Safe Browsing API 掃描自動更新器和安裝程式應用程式的所有下載網址。
應用程式簽署
應用程式簽名在裝置安全性方面扮演重要角色，用於權限檢查和軟體更新。在選擇用於簽署應用程式的金鑰時，請務必考量應用程式是否只適用於單一裝置，或是適用於多個裝置。
- 請確認應用程式並未使用公開金鑰 (例如 AOSP 開發人員金鑰) 進行簽署。
- 請務必按照業界標準處理機密金鑰的做法，管理用於簽署應用程式的金鑰，包括提供可稽核的有限存取權的硬體安全性模組 (HSM)。
- 請確認應用程式並未使用平台金鑰簽署。這樣做會讓應用程式存取平台簽章權限，這些權限功能強大，且僅供作業系統元件使用。系統應用程式應使用特權權限。
- 請確認使用相同套件名稱的應用程式並未使用不同的金鑰簽署。這通常會發生在為不同裝置建立應用程式時，尤其是使用平台金鑰時。如果應用程式不受裝置限制，請在不同裝置上使用相同的金鑰。如果應用程式是裝置專屬，請為每個裝置和金鑰建立專屬的套件名稱。
隔離應用程式和程序
在正確使用情況下，Android 沙箱模型可為應用程式和程序提供額外安全防護。
隔離根程序
根程序是權限提升攻擊最常鎖定的目標，因此減少根程序的數量，就能降低權限提升的風險。
- 請確認裝置以 root 權限執行必要的最低程式碼。請盡量使用一般 Android 程序，而非根程序。如果程序必須在裝置上以 root 權限執行，請在 AOSP 功能要求中記錄程序，以便公開審查。
- 請盡可能將根碼與不受信任的資料隔離，並透過進程間通訊 (IPC) 存取。舉例來說，您可以將根功能縮減為可透過 Binder 存取的小型服務，並將具有簽名權限的服務公開給權限較低或沒有權限的應用程式，以便處理網路流量。
- 根程序不得監聽網路通訊端。
- 根程序不得包含通用的執行階段，例如 Java VM。
隔離系統應用程式
一般來說，預先安裝的應用程式不應使用共用的系統專屬 ID (UID) 執行。如果應用程式需要使用系統的共用 UID 或其他特權服務 (例如電話)，則不應匯出任何服務、廣播接收器或內容提供者，以免使用者安裝的第三方應用程式可存取這些服務。
- 確保裝置以系統模式執行必要的最低程式碼。盡可能使用具有自身 UID 的 Android 程序，而非重複使用系統 UID。
- 在可行情況下，系統程式碼應與不受信任的資料隔離，並只將 IPC 公開給其他受信任的程序。
- 系統程序不得監聽網路通訊端。這是 CTS 規定。
隔離程序
Android 應用程式沙箱可讓應用程式與系統上的其他程序 (包括根層級程序和偵錯工具) 隔離。除非應用程式和使用者明確啟用偵錯功能，否則任何應用程式都不應違反這項預期。
- 請確認根程序不會存取個別應用程式資料資料夾中的資料，除非您使用已記錄的 Android 偵錯方法。
- 請確保根程序不會存取應用程式的記憶體，除非使用已記錄的 Android 偵錯方法。
- 請確認裝置不包含任何會存取其他應用程式或程序資料或記憶體的應用程式。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間：2025-07-27 (世界標準時間)。
[[["容易理解","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 (世界標準時間)。"],[],[],null,["# App security best practices\n\nThis section contains recommendations to ensure the security of apps on\nAndroid devices.\n\nSource code review\n------------------\n\nSource code review can detect a broad range of security issues, including\nthose identified in this document. Android strongly encourages both manual\nand automated source code review.\n\n- Follow comprehensive security guidance when conducting reviews to ensure coverage. Utilize relevant internal or external standards to ensure consistent and complete reviews.\n- Run a linter, such as the [Android Studio linter](https://developer.android.com/studio/write/lint), on all app code using the Android SDK and correct any identified issues.\n- Analyze native code using an automated tool that can detect memory management issues, such as buffer overflows and off-by-one errors.\n- The Android build system supports many of the LLVM sanitizers, such as [AddressSanitizer](/docs/security/test/asan) and [UndefinedBehaviorSanitizer](/docs/security/test/sanitizers#undefinedbehaviorsanitizer), which can be used for runtime analysis of memory-related issues. Combined with fuzzing, supported in Android through [libFuzzer](/docs/security/test/libfuzzer), sanitizers can uncover unusual edge cases requiring further investigation.\n- A knowledgeable security assessor should review higher risk code, such as crypto, payment processing, and PII processing.\n\nAutomated testing\n-----------------\n\nAutomated testing can help detect a broad range of security issues and\nshould be performed regularly.\n\n- Run the latest version of [CTS](/docs/compatibility/cts) regularly throughout the development process to detect problems early and reduce time to correction. Android uses CTS as part of continuous integration in our automated build process, which builds multiple times per day.\n- Automate security testing of interfaces, including testing with malformed inputs (fuzz testing). Android's build system supports [libFuzzer](/docs/security/test/libfuzzer) for writing fuzz tests.\n\nVulnerability scanning\n----------------------\n\nVulnerability scanning can help ensure that pre-installed apps are free of\nknown security vulnerabilities. Advanced detection can reduce the time and\ncost required with addressing these vulnerabilities and preventing risk to\nusers and devices.\n\n- Scan all pre-installed apps using an industry-recognized app vulnerability scanning tool and address detected vulnerabilities.\n\nPotentially Harmful Applications\n--------------------------------\n\nIt is important to ensure that the pre-installed apps on your device aren't\n[Potentially\nHarmful Applications](https://developers.google.com/android/play-protect/phacategories) (PHAs). You are responsible for the behavior of all\napps that are included on your devices. Prior to device launch, scan all\npre-loaded apps for vulnerabilities.\n\nFor more information about PHAs and how Google is combating them in the\nPlay store see the [Google Play Protect\ndeveloper documentation](https://developers.google.com/android/play-protect/).\n\nApp installation and permissions\n--------------------------------\n\nExcessive permissions for pre-installed apps can create a security risk.\nRestrict pre-installed apps to the minimum necessary permissions and ensure they\ndon't have access to unnecessary permissions or privileges. App permissions are\ndescribed in the [AndroidManifest.xml](https://android.googlesource.com/platform/frameworks/base/+/refs/heads/android16-release/core/res/AndroidManifest.xml).\n\n- Don't grant unnecessary permissions or privileges to pre-installed apps. Thoroughly review apps with system privileges as they can have very sensitive permissions.\n- Ensure that all permissions requested are relevant and necessary for the functionality of that specific app.\n- Ensure there is user disclosure for all pre-installed apps that use the `INSTALL_PACKAGES` permission.\n- Ensure that the developer is contractually obligated not to install any apps as UID 0.\n- Evaluate permissions declared in the manifest of all apps to be installed through the developer's network.\n- Ensure that the developer is contractually obligated to scan all download URLs of auto-updater and installer apps with [Google Safe Browsing API](https://developers.google.com/safe-browsing/) before serving apps to the device.\n\nApp signing\n-----------\n\nApp signatures play an important role in device security and are used for\npermissions checks and software updates. When selecting a key to use for\nsigning apps, it is important to consider whether an app is available\nonly on a single device or common across multiple devices.\n\n- Ensure that apps aren't signed with a key that is publicly known, such as the AOSP developer key.\n- Ensure that keys used to sign apps are managed in a manner consistent with industry-standard practices for handling sensitive keys, including an hardware security module (HSM) that provides limited, auditable access.\n- Ensure that apps aren't signed with the platform key. Doing so gives an app access to platform signature permissions, which are very powerful and only intended to be used by components of the operating system. System apps should use privileged permissions.\n- Ensure that apps with the same package name aren't signed with different keys. This often occurs when creating an app for different devices, especially when using the platform key. If the app is device-independent, use the same key across devices. If the app is device-specific, create unique package names per device and key.\n\nIsolate apps and processes\n--------------------------\n\nThe Android [sandboxing model](/docs/security/app-sandbox)\nprovides extra security around apps and processes when used correctly.\n\n### Isolate root processes\n\nRoot processes are the most frequent target of privilege escalation attacks;\nreducing the number of root processes reduces risk of privilege escalation.\n\n- Ensure that devices run the minimum necessary code as root. Where possible, use a regular Android process rather than a root process. If a process must run as root on a device, document the process in an AOSP feature request so it can be publicly reviewed.\n- Where possible, root code should be isolated from untrusted data and accessed through interprocess communication (IPC). For example, reduce root functionality to a small service accessible through Binder and expose the service with signature permission to an app with low or no privileges to handle network traffic.\n- Root processes must not listen on a network socket.\n- Root processes must not include a general-purpose runtime, such as a Java VM.\n\n### Isolate system apps\n\nIn general, pre-installed apps shouldn't run with the shared system unique\nidentifier (UID). If it is necessary for an app to use the shared UID of\nsystem or another privileged service (e.g., phone), the app shouldn't export\nany services, broadcast receivers, or content providers that can be accessed\nby third-party apps installed by users.\n\n- Ensure devices run the minimum necessary code as system. Where possible, use an Android process with its own UID rather than reusing the system UID.\n- Where possible, system code should be isolated from untrusted data and expose IPC only to other trusted processes.\n- System processes must not listen on a network socket. This is a CTS requirement.\n\n### Isolate processes\n\nThe Android Application Sandbox provides apps with an expectation of\nisolation from other processes on the system, including root processes and\ndebuggers. Unless debugging is specifically enabled by the app and the user,\nno app should violate that expectation.\n\n- Ensure root processes don't access data within individual app data folders, unless using a documented Android debugging method.\n- Ensure root processes don't access memory of apps, unless using a documented Android debugging method.\n- Ensure devices don't include any app that accesses data or memory of other apps or processes."]]
