החל מ-27 במרץ 2025, מומלץ להשתמש ב-android-latest-release במקום ב-aosp-main כדי ליצור תרומות ל-AOSP. מידע נוסף זמין במאמר שינויים ב-AOSP.
בדיקות בפלטפורמת Android
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
בפרויקט Android Open Source Project (AOSP) יש כמה כלים וחבילות בדיקה לבדיקה של חלקים שונים בהטמעה. לפני שמשתמשים בדפים שבקטע הזה, כדאי להכיר את המונחים הבאים:
- מכשיר תואם ל-Android
- מכשיר שיכול להריץ כל אפליקציה של צד שלישי שנכתבה על ידי מפתחים של צד שלישי באמצעות Android SDK ו-NDK. מכשירי Android תואמים חייבים לעמוד בדרישות של מסמך הגדרת התאימות (CDD) ולעבור את חבילה לבדיקות תאימות (CTS). מכשירי Android תואמים עומדים בדרישות להשתתפות בסביבה העסקית של Android, שכוללת רישוי פוטנציאלי של Google Play, רישוי פוטנציאלי של חבילת האפליקציות וממשקי ה-API של Google Mobile Services (GMS) ושימוש במותג Android. כל אחד יכול להשתמש בקוד המקור של Android, אבל כדי להיחשב כחלק מסביבת Android, המכשיר צריך להיות תואם ל-Android.
- פריט מידע אחד (artifact) שנוצר בתהליך פיתוח
- יומן שקשור ל-build שמאפשר פתרון בעיות מקומיות.
- מסמך הגדרת תאימות (CDD)
- מסמך שמפרט את הדרישות לתוכנה ולחומרה של מכשיר תואם ל-Android.
- חבילת בדיקות תאימות (CTS)
חבילת בדיקות בחינם ברמה מסחרית, שזמינה להורדה כקובץ בינארי או כקוד מקור ב-AOSP. CTS הוא אוסף של בדיקות יחידה שמיועדות לשילוב בתהליך העבודה היומי. מטרת ה-CTS היא לחשוף אי-תאימות ולוודא שהתוכנה תישאר תואמת לאורך כל תהליך הפיתוח.
בדיקות CTS ובדיקות פלטפורמה לא הן חלופיות. הנה כמה הנחיות כלליות:
- אם הבדיקה מאשרת את תקינות הפונקציות או ההתנהגויות של ממשק ה-API של המסגרת, וצריכים לאכוף את הבדיקה על שותפי OEM, היא צריכה להיכלל ב-CTS.
- אם הבדיקה נועדה לזהות נסיגות במהלך פיתוח הפלטפורמה, ייתכן שתידרש לה הרשאת הרשאה כדי לבצע אותה, וייתכן שהיא תלויה בפרטי ההטמעה (כפי שהם פורסמו ב-AOSP). במקרה כזה, צריך להגדיר אותה כבדיקה של פלטפורמה.
- Google Mobile Services (GMS)
אוסף של אפליקציות וממשקי API של Google שאפשר להתקין מראש במכשירים.
- GoogleTest (GTest)
מסגרת לבדיקה ולזיוף ב-C++. קובצי הבינארי של GTest בדרך כלל ניגשים לשכבות הפשטה ברמה נמוכה יותר או מבצעים IPC גולמי מול שירותי מערכת שונים. בדרך כלל, גישת הבדיקה של GTest משתלבת בצורה הדוקה עם השירות שנבדק. CTS מכיל את מסגרת GTest.
- בדיקת אינסטרומנטציה
סביבת ביצוע מיוחדת של בדיקות שמופעל על ידי הפקודה am instrument, שבה תהליך האפליקציה המטורגט מופעל מחדש ומאותחם עם הקשר בסיסי של האפליקציה, וחווטת הטמעה מתחילה לפעול בתוך המכונה הווירטואלית של תהליך האפליקציה. CTS מכיל בדיקות של מכשירי מדידה.
- Logcat
כלי שורת פקודה שיוצר יומן של הודעות מערכת, כולל מעקב סטאק של מקרים שבהם המכשיר גורם לשגיאה והודעות שכתבתם מהאפליקציה באמצעות הכיתה Log.
- logging
שימוש ביומן כדי לעקוב אחרי אירועים במערכת המחשב, כמו שגיאות. רישום ביומן ב-Android הוא מורכב בגלל השילוב של הסטנדרטים שבהם נעשה שימוש בכלי Logcat.
- postsubmit test
בדיקה של Android שמתבצעת כשתיקון חדש מחויב להסתעפות ליבה משותפת. מזינים את aosp_kernel כחלק משם ההסתעפות כדי לראות רשימה של הסתעפויות של הליבה עם תוצאות זמינות. לדוגמה, התוצאות של android-mainline זמינות בכתובת https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid.
- בדיקה לפני שליחת בקשה
בדיקה שמטרתה למנוע כשל בגרעינים הנפוצים.
- Trade Federation
נקרא גם Tradefed, מסגרת בדיקה רציפה שמיועדת להרצת בדיקות במכשירי Android. לדוגמה, אפשר להשתמש ב-Tradefed כדי להריץ בדיקות של חבילה לבדיקות תאימות (CTS) ובדיקות של חבילה לבדיקות ספקים (VTS).
- חבילת בדיקות של ספקים (VTS)
קבוצה של יכולות נרחבות לבדיקת Android, שמקדמות תהליך פיתוח מבוסס-בדיקה (TDD) ומאפשרות אוטומציה של בדיקות שכבת ההפשטה של החומרה (HAL) ובדיקות הליבה של מערכת ההפעלה.
סוגי בדיקות הפלטפורמה
בבדיקה של פלטפורמה מתבצעת בדרך כלל אינטראקציה עם אחד או יותר משירותי המערכת או משכבות ה-HAL של Android, מתבצעת בדיקה של הפונקציונליות של הנושא שנבדק ומוודאת התקינות של תוצאת הבדיקה. בדיקת פלטפורמה יכולה:
- (סוג 1) אימון ממשקי API של מסגרת באמצעות מסגרת Android. ממשקי ה-API הספציפיים שבהם נעשה שימוש יכולים לכלול:
- ממשקי API ציבוריים המיועדים לאפליקציות של צד שלישי
- ממשקי API מוסתרים שמיועדים לאפליקציות בעלות הרשאות, כלומר ממשקי API של מערכת או ממשקי API פרטיים (
@hide, או protected, package private)
- (סוג 2) קריאה לשירותי מערכת Android באמצעות שרתי proxy של IPC או שרתי proxy גולמיים של binder ישירות.
- (סוג 3) אינטראקציה ישירה עם HALs באמצעות ממשקי API ברמה נמוכה או ממשקי IPC.
בדיקות מסוג 1 ו-2 הן בדרך כלל בדיקות של מכשירי מדידה, ובדיקות מסוג 3 הן בדרך כלל בדיקות GTest.
מה השלב הבא?
ריכזנו כאן רשימה של מסמכים שאפשר לקרוא כדי לקבל מידע מפורט יותר:
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-07-27 (שעון UTC).
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["חסרים לי מידע או פרטים","missingTheInformationINeed","thumb-down"],["התוכן מורכב מדי או עם יותר מדי שלבים","tooComplicatedTooManySteps","thumb-down"],["התוכן לא עדכני","outOfDate","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["בעיה בדוגמאות/בקוד","samplesCodeIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 2025-07-27 (שעון UTC)."],[],[],null,["# Android platform testing\n\nAndroid Open Source Project (AOSP) provides several tools and test suites\nfor testing various parts of your implementation. Before using the pages in this\nsection, you should be familiar with the following terms:\n\n*Android-compatible device*\n: A device that can run any third-party app written by third-party developers\n using the Android SDK and NDK. Android-compatible devices must adhere to the\n requirements of the\n [Compatibility Definition Document (CDD)](#CDD) and pass the\n [Compatibility Test Suite (CTS)](#cts). Android-compatible\n devices are eligible to participate in the Android ecosystem, which includes\n potential licensure of Google Play, potential licensure of the\n [Google Mobile Services (GMS)](#gms) suite of\n app and APIs, and use of the Android trademark. Anyone is welcome to\n use the Android source code, but to be considered part of the Android ecosystem,\n a device must be Android compatible.\n\n*artifact*\n: A build-related log that enables local troubleshooting.\n\n*Compatibility Definition Document (CDD)*\n: A document that enumerates the software and hardware requirements for an\n Android-compatible device.\n\n*Compatibility Test Suite (CTS)*\n\n: A free, commercial-grade test suite, available for download as a binary or as\n source in AOSP. The CTS is a set of unit tests designed to be integrated into\n your daily workflow. The intent of CTS is to reveal incompatibilities, and\n ensure that the software remains compatible throughout the development process.\n\n CTS and platform tests aren't mutually exclusive. Here are some general\n guidelines:\n\n - If a test is asserting correctness of framework API functions or behaviors, and the test should be enforced across OEM partners, it should be in CTS.\n - If a test is intended to catch regressions during platform development, and might require privileged permission to carry out, and might be dependent on implementation details (as released in AOSP), it should be a platform test.\n\n*Google Mobile Services (GMS)*\n\n: A collection of Google apps and APIs that can be preinstalled on devices.\n\n*GoogleTest (GTest)*\n\n: A C++ testing and mocking framework. GTest binaries typically\n access lower-level abstraction layers or perform raw IPC against various system\n services. The testing approach for GTest is usually tightly coupled with the\n service being tested. CTS contains the GTest framework.\n\n*instrumentation test*\n\n: A special test execution environment\n launched by the `am instrument` command, where the targeted app process\n is restarted and initialized with basic app context, and an\n instrumentation thread is started inside the app process virtual\n machine. CTS contains instrumentation tests.\n\n*Logcat*\n\n: A command-line tool that creates a log of system messages, including\n stack traces of when the device throws an error and messages that you have\n written from your app with the `Log` class.\n\n*logging*\n\n: Using a log to keep track of computer system events, such\n as errors. Logging in Android is complex due to the mix of standards used that\n are combined in the Logcat tool.\n\n*postsubmit test*\n\n: An Android test that is performed when a new patch is committed to a\n common kernel branch. By entering `aosp_kernel` as a partial branch name, you\n can see a list of kernel branches with results available. For example, results\n for `android-mainline` can be found at\n \u003chttps://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid\u003e.\n\n*presubmit test*\n\n: A test used to prevent failures from being introduced into the\n common kernels.\n\n*Trade Federation*\n\n: Also called Tradefed, a continuous test\n framework designed for running tests on Android devices. For example,\n Tradefed is used to run Compatibility Test Suite and Vendor Test Suite tests.\n\n*Vendor Test Suite (VTS)*\n\n: A set of extensive capabilities for\n Android testing, promoting a test-driven development process, and automating\n hardware abstraction layer (HAL) and OS kernel testing.\n\nPlatform test types\n-------------------\n\nA platform test typically interacts with one or more of the Android system\nservices or HAL layers, exercises the\nfunctionalities of the subject under test, and asserts correctness of the\ntesting outcome. A platform test might:\n\n- (Type 1) Exercise framework APIs using Android framework. Specific APIs being exercised can include:\n - Public APIs intended for third-party apps\n - Hidden APIs intended for privileged apps, namely system APIs or private APIs (`@hide`, or `protected`, `package private`)\n- (Type 2) Invoke Android system services using raw binder or IPC proxies directly.\n- (Type 3) Interact directly with HALs using low-level APIs or IPC interfaces.\n\nType 1 and 2 tests are typically instrumentation tests, while type 3 tests are\nusually GTests.\n\nWhat's next?\n------------\n\nHere is a list of documents that you can read for more detailed information:\n\n- If you haven't studied Android architecture, see\n [Architecture overview](/docs/core/architecture).\n\n- If you're creating an Android-compatible device, see\n the [Android compatibility program overview](/docs/compatibility/overview).\n\n- To integrate instrumentation, functional, metric, and JAR host tests\n into a platform continuous testing service, see\n [Test development workflow](/docs/core/tests/development).\n\n- To detect and harden your devices against vulnerabilities,\n see [Security testing](/docs/security/test/fuzz-sanitize).\n\n- To learn about testing your HAL and kernel implementations, see\n [Vendor Test Suite (VTS) and infrastructure](/docs/core/tests/vts).\n\n- For app testing, read\n [Fundamentals of testing Android\n apps](https://developer.android.com/training/testing/fundamentals)\n and conduct the [Advanced Android in Kotlin 05.1:Testing\n Basics](https://codelabs.developers.google.com/codelabs/advanced-android-kotlin-training-testing-basics/index.html)\n using the\n [samples](https://github.com/android/testing-samples) provided.\n\n- Learn about the basic presubmit testing available to you through repo hooks.\n These hooks can be used to run linters, check formatting, and trigger unit\n tests before proceeding, such as uploading a commit. These hooks are disabled\n by default. For further information, see [AOSP Preupload\n Hooks](https://android.googlesource.com/platform/tools/repohooks/+/refs/heads/android16-release/README.md).\n\n- To read more about logging, see [Understand logging](/docs/core/tests/debug/understanding-logging).\n\n- To understand how to debug Android code, see\n [Debug native Android platform code](/docs/core/tests/debug)."]]
