أفضل الممارسات لأذونات التطبيق

الإعلانات

أفضل الممارسات لأذونات التطبيق

 

 

أفضل الممارسات

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

يقدم هذا المستند تلميحات عن الطرق التي قد تكون قادراً على إستخدامها، لتحقيق نفس الوظيفة (أو أفضل).

دون الحاجة للوصول إلى معلومات مماثله؛ ليست مناقشة تفصيليه حول كيفية عمل الأذونات في نظام تشغيل الأندرويد.

للحصول على نظرة عامة على أذونات الأندرويد، يرجى الإطلاع على نظرة عامة على الأذونات. للحصول على تفاصيل حول كيفية التعامل مع الأذونات في الكود، راجع طلب أذونات التطبيق.

 

 

 

 

مبادئ التعامل مع أذونات الأندرويد


نوصي بإتباع هذه المبادئ عند التعامل مع أذونات الأندرويد:

# 1: لا تستخدم سوى الأذونات اللازمة لتطبيقك. إعتماداً على كيفية إستخدامك للأذونات.

قد تكون هناك طريقة أخرى للقيام بما تحتاج إليه (أغراض النظام، المعرفات، معلومات المكالمات الهاتفية) دون الإعتماد على الوصول إلى المعلومات الحساسة.

# 2: أعر إهتمام للأذونات المطلوبة من قبل المكتبات. عندما تقوم بتضمين مكتبة، فإنك أيضاً ترث متطلبات الأذونات الخاصة بها.

يجب أن تكون على دراية بما تقوم بتضمينه، والأذونات التي تتطلبها، وفيما تستخدم تلك الأذونات.

# 3: كن واضحاً. عندما تقدم طلباً للحصول على أذونات، كن واضحاً بشأن ما تقوم بالوصول إليه ولماذا، لكي يتمكن المستخدمون من إتخاذ قرارات مدروسه.

أجعل هذه المعلومات متاحة بجانب طلب الإذن، بما في ذلك التثبيت، وقت التشغيل، مربعات حوار تحديث الأذونات.

رقم 4: أجعل وصول النظام صريحاً. وفر دلائل مستمرة عند وصولك إلى إمكانات حساسة (على سبيل المثال، الكاميرا أو الميكروفون)..

وضح للمستخدمين عندما تقوم بجمع البيانات وتجنب أن تجعل المستخدم يتصور بأنك تجمع البيانات خلسه.

توضح الأقسام المتبقية من هذا الدليل هذه القواعد بشكلٍ تفصيلي في سياق تطوير تطبيقات الأندرويد.

 

 

 

 

 

الأذونات في أندرويد 6.0 وأعلى


قدم أندرويد 6.0 مارشميلو، نموذج أذونات جديد يتيح للتطبيقات طلب أذونات من المستخدم أثناء التشغيل، وليس قبل التثبيت.

التطبيقات التي تدعم النموذج الجديد تقوم بطلب الأذونات عندما يتطلب التطبيق فعلياً الخدمات أو البيانات المحمية بواسطة الخدمات.

على الرغم من أن هذا لا يغير سلوك التطبيق الكلي بالضرورة، إلا أنه يقوم بإنشاء بعض التغييرات ذات الصلة..

بالطريقة التي يتم بها التعامل مع بيانات المستخدم الحساسة:

زيادة السياق الظرفي: تتم مطالبة المستخدمين بمنح الأذونات أثناء التشغيل، في سياق تطبيقك..

للحصول على إذن للوصول، إلى الوظائف المشموله بمجموعات الإذن هذه.

يكون المستخدمون أكثر حساسية للسياق الذي يتم فيه طلب الإذن، وإذا كان هناك عدم توافق بين الأذن التي تطلبها والغرض من تطبيقك.

فمن المهم جداً أن تقدم شرح مفصل للمستخدم عن سبب طلبك للحصول على إذن؛ كلما أمكنك ذلك.

يجب عليك تقديم شرح لطلبك، أثناء الطلب، وفي مربع حوار المتابعه، إذا رفض المستخدم الطلب.

 

مرونة أكبر في منح الأذونات: يمكن للمستخدمين منع الوصول إلى أذونات فردية فور طلبها ومن خلال الإعدادات، ولكن قد يتفاجئوا عند تعطل الوظيفة نتيجةً لذلك.

من المستحسن مراقبة عدد المستخدمين الذين يرفضون الأذونات (على سبيل المثال، إستخدام تحليلات قوقل) بحيث يمكنك…

إما إعادة ضبط تطبيقك لتتجنب الإعتماد على هذا الإذن أو تقدم تفسير أفضل، عن سبب إحتياجك إلى الأذن لكي يعمل تطبيقك بشكلٍ صحيح.

يجب عليك أيضاً التأكد من أن تطبيقك يتعامل مع الإستثناءات التي تنشأ عند رفض المستخدمين لطلبات الأذونات، أو عند إيقاف الأذونات من خلال الإعدادات.

 

زيادة العبء المتعلق بالمعاملات: سوف يُطلب من المستخدمين منح الوصول لمجموعات الأذونات بشكلٍ فردي وليس كمجموعة.

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

 

 

 

 

 

تجنب طلب أذونات غير ضرورية


في كل مرة تطلب إذناً، فإنك بذلك تجبر المستخدم على إتخاذ قرار. يجب عليك تقليل عدد مرات إجراء هذه الطلبات.

إذا كان المستخدم يعمل بنظام التشغيل أندرويد 6.0 (مستوى واجهة برمجة التطبيقات 23) أو ما بعده.

فإنه في كل مرة يحاول المستخدم إستخدام بعض ميزات التطبيق الجديدة التي تتطلب إذن، سيتوجب على التطبيق مقاطعة عمل المستخدم لطلب إذن.

إذا كان المستخدم يشغّل إصدار أقدم من الأندرويد، فيجب على المستخدم السماح بكافة الأذونات أثناء تثبيت التطبيق.

إذا كانت القائمة طويلة جداً أو تبدو غير مناسبة، فقد يقرر المستخدم عدم تثبيت تطبيقك على الإطلاق.

لهذه الأسباب، يجب عليك تقليل عدد الأذونات التي يحتاجها تطبيقك.

يوفر هذا القسم بدائل لحالات الإستخدام الشائعة التي ستساعدك على الحد من عدد طلباتك للأذونات.

نظراً لأن عدد ونوع الأذونات، التي تطرح للمستخدمين تؤثر في عمليات التنزيل مقارنة بالتطبيقات المشابهة الأخرى..

التي تطلب أذونات أقل، فمن الأفضل تجنب طلب أذونات للوظائف الغير ضرورية.

 

 

 

 

 

إستخدم غرض بدلاً من ذلك


في العديد من الحالات، يمكنك الإختيار بين طريقتين لتنفيذ مهمة في تطبيقك.

يطلب تطبيقك الإذن لتنفيذ المهمة بنفسه، أو يمكنه إستخدام غرض لجعل تطبيق آخر يؤدي المهمة نيابة عنه.

على سبيل المثال، لنفترض أنه يجب على تطبيقك أن يكون قادراً على إلتقاط الصور بإستخدام كاميرا الجهاز.

يمكن لتطبيقك طلب إذن الكاميرا، والتي ستسمح له بالوصول إلى الكاميرا مباشرةً.

بعد ذلك سيستخدم تطبيقك واجهات برمجة تطبيقات الكاميرا للتحكم في الكاميرا والتقاط صورة.

هذا الأسلوب يمنح تطبيقك التحكم الكامل في عملية التصوير الفوتوغرافي، ويتيح لك دمج واجهة مستخدم الكاميرا في تطبيقك.

مع ذلك، إذا كانت حاجتك للوصول إلى بيانات المستخدم نادرة – بعبارة أخرى، ليس من غير المقبول…

أن يُعرض على المستخدم مربع حوار أثناء التشغيل، في كل مرة تحتاج فيها إلى الوصول إلى البيانات.

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

لأن المستخدم يختار، ما إذا كان هناك شيء يمكن مشاركته مع التطبيق، في الوقت الذي يتم فيه إصدار الطلب المستند إلى الغرض.

على سبيل المثال، يمكن إستخدام نوع إجراء الغرض من MediaStore.ACTION_IMAGE_CAPTURE أو MediaStore.ACTION_VIDEO_CAPTURE ..

لإلتقاط الصور أو ملفات الفيديو، دون إستخدام كائن الكاميرا مباشرةً (أو طلب الإذن).

في هذه الحالة، غرض النظام سيطالب بإذن المستخدم نيابة عنك، في كل مرة يتم فيها إلتقاط صورة.

وبالمثل، إذا كنت تريد إجراء مكالمة هاتفية، والوصول إلى جهات إتصال المستخدم، وما إلى ذلك.

فيمكنك القيام بذلك، عن طريق إنشاء غرض مناسب، أو يمكنك طلب الإذن والوصول إلى الكائنات المناسبة مباشرةً. هناك مزايا وعيوب لكل أسلوب.

 

 

 

 

 

إذا كنت تستخدم الأذونات:

يتمتع تطبيقك بالتحكم الكامل في تجربة المستخدم عند إجراء العملية.

مع ذلك، فإن هذه السيطرة الواسعة تزيد من تعقيد الكود الخاص بك، نظراً لحاجتك إلى تصميم واجهة مستخدم مناسبة.

تتم مطالبة المستخدم بمنح الإذن مرة واحدة، إما أثناء التشغيل، أو أثناء التثبيت (بناءً على إصدار الأندرويد الخاص بالمستخدم).

بعد ذلك، يمكن لتطبيقك إجراء العملية، دون الحاجة إلى تفاعل إضافي من المستخدم.

ومع ذلك، إذا لم يمنح المستخدم الإذن (أو قام بإلغاؤها لاحقاً)، فإن تطبيقك سيفقد القدرة كلياً على إجراء العملية.

 

 

 

إذا كنت تستخدم غرض:

لا ينبغي عليك تصميم واجهة مستخدم للعملية. يوفر التطبيق الذي يتعامل مع الغرض واجهة مستخدم.

يمكن للمستخدم إستخدام التطبيق المفضل لهذه المهمة.

على سبيل المثال، يمكن للمستخدم تحديد تطبيق الصور المفضل لديه لإلتقاط صورة.

إذا لم يكن لدى المستخدم تطبيقاً إفتراضياً للعملية، سيقوم النظام بمطالبة المستخدم بإختيار تطبيق.

إذا لم يقم المستخدم بتعيين معالج إفتراضي، فقد يضطر إلى المرور عبر مربع حوار إضافي في كل مرة يقوم فيها بإجراء العملية.

 

 

 

 

لا تربك المستخدم


إذا كان المستخدم يعمل بنظام التشغيل أندرويد 6.0 (مستوى واجهة برمجة التطبيقات 23) أو أحدث، فيجب عليه منح أذوناته للتطبيق أثناء تشغيله للتطبيق.

إذا واجهت المستخدم بعدد هائل من طلبات الأذونات مرة واحدة، فقد تربكه وتؤدي إلى إنهاؤه لتطبيقك. بدلاً من ذلك، يجب عليك طلب الأذونات عندما تحتاجها.

في بعض الحالات، قد تكون واحدة أو أكثر من الأذونات ضرورية تماماً لتطبيقك.

و قد يكون من المنطقي أن تطلب الحصول على جميع هذه الأذونات بمجرد تشغيل التطبيق.

على سبيل المثال، إذا كنت بصدد إنشاء تطبيق تصوير، فسيتطلب التطبيق الوصول إلى كاميرا الجهاز.

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

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

بدلاً من ذلك، أنتظر حتى يحاول المستخدم إستخدام ميزة “المشاركة” ثم أطلب الإذن.

إذا كان تطبيقك يوفر برنامج تعليمي، فقد يكون من المنطقي طلب الأذونات الأساسية للتطبيق في نهاية السلسلة التعليمية.

 

 

 

 

أفضل الممارسات

 

 

إيقاف الوسائط مؤقتاً بعد فقدان التركيز الصوتي


في هذه الحالة، يجب أن يذهب تطبيقك إلى الخلفية عندما يتلقى المستخدم إتصال هاتفي ويعود الصوت مجدداً عند إنتهاء المكالمة فقط.

الطريقة الشائعة في هذه الحالات – على سبيل المثال، قيام مشغل الوسائط بكتم الصوت أو إيقافه مؤقتاً أثناء المكالمة الهاتفية.

هو للإستماع إلى التغييرات في حالة المكالمة، بإستخدام PhoneStateListener أو الإستماع للبث android.intent.action.PHONE_STATE.

تتمثل المشكلة في هذا الحل، في أنه يتطلب إذن قراءة حالة الهاتف READ_PHONE_STATE، التي تفرض على المستخدم.

منح الوصول إلى مستوى واسع من البيانات الحساسة، مثل معرّفات الجهاز، وبطاقة SIM، ورقم الهاتف للمكالمة الواردة.

يمكنك إكتشاف ما إذا كان المستخدم يجري مكالمة هاتفية بدون إستخدام الأذونات READ_PHONE_STATE أو MODIFY_PHONE_STATE عن طريق طلب التركيز الصوتي لتطبيقك.

والذي لا يتطلب أذونات صريحة (لأنه لا يصل إلى معلومات حساسة).

فما عليك سوى وضع الكود المطلوب، لوضع الصوت في الخلفيه، في معالج الأحداث ()onAudioFocusChange وسيتم تشغيله تلقائياً عندما يغير نظام التشغيل تركيزه الصوتي.

يمكن العثور على وثائق أكثر تفصيلاً حول كيفية القيام بذلك هنا.

 

 

 

أفضل الممارسات

 

حدد الجهاز الذي يعمل عليه مثيلك


في هذه الحالة، تحتاج إلى معرّف فريد، لتحديد الجهاز الذي يتم تشغيل مثيل التطبيق عليه.

قد تحتوي التطبيقات على تفضيلات، أو رسائل محدده للجهاز (على سبيل المثال، حفظ قائمة تشغيل خاصة بالجهاز، لمستخدم في السحابة..

بحيث يمكن أن يكون لديه، قائمة تشغيل مختلفة لتشغيلها في سيارته أو في منزله).

الحل الشائع هو، الإستفادة من معرّفات الجهاز مثل Device IMEI، لكن هذا يتطلب مجموعة الأذونات Device ID and call information

(PHONE في M +).

والتي تستخدم أيضاً معرّف لا يمكن إعادة تعيينه، و مشاركته عبر جميع التطبيقات.

 

هناك نوعان من البدائل لإستخدام هذه الأنواع من المعرفات:

1- إستخدم واجهة برمجة تطبيقات معرف المثيل com.google.android.gms.iid.

سيؤدي ()getInstance(Context context).getID إلى إرجاع معرّف جهاز فريد لمثيل تطبيقك.

والنتيجة هي معرّف نطاق التطبيق، الذي يمكن إستخدامه كمفتاح عند تخزين معلومات حول التطبيق، وتتم إعادة تعيينه إذا قام المستخدم بإعادة تثبيت التطبيق.

2- أنشئ المعرِّف الخاص بك، و الذي يتم تحديده على مساحة تخزين تطبيقك، بإستخدام وظائف النظام الأساسية مثل ()randomUUID.

 

 

 

أفضل الممارسات

 

أنشئ معرف فريد للإعلانات أو تحليلات المستخدمين


في هذه الحالة، تحتاج إلى معرف فريد لإنشاء ملف شخصي، للمستخدمين الذين لم يسجلوا الدخول إلى تطبيقك (على سبيل المثال، للإعلانات التي تستهدف أو تحسب التحويلات).

يتطلب إنشاء ملف تعريف، للإعلان وتحليل المستخدمين أحياناً إلى معرّف مشترك، مع التطبيقات الأخرى.

تتضمن الحلول الشائعة لهذا الأمر، إستخدام معرّفات الأجهزة مثل IMEI، والذي يتطلب معرف الجهاز..

ومجموعة أذونات معلومات الإتصال (PHONE في مستوى واجهة برمجة التطبيقات 23+)، ولا يمكن للمستخدم إعادة تعيينها.

في أي من هذه الحالات، بالإضافة إلى إستخدام معرّف غير قابل لإعادة التعيين، وطلب إذن قد يبدو غريباً على المستخدمين، فإنك أيضاً ستنتهك سياسات برنامج مطوّري البرامج.

للأسف، في هذه الحالات، إستخدام واجهة معرف مثيل com.google.android.gms.iid أو وظائف النظام لإنشاء معرّف نطاق التطبيق، ليست حلولاً مناسبة.

لأنه قد يلزم مشاركة المعرّف مع التطبيقات الأخرى.

الحل البديل هو إستخدام معرّف الإعلانات المتوفر من فئة AdvertisingIdClient.Info عبر دالة ()getId.

يمكنك إنشاء كائن AdvertisingIdClient.Info بإستخدام دالة (getAdvertisingIdInfo (Context ثم إستدعاء الدالة ()getId لإستخدام المعرف.

لاحظ أن هذه الدالة محجوبه، لذلك يجب ألا تستدعيها من التسلسل الرئيسي؛ شرح مفصل لهذه الداله متاح هنا.

 

 

 

 

أفضل الممارسات

 

تعرف على المكتبات التي تتعامل معها


في بعض الأحيان، تكون الأذونات مطلوبة من قِبل المكتبات التي تستخدمها في تطبيقك.

على سبيل المثال، قد تتطلب الإعلانات ومكتبات التحليل، الوصول إلى مجموعات أذونات الموقع أو الهوية، لتنفيذ الوظائف المطلوبة.

ولكن من وجهة نظر المستخدم، يأتي طلب الإذن من تطبيقك، وليس من المكتبه.

تماماً كما يختار المستخدمون التطبيقات التي تستخدم أذونات أقل، لنفس الوظيفة، يجب على المطورين مراجعة مكتباتهم وتحديد مجموعات SDK لجهات خارجية، لا تستخدم أذونات غير ضرورية.

على سبيل المثال، حاول تجنب المكتبات التي تتطلب مجموعة أذونات الهوية، ما لم يكن هناك سبب واضح يبين سبب حاجة التطبيق إلى تلك الأذونات.

بشكلٍ خاص، بالنسبة للمكتبات التي توفر وظائف الموقع، تأكد من أنك لا تتطلب المطالبه بإذن FINE_LOCATION إلا إذا كنت تستخدم وظيفة الإستهداف المرتكزة على الموقع.

 

 

 

 

أفضل الممارسات

أشرح لماذا تحتاج إلى أذونات


يشير مربع حوار الأذونات الذي يظهره النظام عند إستدعاء ()requestPermissions إلى الإذن الذي يريده تطبيقك، ولكنه لا يحدد السبب.

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

تُظهر الأبحاث أن المستخدمين يكونوا أكثر إرتياحاً لطلبات الأذونات، إذا كانوا يعرفون سبب إحتياج التطبيق لهم. أظهرت دراسة المستخدم ما يلي:

… رغبة المستخدم في منح إذن معينه لتطبيق معين على الجهاز تتأثر بشدة بالغرض من هذه الأذن.

على سبيل المثال، يختلف إستعداد المستخدم لمنح حق الوصول إلى موقعه إستناداً إلى ما إذا كان الطلب مطلوباً لدعم الوظيفة الأساسية للتطبيق.

أو ما إذا كان لمشاركة هذه المعلومات مع شبكة إعلانية أو شركة تحليلات.

وفقاً إلى أبحاث مجموعته، خلص البروفيسور “جيسون هونغ” من جامعة كارنيجي ميلون إلى أن:

… عندما يعرف الأشخاص سبب إستخدام تطبيق ما، لشيء حساس مثل الموقع – على سبيل المثال، للإعلانات المستهدفه – فهو يجعلهم أكثر راحة من لو أخبروا ببساطة أن أحد التطبيقات يستخدم موقعهم .1

ونتيجة لذلك، إذا كنت تستخدم جزءاً فقط من طلبات واجهة برمجة التطبيقات، التي تقع ضمن مجموعة الإذن.

فستساعدك في تحديد أي من تلك الأذونات التي تستخدمها بشكلٍ صريح، ولماذا. مثال:

  • إذا كنت تستخدم موقع تقريبي فقط، فدع المستخدم يعرف ذلك في وصف تطبيقك أو في المقالات المساعدة حول تطبيقك.
  • إذا كنت بحاجة إلى الوصول إلى رسائل SMS، لتلقي رموز المصادقة التي تحمي المستخدم من الإحتيال، أسمح للمستخدم بمعرفة ذلك في وصف تطبيقك و/أو في أول مرة تصل فيها إلى البيانات.
ملاحظة: إذا كان تطبيقك يستهدف أندرويد 8.0 (مستوى واجهة برمجة التطبيقات 26) أو أعلى، فلا تطلب الحصول على إذن قراءة الرسائل القصيرة كجزء من التحقق من صحة بيانات المستخدم.

بدلاً من ذلك، أنشئ رمز مميز للتطبيق بإستخدام ()createAppSpecificSmsToken.

 ومن ثم مرر هذا الرمز إلى تطبيق آخر أو خدمة أخرى يمكنهما إرسال رسالة SMS للتحقق.

 

في ظل ظروف معينة، من المفيد أيضاً السماح للمستخدمين بمعرفة الوصول إلى البيانات الحساسة، خلال الوقت الفعلي.

على سبيل المثال، إذا كنت تدخل إلى الكاميرا أو الميكروفون، فمن الأفضل عادةً إبلاغ المستخدم بأيقونة تنبيه في مكان ما من تطبيقك.

أو في شريط الإشعارات (إذا كان التطبيق قيد التشغيل في الخلفية)، حتى لا يبدو أنك تجمع البيانات خلسة.

أخيراً، إذا كنت بحاجة لطلب إذن لعمل شيء ما في تطبيقك، ولكن السبب غير واضح للمستخدم.

فأبحث عن طريقة تسمح للمستخدم بمعرفة سبب حاجتك إلى أكثر الأذونات حساسية.

 

 

أفضل الممارسات

 

إختبار لنموذجي الأذونات


بدءاً من أندرويد 6.0 (مستوى واجهة برمجة التطبيقات 23)، يقوم المستخدمون بمنح أذونات التطبيق وإلغائها أثناء التشغيل.

بدلاً من القيام بذلك أثناء تثبيت التطبيق. نتيجةً لذلك، سيكون عليك إختبار تطبيقك ضمن مجموعة أوسع من الشروط.

قبل صدور أندرويد 6.0، كان يمكنك الإفتراض بشكلٍ معقول أنه إذا كان تطبيقك يعمل، فإنه يحتوي على جميع الأذونات التي أعلن عنها في ملف إيضاح التطبيق.

ولكن بدءاً من أندرويد 6.0، يمكن للمستخدم تشغيل الأذونات أو إيقاف تشغيلها لأي تطبيق، حتى لو كان التطبيق يستهدف، مستوى واجهة برمجة التطبيقات 22 أو أقل.

يجب عليك إجراء إختبار للتأكد من أن التطبيق يعمل بشكلٍ صحيح سواء كان لديه أي أذونات أم لم يكن.

ستساعدك النصائح التالية، في العثور على مشاكل الكود المتعلقة بالأذونات، على الأجهزة التي تقوم بتشغيل API مستوى 23 أو أعلى:

– حدد الأذونات الحالية لتطبيقك ومسارات الكود ذات الصلة.

– أختبر تدفقات المستخدم عبر الخدمات والبيانات المحمية بموجب أذونات.

– أختبر مع مجموعات مختلفة من الأذونات الممنوحة أو الملغاه. على سبيل المثال، قد يدرج تطبيق الكاميرا أذونات الوصول إلى الكاميرا و قراءة جهات الإتصال و الوصول للموقع الدقيق في ملف إيضاحه.

يجب إختبار التطبيق أثناء تشغيل كل من هذه الأذونات وأثناء إيقافها، للتأكد من أن التطبيق يمكنه التعامل مع جميع تكوينات الأذونات بأمان.

 

– استخدم أداة adb لإدارة الأذونات من سطر الأوامر:

أذونات قائمة وحالة حسب المجموعة:

$ adb shell pm list permissions -d -g

السماح أو إلغاء واحد أو أكثر من الأذونات:

$ adb shell pm [grant|revoke] <permission-name> ...

 

-تحليل تطبيقك للخدمات التي تستخدم الأذونات.

 

 

 

أفضل الممارسات

 

مصادر إضافية


 

 

المراجع


[1] Modeling Users’ Mobile App Privacy Preferences: Restoring Usability in a Sea of Permission Settings, by J. Lin B. Liu, N. Sadeh and J. Hong. In Proceedings of SOUPS 2014.

 


للإطلاع على المقال باللغة الإنجليزية أضغط هنا.

الإعلانات