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

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

تصف هذه الصفحة الجوانب المهمة لاختبار عدة مستخدمين على نظام 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 المفيدة عند التعامل مع مستخدمين متعددين. بعض لا يتم دعم هذه الأوامر إلا في Android 9 أعلى:

• يتم إجراء اختبار قياس حالة التطبيق من قِبل "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> بشكل صريح لأي أمر يتيح ذلك. موسيقى فاضحة لم تكن عمليات إبلاغ المستخدمين متاحة في جميع الطلبات حتى نظام التشغيل Android 9.

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

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

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

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

• تستخدم قائمة اتحاد تجاري ITestDevice لإرسال الملفات أو سحبها، وفي هذه الحالة استخدِم مسارات /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 الرسمية. يلخص هذا القسم بعض الأدوات المضمنة دعم سيناريوهات اختبار عدة مستخدمين.

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

أدوات التحقّق من حالة النظام (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 (الموضّح في أدوات التحقّق من الحالة) للاختبارات التي يجريها المضيف التي تتغير حالة المستخدم لأنها تضمن أن يتم تنظيف الاختبار من بعد نفسه بشكل صحيح.