ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release
แทน aosp-main
เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
การทดสอบแพลตฟอร์ม Android
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
โครงการโอเพนซอร์ส Android (AOSP) มีเครื่องมือและชุดทดสอบหลายชุดสําหรับการทดสอบส่วนต่างๆ ของการติดตั้งใช้งาน ก่อนใช้หน้าต่างๆ ในส่วนนี้ คุณควรทำความคุ้นเคยกับคําศัพท์ต่อไปนี้
- อุปกรณ์ที่ใช้ร่วมกับ Android ได้
- อุปกรณ์ที่เรียกใช้แอปของบุคคลที่สามที่เขียนโดยนักพัฒนาแอปบุคคลที่สามได้โดยใช้ Android SDK และ NDK อุปกรณ์ที่ใช้งานร่วมกับ Android ได้ต้องเป็นไปตามข้อกำหนดของเอกสารนิยามความเข้ากันได้ (CDD) และผ่านชุดเครื่องมือทดสอบความเข้ากันได้ (CTS) อุปกรณ์ที่เข้ากันได้กับ Android จะมีสิทธิ์เข้าร่วมในระบบนิเวศของ Android ซึ่งรวมถึงสิทธิ์ในการขอใบอนุญาตใช้ Google Play, สิทธิ์ในการขอใบอนุญาตใช้ชุดแอปและ API ของ Google Mobile Services (GMS) และสิทธิ์ในการใช้เครื่องหมายการค้า Android ทุกคนสามารถใช้ซอร์สโค้ด Android ได้ แต่อุปกรณ์ต้องใช้งานร่วมกับ Android ได้จึงจะถือว่าเป็นส่วนหนึ่งของระบบนิเวศ Android
- อาร์ติแฟกต์
- บันทึกที่เกี่ยวข้องกับบิลด์ที่ช่วยให้แก้ปัญหาได้ในพื้นที่
- เอกสารนิยามความเข้ากันได้ (CDD)
- เอกสารที่ระบุข้อกำหนดด้านซอฟต์แวร์และฮาร์ดแวร์สำหรับอุปกรณ์ที่เข้ากันได้กับ Android
- ชุดทดสอบความเข้ากันได้ (CTS)
ชุดทดสอบระดับเชิงพาณิชย์แบบไม่มีค่าใช้จ่าย ซึ่งสามารถดาวน์โหลดเป็นไฟล์ไบนารีหรือเป็นซอร์สโค้ดใน AOSP CTS คือชุดการทดสอบหน่วยที่ออกแบบมาเพื่อผสานรวมเข้ากับเวิร์กโฟลว์ประจำวัน วัตถุประสงค์ของ CTS คือเพื่อเปิดเผยความเข้ากันไม่ได้ และตรวจสอบว่าซอฟต์แวร์ยังคงเข้ากันได้ตลอดกระบวนการพัฒนา
การทดสอบ CTS และการทดสอบแพลตฟอร์มไม่ได้แยกกัน หลักเกณฑ์ทั่วไปมีดังนี้
- หากการทดสอบยืนยันความถูกต้องของฟังก์ชันหรือลักษณะการทํางานของ API เฟรมเวิร์ก และควรบังคับใช้การทดสอบกับพาร์ทเนอร์ OEM การทดสอบนั้นควรอยู่ใน CTS
- หากการทดสอบมีจุดประสงค์เพื่อตรวจหาการถดถอยระหว่างการพัฒนาแพลตฟอร์ม และอาจต้องใช้สิทธิ์ที่มีสิทธิ์ในการดำเนินการ และอาจขึ้นอยู่กับรายละเอียดการใช้งาน (ตามที่เผยแพร่ใน AOSP) การทดสอบนั้นควรเป็นการทดสอบแพลตฟอร์ม
- บริการของ Google Mobile (GMS)
ชุดแอปและ API ของ Google ที่ติดตั้งล่วงหน้าในอุปกรณ์ได้
- GoogleTest (GTest)
เฟรมเวิร์กการทดสอบและการจำลอง C++ โดยปกติแล้วไบนารีของ GTest จะเข้าถึงเลเยอร์การแยกชั้นระดับล่างหรือดำเนินการ IPC ดิบกับบริการต่างๆ ของระบบ โดยทั่วไปแล้ว แนวทางการทดสอบสำหรับ GTest จะเชื่อมโยงกับบริการที่ทดสอบอย่างใกล้ชิด CTS มีเฟรมเวิร์ก GTest
- การทดสอบการวัดคุม
สภาพแวดล้อมการเรียกใช้การทดสอบพิเศษที่เปิดใช้งานโดยคําสั่ง am instrument
ซึ่งจะรีสตาร์ทและเริ่มต้นกระบวนการของแอปเป้าหมายด้วยบริบทแอปพื้นฐาน และเริ่มเธรดเครื่องมือวัดผลภายในเครื่องเสมือนของกระบวนการแอป CTS มีการทดสอบการใช้เครื่องมือ
- Logcat
เครื่องมือบรรทัดคำสั่งที่สร้างบันทึกข้อความของระบบ ซึ่งรวมถึงสแต็กเทรซเมื่ออุปกรณ์แสดงข้อผิดพลาดและข้อความที่คุณเขียนจากแอปด้วยคลาส Log
- การบันทึก
การใช้บันทึกเพื่อติดตามเหตุการณ์ของระบบคอมพิวเตอร์ เช่น ข้อผิดพลาด การบันทึกใน 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 เพื่อเรียกใช้ชุดเครื่องมือทดสอบความเข้ากันได้และการทดสอบชุดเครื่องมือทดสอบของผู้ให้บริการ
- ชุดทดสอบของผู้ให้บริการ (VTS)
ชุดความสามารถที่ครอบคลุมสำหรับการทดสอบ Android, การส่งเสริมกระบวนการพัฒนาที่ขับเคลื่อนโดยทดสอบ และการทำให้การทดสอบเลเยอร์การแยกแยะฮาร์ดแวร์ (HAL) และการทดสอบเคอร์เนลระบบปฏิบัติการเป็นแบบอัตโนมัติ
ประเภทการทดสอบแพลตฟอร์ม
การทดสอบแพลตฟอร์มมักจะโต้ตอบกับบริการของระบบ Android หรือเลเยอร์ HAL อย่างน้อย 1 รายการ ทดสอบฟังก์ชันการทำงานของสิ่งที่ทดสอบ และยืนยันความถูกต้องของผลลัพธ์การทดสอบ การทดสอบแพลตฟอร์มอาจมีลักษณะดังนี้
- (ประเภทที่ 1) ทดสอบ API ของเฟรมเวิร์กโดยใช้เฟรมเวิร์ก Android API ที่ใช้งานอยู่อาจรวมถึง API ต่อไปนี้
- API สาธารณะที่มีไว้สำหรับแอปของบุคคลที่สาม
- API ที่ซ่อนไว้มีไว้สําหรับแอปที่มีสิทธิ์ ซึ่งได้แก่ API ของระบบหรือ API ส่วนตัว (
@hide
หรือ protected
, package private
)
- (ประเภท 2) เรียกใช้บริการระบบ Android โดยใช้ Binder ดิบหรือพร็อกซี IPC โดยตรง
- (ประเภท 3) โต้ตอบกับ HAL โดยตรงโดยใช้ 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)."]]