از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
بهترین شیوه های امنیت برنامه
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
این بخش حاوی توصیه هایی برای اطمینان از امنیت برنامه ها در دستگاه های Android است.
بررسی کد منبع
بررسی کد منبع می تواند طیف گسترده ای از مسائل امنیتی، از جمله موارد شناسایی شده در این سند را شناسایی کند. اندروید قویاً بازبینی کد منبع دستی و خودکار را تشویق می‌کند.
- هنگام انجام بررسی ها برای اطمینان از پوشش، از راهنمایی های امنیتی جامع پیروی کنید. از استانداردهای داخلی یا خارجی مربوطه برای اطمینان از بررسی های منسجم و کامل استفاده کنید.
- با استفاده از Android SDK، روی همه کدهای برنامه مانند Android Studio linter اجرا کنید و مشکلات شناسایی شده را اصلاح کنید.
- کدهای بومی را با استفاده از یک ابزار خودکار که می تواند مشکلات مدیریت حافظه مانند سرریز بافر و خطاهای یک به یک را شناسایی کند، تجزیه و تحلیل کنید.
- سیستم ساخت اندروید از بسیاری از ضدعفونی‌کننده‌های LLVM مانند AddressSanitizer و UndefinedBehaviorSanitizer پشتیبانی می‌کند که می‌توانند برای تجزیه و تحلیل زمان اجرا مسائل مربوط به حافظه استفاده شوند. همراه با fuzzing که در اندروید از طریق libFuzzer پشتیبانی می‌شود، ضدعفونی‌کننده‌ها می‌توانند موارد لبه‌ای غیرعادی را که نیاز به بررسی بیشتر دارند، کشف کنند.
- یک ارزیاب امنیتی آگاه باید کدهای ریسک بالاتر، مانند رمزنگاری، پردازش پرداخت و پردازش PII را بررسی کند.
تست خودکار
تست خودکار می تواند به شناسایی طیف گسترده ای از مسائل امنیتی کمک کند و باید به طور منظم انجام شود.
- آخرین نسخه CTS را به طور منظم در طول فرآیند توسعه اجرا کنید تا مشکلات را زود تشخیص داده و زمان اصلاح را کاهش دهید. Android از CTS به عنوان بخشی از یکپارچه سازی مداوم در فرآیند ساخت خودکار ما استفاده می کند، که چندین بار در روز ساخته می شود.
- تست امنیتی خودکار رابط ها، از جمله آزمایش با ورودی های نادرست (تست فاز). سیستم ساخت اندروید از libFuzzer برای نوشتن تست های فازی پشتیبانی می کند.
اسکن آسیب پذیری
اسکن آسیب پذیری می تواند به اطمینان حاصل شود که برنامه های از پیش نصب شده عاری از آسیب پذیری های امنیتی شناخته شده هستند. تشخیص پیشرفته می تواند زمان و هزینه مورد نیاز را با رفع این آسیب پذیری ها و جلوگیری از خطرات برای کاربران و دستگاه ها کاهش دهد.
- تمام برنامه های از پیش نصب شده را با استفاده از ابزار اسکن آسیب پذیری برنامه های شناخته شده در صنعت اسکن کنید و آسیب پذیری های شناسایی شده را برطرف کنید.
برنامه های بالقوه مضر
مهم است که مطمئن شوید برنامه های از پیش نصب شده روی دستگاه شما برنامه های بالقوه مضر (PHA) نیستند. شما مسئول رفتار همه برنامه هایی هستید که در دستگاه های شما گنجانده شده است. قبل از راه‌اندازی دستگاه، همه برنامه‌های از پیش بارگذاری شده را برای آسیب‌پذیری اسکن کنید.
برای اطلاعات بیشتر در مورد PHA ها و نحوه مبارزه Google با آنها در فروشگاه Play به مستندات توسعه دهنده Google Play Protect مراجعه کنید.
نصب برنامه و مجوزها
مجوزهای بیش از حد برای برنامه های از پیش نصب شده می تواند یک خطر امنیتی ایجاد کند. برنامه های از پیش نصب شده را به حداقل مجوزهای لازم محدود کنید و اطمینان حاصل کنید که آنها به مجوزها یا امتیازات غیر ضروری دسترسی ندارند. مجوزهای برنامه در AndroidManifest.xml توضیح داده شده است.
- مجوزها یا امتیازات غیر ضروری را به برنامه های از پیش نصب شده اعطا نکنید. برنامه های دارای امتیازات سیستم را به طور کامل بررسی کنید زیرا می توانند مجوزهای بسیار حساسی داشته باشند.
- اطمینان حاصل کنید که تمام مجوزهای درخواستی مرتبط و ضروری برای عملکرد آن برنامه خاص هستند.
- اطمینان حاصل کنید که برای همه برنامه‌های از پیش نصب‌شده‌ای که از مجوز
INSTALL_PACKAGES استفاده می‌کنند، افشای کاربر وجود دارد. - اطمینان حاصل کنید که توسعه‌دهنده طبق قرارداد متعهد است که هیچ برنامه‌ای را به‌عنوان UID 0 نصب نکند.
- مجوزهای اعلام شده در مانیفست همه برنامه‌ها را برای نصب از طریق شبکه توسعه‌دهنده ارزیابی کنید.
- اطمینان حاصل کنید که توسعه‌دهنده طبق قرارداد متعهد است قبل از ارائه برنامه‌ها به دستگاه، همه URLهای دانلود برنامه‌های به‌روزرسانی خودکار و نصب‌کننده را با Google Safe Browsing API اسکن کند.
امضای برنامه
امضای برنامه نقش مهمی در امنیت دستگاه ایفا می کند و برای بررسی مجوزها و به روز رسانی نرم افزار استفاده می شود. هنگام انتخاب کلیدی برای استفاده برای امضای برنامه‌ها، مهم است که در نظر بگیرید که آیا یک برنامه فقط در یک دستگاه در دسترس است یا در چندین دستگاه مشترک است.
- اطمینان حاصل کنید که برنامه‌ها با کلیدی که عموماً شناخته شده است، مانند کلید برنامه‌نویس AOSP، امضا نشده باشند.
- اطمینان حاصل کنید که کلیدهای مورد استفاده برای امضای برنامه‌ها به روشی مطابق با شیوه‌های استاندارد صنعتی برای مدیریت کلیدهای حساس مدیریت می‌شوند، از جمله یک ماژول امنیتی سخت‌افزار (HSM) که دسترسی محدود و قابل بازرسی را فراهم می‌کند.
- مطمئن شوید که برنامه‌ها با کلید پلتفرم امضا نشده‌اند. با انجام این کار، یک برنامه به مجوزهای امضای پلتفرم دسترسی پیدا می کند، که بسیار قدرتمند هستند و فقط برای استفاده توسط اجزای سیستم عامل در نظر گرفته شده است. برنامه های سیستم باید از مجوزهای ممتاز استفاده کنند.
- اطمینان حاصل کنید که برنامه هایی با نام بسته یکسان با کلیدهای مختلف امضا نشده اند. این اغلب هنگام ایجاد یک برنامه برای دستگاه های مختلف رخ می دهد، به خصوص هنگام استفاده از کلید پلت فرم. اگر برنامه مستقل از دستگاه است، از کلید یکسانی در همه دستگاه‌ها استفاده کنید. اگر برنامه مخصوص دستگاه است، نام‌های بسته منحصربه‌فرد برای هر دستگاه و کلید ایجاد کنید.
برنامه ها و فرآیندها را ایزوله کنید
مدل sandboxing اندروید در صورت استفاده صحیح، امنیت بیشتری را در اطراف برنامه‌ها و فرآیندها فراهم می‌کند.
فرآیندهای ریشه را جدا کنید
فرآیندهای ریشه بیشترین هدف حملات افزایش امتیاز هستند. کاهش تعداد فرآیندهای ریشه، خطر افزایش امتیاز را کاهش می دهد.
- اطمینان حاصل کنید که دستگاه ها حداقل کد لازم را به عنوان روت اجرا می کنند. در صورت امکان، به جای پردازش ریشه، از یک فرآیند معمولی اندروید استفاده کنید. اگر فرآیندی باید به‌عنوان روت در دستگاه اجرا شود، فرآیند را در یک درخواست ویژگی AOSP مستند کنید تا بتوان آن را به صورت عمومی بررسی کرد.
- در صورت امکان، کد ریشه باید از داده های نامعتبر جدا شده و از طریق ارتباطات بین پردازشی (IPC) قابل دسترسی باشد. به عنوان مثال، عملکرد ریشه را به یک سرویس کوچک قابل دسترسی از طریق Binder کاهش دهید و سرویس را با مجوز امضا در معرض برنامه‌ای قرار دهید که دارای امتیازات کم یا بدون دسترسی به ترافیک شبکه است.
- فرآیندهای ریشه نباید در سوکت شبکه گوش دهند.
- فرآیندهای ریشه نباید شامل زمان اجرا همه منظوره مانند جاوا VM باشد.
برنامه های سیستم را ایزوله کنید
به طور کلی، برنامه های از پیش نصب شده نباید با شناسه منحصر به فرد سیستم مشترک (UID) اجرا شوند. اگر لازم است یک برنامه از UID مشترک سیستم یا سرویس ممتاز دیگری (به عنوان مثال، تلفن) استفاده کند، برنامه نباید هیچ سرویس، گیرنده پخش یا ارائه دهنده محتوا را صادر کند که توسط برنامه های شخص ثالث نصب شده توسط کاربران قابل دسترسی باشد.
- اطمینان حاصل کنید که دستگاه ها حداقل کد لازم را به عنوان سیستم اجرا می کنند. در صورت امکان، به جای استفاده مجدد از UID سیستم، از یک فرآیند Android با UID خود استفاده کنید.
- در صورت امکان، کد سیستم باید از داده های نامعتبر جدا شده و IPC را فقط در معرض سایر فرآیندهای قابل اعتماد قرار دهد.
- فرآیندهای سیستم نباید در سوکت شبکه گوش دهند. این یک الزام CTS است.
فرآیندها را جدا کنید
Android Application Sandbox برنامه‌ها را با انتظار جدا شدن از سایر فرآیندهای روی سیستم، از جمله فرآیندهای ریشه و اشکال‌زدا، فراهم می‌کند. مگر اینکه اشکال زدایی به طور خاص توسط برنامه و کاربر فعال شده باشد، هیچ برنامه ای نباید آن انتظار را نقض کند.
- اطمینان حاصل کنید که فرآیندهای ریشه به داده‌های داخل پوشه‌های داده برنامه‌های جداگانه دسترسی ندارند، مگر اینکه از روش اشکال‌زدایی مستند Android استفاده کنید.
- اطمینان حاصل کنید که فرآیندهای ریشه به حافظه برنامه‌ها دسترسی ندارند، مگر اینکه از یک روش اشکال‌زدایی مستند Android استفاده کنید.
- مطمئن شوید که دستگاه‌ها هیچ برنامه‌ای را که به داده‌ها یا حافظه برنامه‌ها یا فرآیندهای دیگر دسترسی دارد، نداشته باشند.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین به‌روزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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 بهوقت ساعت هماهنگ جهانی."],[],[],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."]]
