מערכת VTS תומכת בבדיקות שדורשות אינטראקציה בין כמה מכשירי Android.
ארכיטקטורה
מערכת VTS משתמשת במסגרת TradeFed כדי לקבל מספרי סידורי של מכשירים ולהעביר אותם למודולי בדיקה.

דרישות המכשיר, כמו מספר המכשירים וסוגי המכשירים, מפורטות בהגדרת תוכנית הבדיקה. לדוגמה, אפשר לציין תוכנית בדיקה שנדרשים בה שני מכשירי Android עם יעדי בנייה של Sailfish.
הקצאת מכשירים
תשתית הבדיקה (בדרך כלל מתזמן הבדיקות) מקצה מכשירים זמינים שעומדים בדרישות שצוינו בהגדרת תוכנית הבדיקה ל-VTS framework. המכשירים שהוקצו שמורים לתוכנית הבדיקה גם אם מודול הבדיקה לא משתמש בהם. אחרי כן, קובצי ה-VTS agent הבינאריים נדחפים ומופעלים בכל המכשירים שהוקצו (אלא אם יש הוראה ספציפית לא להפעיל אותם). כך מוודאים שחיבורי TCP לפקודות shell ול-HAL RPC זמינים לכל המכשירים בסקריפט בדיקה.
מכינים למבחנים
המסגרת מריצה בדיקות הכנה לכל המכשירים שהיא קיבלה עבורם מספרים סידוריים. מכשירים להכנת טרגוט יכולים להיות מכשירים יחידים או מכשירים מרובים:
- מכיני יעד במכשיר יחיד (דוגמה ב-VtsDeviceInfoCollector):
- אפשר לציין את ההגדרה הזו רק בהגדרת תוכנית הבדיקה עם רשימת המכשירים הנדרשת (בגרסאות עתידיות תהיה אפשרות להגדיר את ההגדרה הזו ברמת המודול).
- מקבלים רק מספר סידורי אחד של מכשיר.
- הפעלת משימות הכנה וניקוי במכשיר ספציפי.
- קובצי הכנה לטירגוט למספר מכשירים (דוגמה ב-VtsPythonVirtualenvPreparer):
- אפשר לציין את ההגדרה בתצורת תוכנית הבדיקה או בתצורת מודול הבדיקה
- קבלת כל המספרים הסידוריים של המכשירים
- מריצים את המשימות של ההכנה והניקוי לכל מכשיר או לכל המכשירים.
Test modules
מודולים של בדיקות מקבלים רשימה של מכשירים אחרי שהבודקים מסיימים להגדיר את המארח או את המכשירים. מודול בדיקה אחד של Python בצד המארח מופעל עבור כל מודול בדיקה של התאמה רחבה. אפשר לגשת למכשירי Android שהוקצו ממודולי בדיקה של Python בתור רשימה של אובייקטים מסוג AndroidDevice:
devices = self.android_devices device1 = devices[0] device1_serial = device1.serial
כל המכשירים שהוקצו שמורים לתוכנית הבדיקה, גם אם מודול הבדיקה בתוכנית משתמש רק במכשיר אחד.
תקשורת בין מכשירים במהלך הבדיקה
בדיקות יעילות של כמה מכשירי Android כוללות תקשורת בין המכשירים שהוקצו. כשמפתחים בדיקות כאלה, צריך לקבוע איך ליצור תקשורת בין המכשירים שהוקצו. בקטעים הבאים מופיעות שלוש דוגמאות לתקשורת (אבל מפתחי הבדיקות יכולים לעצב מודלים אחרים).
סוג 1: בדיקות HAL בצד המארח
בדיקות HAL בצד המארח יכולות להשתמש במנהלי התקנים של VTS HAL שמועברים למכשירים כברירת מחדל:

במקרה כזה:
- לוגיקת הבדיקה מופעלת במארח.
- סקריפט בדיקה בצד המארח שולח קריאות RPC למנהלי ההתקנים בכל מכשיר.
- המארח מתאם את האינטראקציות עם המכשיר.
סוג 2: בדיקות מבוססות-סוכן בצד המארח
במקום להשתמש בסוכני VTS במכשיר, בדיקה בצד המארח יכולה גם לדחוף סוכן משלה (אפליקציה או קובץ בינארי) לכל מכשיר:

במקרה כזה:
- לוגיקת הבדיקה מופעלת במארח.
- אפליקציית הסוכן (או קובץ בינארי) מותקנת בכל מכשיר.
- סקריפט הבדיקה בצד המארח שולח פקודות לאפליקציות בכל מכשיר.
- המארח מתאם את האינטראקציות עם המכשיר.
לדוגמה, בדיקות של המשתמשים הבאים במאגר VTS הנוכחי הן בדיקות בצד המארח, מבוססות אפליקציות ומתבצעות בכמה מכשירים.
סוג 3: בדיקות HIDL בצד היעד
בבדיקות HIDL מרובות מכשירים בצד היעד, כל לוגיקת הבדיקה נמצאת בקובצי בדיקה בינאריים בצד המכשיר, ולכן הבדיקות צריכות לסנכרן את המכשירים במהלך ביצוע הבדיקה:

במקרה כזה:
- הלוגיקה של הבדיקה מופעלת במכשירים.
- המסגרת בצד המארח מספקת זיהוי ראשוני של המכשיר.
- קובץ בינארי לבדיקה בצד היעד דורש סנכרון:
- אותו קובץ בינארי של הבדיקה לכל המכשירים.
- קובצי הפעלה שונים לבדיקה לכל תפקיד.
דוגמה: תוכנית בדיקה להתאמה רחבה
בדוגמה הזו מוגדרת ההגדרה לשני מכשירים:
- מכשיר 1 כולל ספק build ו
VtsDeviceInfoCollectortarget preparer. - מכשיר 2 כולל
FilePusherמכין נוסף שמעביר קבוצה של קבצים קשורים שמבוססים על המארח למכשיר.
<configuration description="VTS Codelab Plan"> ... <device name="device1"> <build_provider class="com.android.compatibility.common.tradefed.build.CompatibilityBuildProvider" /> <target_preparer class="com.android.tradefed.targetprep.VtsDeviceInfoCollector" /> </device> <device name="device2" > <build_provider class="com.android.compatibility.common.tradefed.build.CompatibilityBuildProvider" /> <target_preparer class="com.android.tradefed.targetprep.VtsDeviceInfoCollector" /> <target_preparer class="com.android.compatibility.common.tradefed.targetprep.VtsFilePusher"> <option name="push-group" value="HostDrivenTest.push" /> </target_preparer> </device> <option name="compatibility:include-filter" value="VtsCodelabHelloWorldMultiDeviceTest" /> </configuration>
דוגמה: סקריפט בדיקה של Python בצד המארח
פרטים ודוגמאות לגבי קבצים להכנת בדיקות מופיעים במאמר בנושא קבצים להכנת בדיקות. דוגמה מלאה לשימוש בכמה מכשירים בצד המארח מופיעה ב-codelab hello_world_multi.
def setUpClass(self):
logging.info('number of device: %s', self.android_devices)
asserts.assertEqual(len(self.android_devices), 2, 'number of device is wrong.')
self.dut1 = self.android_devices[0]
self.dut2 = self.android_devices[1]
self.shell1 = self.dut1.shell
self.shell2 = self.dut2.shell
def testSerialNotEqual(self):
'''Checks serial number from two device not being equal.'''
command = 'getprop | grep ro.serial'
res1 = self.shell1.Execute(command)
res2 = self.shell2.Execute(command)
def getSerialFromShellOutput(output):
'''Get serial from getprop query'''
return output[const.STDOUT][0].strip().split(' ')[-1][1:-1]
serial1 = getSerialFromShellOutput(res1)
serial2 = getSerialFromShellOutput(res2)
logging.info('Serial number of device 1 shell output: %s', serial1)
logging.info('Serial number of device 2 shell output: %s', serial2)
asserts.assertNotEqual(serial1, serial2, 'serials from two devices should not be the same')
asserts.assertEqual(serial1, self.dut1.serial, 'serial got from device system property is different from allocated serial')
asserts.assertEqual(serial2, self.dut2.serial, 'serial got from device system property is different from allocated serial')