Runtime Permission: ما هي الأنواع ومبدأ العمل في Android

ما هو Runtime Permission؟

Runtime Permission هو نموذج أمان Android حيث يطلب التطبيق الوصول إلى البيانات الحساسة في اللحظة التي تكون فيها هذه الوظيفة ضرورية فعليًا للمستخدم. قبل Android 6.0، كانت جميع الأذونات تُمنح عند تثبيت التطبيق، ولم يتمكن المستخدم من إلغائها دون إزالة التطبيق بالكامل.

تطور نموذج أذونات Android

قبل Android 6.0، كان المستخدم يرى قائمة بجميع الأذونات عند التثبيت ويمكنه إما الموافقة على الكل أو رفض التثبيت. أظهرت دراسة عام 2015 أن 87% من المستخدمين لا يقرؤون قائمة الأذونات عند التثبيت. Android 6.0 قدم أذونات وقت التشغيل، مقسمة الأذونات إلى عادية (تلقائية) وخطرة (تتطلب طلبًا). Android 11 أضاف الأذونات لمرة واحدة — الإلغاء التلقائي بعد إغلاق التطبيق. Android 13 قدم منتقي الصور وإشعارات الدفع كأذونات وقت تشغيل منفصلة.

iOS يستخدم نموذجًا مشابهًا منذ iOS 10، حيث يتم طلب الوصول إلى الكاميرا والميكروفون والموقع الجغرافي عند أول استخدام. ومع ذلك، لا يحتوي iOS على مفهوم «الأذونات العادية» — يتم طلب كل إذن بشكل صريح، ويستمر الرفض حتى يعيد المطور الطلب من خلال إعدادات النظام.

كيف يعمل Runtime Permission في Android؟

Runtime Permission يعمل من خلال حوار نظام يتم استدعاؤه بواسطة طريقة requestPermissions() (AndroidX — ActivityResultLauncher). يعرض النظام حوارًا قياسيًا مع شرح، ويختار المستخدم «السماح» أو «الرفض». بعد الرد، يتم استدعاء رد اتصال حيث يعالج التطبيق قرار المستخدم.

طلب الإذن عبر ActivityResultLauncher

private lateinit var requestPermissionLauncher: ActivityResultLauncher<String>

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)

    requestPermissionLauncher =
        registerForActivityResult(ActivityResultContracts.RequestPermission()) { isGranted ->
            if (isGranted) {
                startCamera()
            } else {
                showPermissionDeniedDialog()
            }
        }
}

private fun checkCameraPermission() {
    when {
        ContextCompat.checkSelfPermission(this, Manifest.permission.CAMERA)
                == PackageManager.PERMISSION_GRANTED -> {
            startCamera()
        }
        ActivityCompat.shouldShowRequestPermissionRationale(this, Manifest.permission.CAMERA) -> {
            showRationaleDialog { requestPermissionLauncher.launch(Manifest.permission.CAMERA) }
        }
        else -> {
            requestPermissionLauncher.launch(Manifest.permission.CAMERA)
        }
    }
}

طريقة shouldShowRequestPermissionRationale تعيد true إذا كان المستخدم قد رفض الطلب مرة واحدة بالفعل. في هذه الحالة، يُوصى بإظهار حوار مع شرح لماذا يحتاج التطبيق إلى الإذن، ثم إعادة الطلب فقط. هذا يزيد من احتمالية موافقة المستخدم بنسبة 30–40% (بيانات Google I/O 2024).

أنواع الأذونات في Android

Android يصنف جميع الأذونات إلى عدة مستويات حماية: عادية وخطرة وتوقيع وخاصة. الأذونات العادية تُمنح تلقائيًا عند التثبيت. الأذونات الخطرة تتطلب طلب وقت تشغيل. أذونات التوقيع متاحة فقط للتطبيقات الموقعة بنفس الشهادة.

مجموعات الأذونات الخطرة

الأذونات الخاصة (SYSTEM_ALERT_WINDOW، WRITE_SETTINGS، MANAGE_EXTERNAL_STORAGE) تتطلب انتقالًا إضافيًا إلى إعدادات النظام عبر Settings.ACTION_MANAGE_OVERLAY_PERMISSION. لا يمكن طلب هذه الأذونات من خلال حوار النظام القياسي وتتطلب إجراءً صريحًا من المستخدم في شاشة الإعدادات.

طلب الأذونات في Android 12+

Android 12 قدم تغييرات كبيرة في نموذج أذونات وقت التشغيل. الأذونات لمرة واحدة تسمح بمنح الوصول إلى الكاميرا أو الميكروفون أو الموقع الجغرافي لجلسة واحدة فقط. بمجرد إغلاق المستخدم للتطبيق، يتم إلغاء الإذن تلقائيًا. مؤشرات الخصوصية هي مؤشرات خضراء في شريط الحالة تظهر عند استخدام التطبيق للكاميرا أو الميكروفون.

معالجة الأذونات لمرة واحدة

// Android 12+ — معالجة الإذن لمرة واحدة للموقع الجغرافي
private fun checkLocationPermission() {
    val permissionLauncher =
        registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { permissions ->

        val fineLocationGranted = permissions[Manifest.permission.ACCESS_FINE_LOCATION]
        val coarseLocationGranted = permissions[Manifest.permission.ACCESS_COARSE_LOCATION]

        if (fineLocationGranted == true) {
            showUserLocation()
        } else {
            showLocationDisabledDialog()
        }
    }

    permissionLauncher.launch(
        arrayOf(
            Manifest.permission.ACCESS_FINE_LOCATION,
            Manifest.permission.ACCESS_COARSE_LOCATION
        )
    )
}

// التحقق مما إذا كان الإذن قد تم إلغاؤه بواسطة النظام (Android 12+)
class PermissionReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        if (intent.action == Intent.ACTION_PERMISSION_REVOCATION) {
            handleRevokedPermission(intent.getStringExtra(Intent.EXTRA_REVOKED_PERMISSION))
        }
    }
}

Android 13 أضاف إذن POST_NOTIFICATIONS إلى المجموعة الخطرة، مما يتطلب طلبًا صريحًا لإرسال إشعارات الدفع. Android 14 قدم قيودًا على الموقع الجغرافي في الخلفية: يجب أن يحصل التطبيق على موافقة صريحة من المستخدم في كل مرة يطلب فيها موقع الخلفية. منتقي الصور (API 33+) استغنى عن الحاجة إلى READ_EXTERNAL_STORAGE لاختيار الصور.

معالجة رفض المستخدم

رفض المستخدم لطلب الإذن هو حالة طبيعية يجب معالجتها بشكل صحيح. هناك نوعان من الرفض: لمرة واحدة (ضغط المستخدم على «رفض») ودائم (اختار المستخدم «عدم السؤال مرة أخرى»). في الحالة الثانية، لن يظهر حوار النظام بعد الآن، ويجب على التطبيق توجيه المستخدم إلى إعدادات النظام.

استراتيجية معالجة الرفض

بعد الرفض الأول، يجب على التطبيق إظهار حوار تبرير — شرحه الخاص لسبب ضرورة الإذن. إذا رفض المستخدم مرة أخرى، يجب توجيهه إلى شاشة إعدادات التطبيق عبر Settings.ACTION_APPLICATION_DETAILS_SETTINGS. Material 3 يوصي باستخدام PermissionRequestBottomSheet لتجربة مستخدم أكثر طبيعية.

من المهم عدم حظر وظائف التطبيق تمامًا عند الرفض. على سبيل المثال، إذا رفض المستخدم الموقع الجغرافي، يجب على التطبيق تقديم إدخال العنوان يدويًا. بالنسبة لـ الكاميرا، السماح بتحميل الصورة من المعرض. توصي Google دائمًا بتوفير آلية بديلة لجميع أذونات وقت التشغيل.

توصيات الأمان

أذونات وقت التشغيل ليست مجرد آلية تقنية، بل هي أيضًا عنصر ثقة المستخدم في التطبيق. طلب الإذن في وقت غير مناسب (على سبيل المثال، عند التشغيل الأول) يقلل بشكل كبير من احتمالية الموافقة. Google Play Store يحلل تكرار وسياق طلبات الأذونات: التطبيقات ذات الطلبات العدوانية تحصل على مراكز أقل في البحث.

قواعد طلب الأذونات

السياق — اطلب الإذن مباشرة قبل تنفيذ الإجراء الذي يتطلبه. الحد الأدنى — اطلب فقط الأذونات الضرورية فعليًا لعمل الميزة. الشفافية — اشرح للمستخدم سبب الحاجة إلى الإذن قبل حوار النظام. الإلغاء — اشترك في ACTION_PERMISSION_REVOCATION لمعالجة إلغاء الإذن بشكل صحيح في وقت التشغيل.

لاختبار أذونات وقت التشغيل، استخدم أوامر adb: adb shell pm revoke <package> android.permission.CAMERA تسمح بمحاكاة إلغاء الإذن دون إعادة تثبيت التطبيق. Espresso و UiAutomator يدعمان اختبار حوارات الأذونات عبر GrantPermissionRule. دمج هذه الأدوات في خط أنابيب CI/CD إلزامي للتطبيقات ذات أذونات وقت التشغيل.

تدقيق الأذونات في Google Play Console

Google Play Console يوفر قسم تدقيق الأذونات، حيث يمكن للمطورين رؤية عدد مرات طلب الأذونات، ونسبة المستخدمين الذين يمنحون الوصول، والأذونات التي تم إلغاؤها. يساعد تحليل هذه البيانات في تحديد الطلبات غير الفعالة وتحسين تجربة المستخدم. على سبيل المثال، إذا كان أقل من 40% من المستخدمين يمنحون الموقع الجغرافي، فكر في مراجعة توقيت الطلب وإضافة تبرير أكثر إقناعًا.

استخدام Android Vitals لمراقبة ANR (التطبيق لا يستجيب) المرتبط بالأذونات هو أيضًا أمر بالغ الأهمية. إذا تم تنفيذ طلب الإذن على الخيط الرئيسي أو قام حوار النظام بحظر واجهة المستخدم، فقد يتسبب ذلك في ANR على الأجهزة البطيئة. انقل التحقق من الأذونات وطلبها إلى خيط منفصل أو استخدم coroutines في Kotlin للمعالجة غير المتزامنة لتجنب حظر واجهة المستخدم.