اختبار مستخدمين متعدّدين

توضِّح هذه الصفحة الجوانب المهمة لاختبار حسابات مستخدمين متعدّدين على منصّة Android. للحصول على معلومات عن تنفيذ ميزة "الوصول المتعدد للمستخدمين"، يُرجى الاطّلاع على مقالة إتاحة ميزة "الوصول المتعدد للمستخدمين".

مسارات الأجهزة

يسرد الجدول التالي العديد من مسارات الأجهزة وكيفية حلّها. جميع القيم في عمود المسار هي مساحة تخزين في مساحة مغلقة خاصة بالمستخدم. تغيّرت قصة مساحة التخزين في Android بمرور الوقت. يُرجى الاطّلاع على مستندات مساحة التخزين للحصول على مزيد من المعلومات.

في ما يلي مثال على استخدام مسار خاص بالمستخدم:

# to access user 10's private application data for app com.bar.foo:
$ adb shell ls /data/user/10/com.bar.foo/

تفاعلات adb بين المستخدمين

تكون عدّة أوامر adb مفيدة عند التعامل مع مستخدمين متعدّدين. لا تتوفّر بعض هذه الطلبات إلا في الإصدار 9 من نظام Android والإصدارات الأحدث:

• adb shell am instrument --user <userId> يُجري اختبارًا للأدوات ضد مستخدم معيّن. يتم استخدام المستخدم الحالي تلقائيًا.
• تثبِّت adb install --user <userId> حزمة لمستخدم معيّن. لضمان تثبيت حزمة لجميع المستخدمين، يجب استدعاء هذه السلسلة من الخطوات لكل مستخدم.
• adb uninstall --user <userId> يزيل حزمة لمستخدم معيّن. يمكنك طلب الإجراء بدون العلامة --user لإزالة التطبيق لجميع المستخدمين.
• يحصل adb shell am get-current-user على رقم تعريف المستخدم الحالي (في المقدّمة).
• تحصل adb shell pm list users على قائمة بجميع المستخدمين الحاليين.
• adb shell pm create-user ينشئ مستخدمًا جديدًا، ويعرض رقم التعريف.
• تزيل adb shell pm remove-user مستخدمًا معيّنًا حسب رقم التعريف.
• adb shell pm disable --user <userId> يوقف حزمة لمستخدم معيّن.
• adb shell pm enable --user <userId> تفعِّل حزمة لمستخدم معيّن.
• يعرض adb shell pm list packages --user <userId> الحِزم (-e للإشارة إلى أنّها مفعّلة و-d للإشارة إلى أنّها غير مفعّلة) لمستخدم معيّن. يتم تلقائيًا إدراج هذا الإعداد دائمًا لمستخدم النظام.

تساعد المعلومات التالية في توضيح سلوك adb مع مستخدمين متعدّدين:

• يتم دائمًا تشغيل adb (أو بشكل أدق الخادم الداعم adbd) بصفتها مستخدِم النظام (معرّف المستخدِم = 0) بغض النظر عن المستخدِم الحالي. لذلك، فإنّ مسارات الجهاز التي تعتمد على المستخدم (مثل /sdcard/) يتم حلّها دائمًا على أنّها مستخدم النظام. اطّلِع على مسارات الجهاز للحصول على مزيد من التفاصيل.

• إذا لم يتم تحديد مستخدم تلقائي، سيكون لكلّ أمر فرعي من adb مستخدم مختلف. من أفضل الممارسات استرداد رقم تعريف المستخدم باستخدام am get-current-user ثم استخدام --user <userId> بشكل صريح لأي أمر يتيح ذلك. لم تكن علامات المستخدِم الصريحة متاحة لجميع الأوامر حتى الإصدار 9 من Android.

• تم حظر الوصول إلى مسارات /sdcard للمستخدمين الثانويين اعتبارًا من الإصدار Android 9. اطّلِع على موفِّر المحتوى لبيانات المستخدمين المتعدّدين للحصول على تفاصيل حول كيفية استرجاع الملفات أثناء الاختبار.

موفّر المحتوى لبيانات عدّة مستخدمين

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

• يتم تشغيل adbd بصفتها الجذر (من خلال adb root)، ولا يمكن إجراء ذلك إلا باستخدام إصدارات userdebug أو usereng.

• إذا كنت تستخدم مكتبة ITestDevice ITestDevice من Trade Federation (Tradefed) لدفع الملفات أو سحبها، استخدِم مسارات /sdcard/ في ملف الاختبار الإعدادي (على سبيل المثال، اطّلِع على رمز المصدر لـ pushFile في NativeDevice.java).

عندما يكون مقدّم المحتوى قيد التشغيل في حساب المستخدم الثانوي، يمكنك الوصول إليه باستخدام الأمر adb shell content مع المَعلمات المناسبة user وuri وغيرها من المَعلمات المحدّدة.

حلّ بديل لمطوّري التطبيقات

يمكنك التفاعل مع الملفات الاختبارية باستخدام adb content ومثيل ContentProvider، بدلاً من الأمر push أو pull.

1. أنشئ مثيلًا من ContentProvider يستضيفه التطبيق ويمكنه عرض والتخزين الملفات عند الحاجة. استخدام مساحة التخزين الداخلية للتطبيق
2. استخدِم الأمرَين adb shell content read أو write لدفع الملفات أو سحبها.

حلّ بديل لملفات الوسائط

لدفع ملفات الوسائط إلى قسم الوسائط في بطاقة SD، استخدِم MediaStore واجهة برمجة التطبيقات العلنية. مثلاً:

# push MVIMG_20190129_142956.jpg to /storage/emulated/10/Pictures
# step 1
$ adb shell content insert --user 10 --uri content://media/external/images/media/ --bind _display_name:s:foo.jpg

# step 2
$ adb shell content query --user 10 --projection _id --uri content://media/external/images/media/ --where "_display_name=\'foo.jpg\'"

# step 3
$ adb shell content write --user 10 --uri content://media/external/images/media/8022 < MVIMG_20190129_142956.jpg

تثبيت موفّر محتوى عام

ثبِّت مقدّم محتوى حاليًا واستخدِمه لقراءة الملفات وكتابتها في ملف /sdcard الخاص بالمستخدم.

أنشئ TradefedContentProvider.apk من المصدر باستخدام make TradefedContentProvider:

```
# install content provider apk
$ adb install --user 10 -g TradefedContentProvider.apk

# pull some_file.txt
$ adb shell content read --user 10 --uri content://android.tradefed.contentprovider/sdcard/some_file.txt > local_file.txt

# push local_file.txt
$ adb shell content write --user 10 --uri content://android.tradefed.contentprovider/sdcard/some_file.txt < local_file.txt
```

إتاحة استخدام ميزة "اتحاد التجارة" لعدة مستخدمين

‫Tradefed هو أداة اختبار تطبيقات Android الرسمية. يلخِّص هذا القسم بعضًا من ميزات التكامل المضمّنة في Tradefed لسيناريوهات الاختبار المتعدّد المستخدمين.

أدوات التحقّق من الحالة

يتم تشغيل أدوات التحقّق من حالة النظام (SSC) قبل أدوات الإعداد المستهدفة، ويتم تشغيل عملية التنظيف بعد أدوات الإعداد هذه.

تم تحديد UserChecker بوضوح لمساعدة المطوّرين عند اختبار مستخدمين متعدّدين. وتتتبّع هذه السمة ما إذا كان الاختبار قد غيّر حالة المستخدمين على الجهاز (على سبيل المثال، إنشاء مستخدمين بدون إزالتهم في عملية الإزالة). بالإضافة إلى ذلك، في حال ضبط user-cleanup ، يحاول البرنامج تلقائيًا تنظيف البيانات بعد الاختبار، مع مواصلة تقديم أخطاء مفيدة حتى يمكن إصلاح الاختبار.

<system_checker class="com.android.tradefed.suite.checker.UserChecker" >
    <option name="user-cleanup" value="true" />
</system_checker>

مُعدّ التقارير المستهدَفة

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

بالنسبة إلى أنواع الأجهزة التي لا تتضمّن مستخدمًا ثانويًا، يمكنك استخدام CreateUserPreparer لإنشاء التبديل إلى مستخدم ثانوي في AndroidTest.xml. في نهاية الاختبار، يعود المُعدّ إلى الحساب الأساسي ويصعِد ملف تعريف المستخدم الثانوي ويحذفه.

<target_preparer
  class="com.google.android.tradefed.targetprep.CreateUserPreparer" >
</target_preparer>

إذا كان نوع المستخدم الذي تريده متوفّرًا على الجهاز، استخدِم رمز SwitchUserTargetPreparer للتبديل إلى المستخدم الحالي. تشمل القيم الشائعة لسمة user-type system أو secondary.

<target_preparer
  class="com.android.tradefed.targetprep.SwitchUserTargetPreparer">
    <option name="user-type" value="secondary" />
</target_preparer>

الاختبارات التي يجريها المضيف

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

استخدِم UserChecker (الموضَّح في أدوات التحقّق من الحالة) للاختبارات المستندة إلى المضيف التي تغيّر حالة المستخدم، لأنّها تضمن إزالة الاختبار بشكل صحيح بعد الانتهاء.