اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
أفضل الممارسات حول أمان التطبيقات
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
يحتوي هذا القسم على اقتراحات لضمان أمان التطبيقات على
أجهزة Android.
مراجعة رمز المصدر
يمكن أن ترصد مراجعة رمز المصدر مجموعة كبيرة من مشاكل الأمان، بما في ذلك
المشاكل التي تم تحديدها في هذا المستند. ننصح بشدة بمراجعة رمز المصدر يدوياً
وبشكل آلي.
- اتّبِع إرشادات الأمان الشاملة عند إجراء المراجعات لضمان تغطية استخدِم المعايير الداخلية أو الخارجية ذات الصلة لضمان حصولك على مراجعات متّسقة وكاملة.
- يمكنك تشغيل أداة تدقيق، مثل
أداة تدقيق "استوديو Android"، على جميع رموز التطبيق باستخدام
حزمة تطوير برامج Android وتصحيح أي مشاكل تم رصدها.
- حلِّل الرمز البرمجي الأصلي باستخدام أداة آلية يمكنها رصد مشاكل إدارة
الذاكرة، مثل تدفّق المخزن المؤقت والأخطاء الناتجة عن تغيُّر قيمة واحدة.
- يتوافق نظام إنشاء Android مع العديد من أدوات فحص الأخطاء في LLVM، مثل
AddressSanitizer و
UndefinedBehaviorSanitizer،
والتي يمكن استخدامها لتحليل وقت التشغيل للمشاكل المتعلّقة بالذاكرة. عند استخدام أدوات التطهير مع أدوات البحث العشوائي عن الأخطاء، والتي تتوفّر في Android من خلال مكتبة libFuzzer، يمكن أن تكشف هذه الأدوات عن حالات استثنائية غير عادية تتطلّب إجراء مزيد من التحقيق.
- على أحد خبراء تقييم الأمان المتمرّسين مراجعة الرموز البرمجية ذات المخاطر العالية، مثل
رموز التشفير ومعالجة المعاملات ومعالجة معلومات تحديد الهوية الشخصية.
الاختبار الآلي
يمكن أن يساعد الاختبار المبرمَج في رصد مجموعة كبيرة من مشاكل الأمان، ويجب إجراؤه بانتظام.
- يمكنك تشغيل أحدث إصدار من CTS بانتظام
خلال عملية التطوير لرصد المشاكل في وقت مبكر وخفض وقت
تصحيحها. يستخدم نظام التشغيل Android أداة CTS كجزء من عملية الدمج المستمر في
عملية الإنشاء المبرمَجة التي يتم إجراؤها عدة مرات في اليوم.
- اختبار أمان الواجهات بشكل آلي، بما في ذلك الاختبار باستخدام مدخلات
ذات تنسيق غير صحيح (اختبار الاختراق). يتيح نظام إنشاء البرامج في Android استخدام مكتبة
libFuzzer لكتابة اختبارات الكشف عن الأخطاء
البرمجية.
البحث عن الثغرات الأمنية
يمكن أن يساعد فحص الثغرات الأمنية في التأكّد من أنّ التطبيقات المثبّتة مسبقًا خالية من
الثغرات الأمنية المعروفة. يمكن أن تقلّل ميزة الكشف المتقدّم من الوقت
والتكلفة المطلوبة لحلّ هذه الثغرات الأمنية ومنع المخاطر التي تواجه
المستخدمين والأجهزة.
- فحص جميع التطبيقات المثبَّتة مسبقًا باستخدام أداة فحص ثغرات التطبيقات المعتمَدة في المجال ومعالجة الثغرات التي يتم رصدها
التطبيقات التي قد تتسبّب بضرر
من المهم التأكّد من أنّ التطبيقات المثبَّتة مسبقًا على جهازك ليست
تطبيقات قد تُلحق الضرر
بجهازك. أنت مسؤول عن سلوك كل التطبيقات المضمّنة على أجهزتك. قبل تشغيل الجهاز، عليك فحص جميع التطبيقات المُحمَّلة مسبقًا بحثًا عن الثغرات الأمنية.
لمزيد من المعلومات حول التطبيقات التي قد تتسبّب بضرر وكيفية مكافحة Google لها في
متجر Play، يُرجى الاطّلاع على مستندات المطوّرين الخاصة بخدمة "Google Play للحماية".
تثبيت التطبيقات وأذوناتها
يمكن أن تؤدي الأذونات المفرطة للتطبيقات المثبَّتة مسبقًا إلى تعريضك لمخاطر أمنية.
حصر التطبيقات المثبَّتة مسبقًا بأقل الأذونات اللازمة والتأكّد من عدم وصولها
إلى أذونات أو امتيازات غير ضرورية يتم توضيح أذونات التطبيق في AndroidManifest.xml.
- لا تمنح أذونات أو امتيازات غير ضرورية للتطبيقات المثبَّتة مسبقًا. راجِع بدقة التطبيقات التي تملك أذونات نظام، لأنّها قد تحصل على أذونات
حسّاسة للغاية.
- تأكَّد من أنّ جميع الأذونات المطلوبة ذات صلة وضرورية لتشغيل
هذا التطبيق المحدّد.
- تأكَّد من توفُّر بيان الإفصاح عن التعامل مع البيانات للمستخدمين لجميع التطبيقات المثبَّتة مسبقًا التي تستخدم إذن
INSTALL_PACKAGES.
- تأكَّد من أنّ المطوّر ملزم بموجب العقد بعدم تثبيت أي تطبيقات
باستخدام رقم التعريف الفريد 0.
- تقييم الأذونات المُعلَن عنها في بيان جميع التطبيقات التي سيتم تثبيتها
من خلال شبكة المطوّر
- تأكَّد من أنّ المطوّر ملزم بموجب العقد بفحص جميع عناوين URL
للتنزيل الخاصة بالتطبيقات المزوّدة بميزة التحديث التلقائي وتطبيقات التثبيت باستخدام Google Safe Browsing API
قبل عرض التطبيقات على الجهاز.
توقيع التطبيق
تؤدي توقيعات التطبيقات دورًا مهمًا في أمان الجهاز، ويتم استخدامها لفحص الأذونات وتحديثات البرامج. عند اختيار مفتاح لاستخدامه في توقيع التطبيقات، من المهم مراعاة ما إذا كان التطبيق متاحًا على جهاز واحد فقط أو على أجهزة متعددة.
- تأكَّد من عدم توقيع التطبيقات باستخدام مفتاح معروف للجميع، مثل
مفتاح المطوّر في AOSP.
- تأكَّد من أنّ المفاتيح المستخدَمة لتوقيع التطبيقات تُدار بطريقة متوافقة
مع الممارسات المتّبعة في المجال لمعالجة المفاتيح الحسّاسة، بما في ذلك
وحدة أمان الأجهزة (HSM) التي توفّر إمكانية وصول محدودة يمكن مراجعتها.
- تأكَّد من عدم توقيع التطبيقات باستخدام مفتاح المنصة. يؤدي ذلك إلى منح
تطبيقك إذن الوصول إلى أذونات توقيع النظام الأساسي، وهي أذونات قوية جدًا
ومخصّصة فقط لاستخدام مكوّنات نظام التشغيل. يجب أن تستخدم تطبيقات النظام
أذونات مميّزة.
- تأكَّد من عدم توقيع التطبيقات التي تحمل اسم الحزمة نفسه باستخدام مفاتيح
مختلفة. ويحدث ذلك غالبًا عند إنشاء تطبيق لأجهزة مختلفة،
خاصةً عند استخدام مفتاح النظام الأساسي. إذا كان التطبيق مستقلاً عن الجهاز،
استخدِم المفتاح نفسه على جميع الأجهزة. إذا كان التطبيق خاصًا بالجهاز، أنشِئ
أسماء حِزم فريدة لكل جهاز ومفتاح.
عزل التطبيقات والعمليات
يقدّم نموذج وضع الحماية
في Android أمانًا إضافيًا للتطبيقات والعمليات عند استخدامه بشكل صحيح.
عزل العمليات الأساسية
إنّ عمليات الجذر هي الهدف الأكثر شيوعًا لهجمات تصعيد الامتيازات.
ويؤدي تقليل عدد عمليات الجذر إلى تقليل خطر تصعيد الامتيازات.
- تأكَّد من أنّ الأجهزة تعمل بالحد الأدنى من الرموز البرمجية اللازمة بصفتها الجذر. استخدِم عملية Android عادية بدلاً من عملية الجذر، متى كان ذلك
ممكنًا. إذا كان يجب تنفيذ عملية
باستخدام إذن الوصول إلى الجذر على جهاز، يجب توثيق العملية في طلب ميزة
لنظام التشغيل AOSP حتى يمكن مراجعتها بشكل علني.
- يجب عزل الرمز الجذر عن البيانات غير الموثوق بها كلما أمكن،
والوصول إليه من خلال ميزة "التواصل بين العمليات" (IPC). على سبيل المثال، يمكنك تقليل وظائف ملف التمهيد
إلى خدمة صغيرة يمكن الوصول إليها من خلال Binder وعرض
الخدمة التي تملك إذن التوقيع على تطبيق يملك امتيازات منخفضة أو لا يملك أي امتيازات
لمعالجة حركة بيانات الشبكة.
- يجب ألا تستمع عمليات الجذر إلى منفذ شبكة.
- يجب ألا تتضمّن العمليات الجذر بيئة تشغيل للأغراض العامة، مثل Java VM.
عزل تطبيقات النظام
بشكل عام، يجب عدم تشغيل التطبيقات المثبَّتة مسبقًا باستخدام المعرّف الفريد المشترَك للنظام (UID). إذا كان من الضروري أن يستخدم التطبيق المعرّف الفريد المشترَك للنظام
أو خدمة أخرى مميّزة (مثل الهاتف)، يجب ألا يصدِّر التطبيق
أي خدمات أو أجهزة استقبال للبث أو مقدّمي محتوى يمكن للتطبيقات التابعة لجهات خارجية التي ثبَّتها المستخدمون الوصول إليها
.
- تأكَّد من أنّ الأجهزة تعمل بالحد الأدنى من الرموز البرمجية اللازمة كنظام. كلما أمكن،
استخدِم عملية Android التي لها رقم تعريف مستخدم خاص بها بدلاً من إعادة استخدام رقم تعريف مستخدم النظام.
- يجب عزل رمز النظام عن البيانات غير الموثوق بها كلما أمكن،
ويجب عدم السماح بعمليات تبادل البيانات بين العمليات إلا للعمليات الموثوق بها الأخرى.
- يجب ألا تستمع عمليات النظام إلى منفذ شبكة. هذا شرط من متطلبات 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."]]
