از 27 مارس 2025، توصیه می کنیم از android-latest-release
به جای aosp-main
برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
تست پلتفرم اندروید
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
پروژه متن باز اندروید (AOSP) چندین ابزار و مجموعه آزمایشی برای آزمایش بخش های مختلف پیاده سازی شما ارائه می دهد. قبل از استفاده از صفحات این بخش، باید با اصطلاحات زیر آشنا باشید:
- دستگاه سازگار با اندروید
- دستگاهی که می تواند هر برنامه شخص ثالث نوشته شده توسط توسعه دهندگان شخص ثالث را با استفاده از Android SDK و NDK اجرا کند. دستگاههای سازگار با Android باید از الزامات سند تعریف سازگاری (CDD) پیروی کنند و مجموعه تست سازگاری (CTS) را بگذرانند. دستگاههای سازگار با Android واجد شرایط شرکت در اکوسیستم Android هستند، که شامل مجوز بالقوه Google Play، مجوز بالقوه مجموعه برنامهها و APIهای سرویسهای تلفن همراه Google (GMS) و استفاده از علامت تجاری Android است. هر کسی میتواند از کد منبع اندروید استفاده کند، اما برای اینکه بخشی از اکوسیستم اندروید در نظر گرفته شود، دستگاه باید با اندروید سازگار باشد.
- مصنوع
- گزارش مربوط به ساخت که عیب یابی محلی را امکان پذیر می کند.
- سند تعریف سازگاری (CDD)
- سندی که نرمافزار و سختافزار مورد نیاز دستگاههای سازگار با Android را برمیشمارد.
- مجموعه تست سازگاری (CTS)
یک مجموعه آزمایشی رایگان و تجاری، که برای دانلود به صورت باینری یا منبع در AOSP در دسترس است. CTS مجموعهای از تستهای واحد است که برای ادغام در گردش کار روزانه شما طراحی شده است. هدف CTS آشکارسازی ناسازگاریها و اطمینان از سازگاری نرمافزار در طول فرآیند توسعه است.
تستهای CTS و پلتفرم متقابلاً منحصر به فرد نیستند. در اینجا چند دستورالعمل کلی وجود دارد:
- اگر آزمایشی صحت توابع یا رفتارهای API فریمورک را تأیید میکند و آزمایش باید در شرکای OEM اجرا شود، باید در CTS باشد.
- اگر آزمایشی برای گرفتن رگرسیون ها در طول توسعه پلتفرم در نظر گرفته شده است و ممکن است برای انجام به مجوز ممتاز نیاز داشته باشد و ممکن است به جزئیات پیاده سازی وابسته باشد (همانطور که در AOSP منتشر شده است)، باید یک آزمایش پلت فرم باشد.
- خدمات تلفن همراه گوگل (GMS)
مجموعهای از برنامهها و APIهای Google که میتوانند از قبل روی دستگاهها نصب شوند.
- GoogleTest (GTest)
یک چارچوب تست و تمسخر ++C. باینریهای GTest معمولاً به لایههای انتزاعی سطح پایینتر دسترسی دارند یا IPC خام را در برابر سرویسهای مختلف سیستم انجام میدهند. رویکرد تست برای GTest معمولاً با سرویس در حال آزمایش همراه است. CTS شامل چارچوب GTest است.
- تست ابزار دقیق
یک محیط اجرای آزمایشی ویژه که توسط دستور am instrument
راه اندازی شده است، که در آن فرآیند برنامه هدفمند مجدداً راه اندازی شده و با زمینه اصلی برنامه شروع می شود و یک رشته ابزار دقیق در داخل ماشین مجازی فرآیند برنامه شروع می شود. CTS شامل تست های ابزار دقیق است.
- Logcat
یک ابزار خط فرمان که گزارشی از پیامهای سیستم را ایجاد میکند، از جمله پشتههایی از زمانی که دستگاه خطا میدهد و پیامهایی که از برنامه خود با کلاس Log
نوشتهاید.
- چوب بری
استفاده از گزارش برای پیگیری رویدادهای سیستم کامپیوتری، مانند خطاها. ورود به سیستم اندروید به دلیل ترکیبی از استانداردهای استفاده شده که در ابزار Logcat ترکیب شده اند، پیچیده است.
- پس از ارسال آزمون
یک تست اندروید که زمانی انجام می شود که یک پچ جدید به یک شاخه هسته مشترک متعهد شود. با وارد کردن aosp_kernel
به عنوان یک نام جزئی شاخه، می توانید لیستی از شاخه های هسته را با نتایج موجود مشاهده کنید. برای مثال، نتایج مربوط به android-mainline
میتوانید در https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid پیدا کنید.
- آزمون را از پیش ارسال کنید
تستی که برای جلوگیری از وارد شدن خرابی ها به هسته های رایج استفاده می شود.
- فدراسیون تجارت
Tradefed نیز نامیده می شود، یک چارچوب آزمایشی پیوسته که برای اجرای تست ها بر روی دستگاه های اندرویدی طراحی شده است. به عنوان مثال، Tradefed برای اجرای تست های Compatibility Test Suite و Vendor Test Suite استفاده می شود.
- مجموعه تست فروشنده (VTS)
مجموعه ای از قابلیت های گسترده برای آزمایش اندروید، ترویج فرآیند توسعه مبتنی بر آزمایش، و خودکارسازی لایه انتزاعی سخت افزار (HAL) و آزمایش هسته سیستم عامل.
انواع تست پلت فرم
یک تست پلت فرم معمولاً با یک یا چند سرویس سیستم Android یا لایههای HAL تعامل دارد، عملکردهای موضوع مورد آزمایش را اعمال میکند و صحت نتیجه آزمایش را تأیید میکند. آزمایش پلت فرم ممکن است:
- (نوع 1) APIهای فریمورک را با استفاده از فریم ورک اندروید تمرین کنید. API های خاص در حال اجرا می تواند شامل موارد زیر باشد:
- API های عمومی در نظر گرفته شده برای برنامه های شخص ثالث
- APIهای مخفی در نظر گرفته شده برای برنامههای دارای امتیاز، یعنی APIهای سیستم یا APIهای خصوصی (
@hide
، یا protected
، package private
)
- (نوع 2) خدمات سیستم اندروید را با استفاده از بایندر خام یا پروکسی های IPC به طور مستقیم فراخوانی کنید.
- (نوع 3) با استفاده از API های سطح پایین یا رابط های IPC مستقیماً با HAL ها تعامل داشته باشید.
تستهای نوع 1 و 2 معمولاً تستهای ابزار دقیق هستند، در حالی که تستهای نوع 3 معمولاً GTest هستند.
بعدش چی؟
در اینجا لیستی از اسناد وجود دارد که می توانید برای اطلاعات دقیق تر بخوانید:
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],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)."]]