ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release
แทน aosp-main
เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
ตรวจสอบสถานะระบบ
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
โปรแกรมตรวจสอบสถานะของระบบ (SSC) จะกำหนดไว้ในการกำหนดค่าระดับชุดซอฟต์แวร์และทำงานระหว่างแต่ละโมดูล โดยจะตรวจสอบว่าโมดูลมีการเปลี่ยนแปลงหรือไม่ และไม่ได้กู้คืนสถานะบางอย่าง เช่น การเปลี่ยนค่าพร็อพเพอร์ตี้ของระบบ
SSC ส่วนใหญ่ใช้เพื่อให้มั่นใจว่าผู้เขียนโมดูลจะไม่ลืมล้างข้อมูลหลังจากการทดสอบ แต่หากลืม ให้ระบุร่องรอยเพื่อให้แก้ไขได้
การใช้งานรองคือการกู้คืนสถานะเดิมเมื่อเป็นไปได้ เช่น การปิด Keyguard หากเปิดค้างไว้
คําจํากัดความ XML ของเครื่องมือตรวจสอบสถานะระบบ
<system_checker class="com.android.tradefed.suite.checker.KeyguardStatusChecker" />
<system_checker class="com.android.tradefed.suite.checker.LeakedThreadStatusChecker" />
<system_checker class="com.android.tradefed.suite.checker.SystemServerStatusChecker" />
SSC จะกำหนดไว้ในแท็ก system_checker
ในการกําหนดค่า Tradefed
XML
การใช้งาน
SSC ทุกรายการต้องใช้ISystemStatusChecker
อินเทอร์เฟซ ซึ่งมี 2 วิธีการหลัก ได้แก่ preExecutionCheck
และ postExecutionCheck
ที่ทำงานก่อนและหลังการเรียกใช้แต่ละโมดูล
โปรแกรมตรวจสอบอาจใช้เพียงอย่างใดอย่างหนึ่งหรือทั้ง 2 อย่างก็ได้ หากจำเป็นต้องตรวจสอบสถานะก่อนโมดูลและเปรียบเทียบกับสถานะหลังโมดูล
มีตัวอย่างการใช้งานหลายรายการใน Tradefed เราขอแนะนำให้ใช้การตรวจสอบรายการเดียวในแต่ละการใช้งานเพื่อปรับปรุงความสามารถในการนํากลับมาใช้ซ้ำ เช่น SystemServerStatusCheck
จะตรวจสอบว่ากระบวนการ system_server
รีสตาร์ทในอุปกรณ์ระหว่างการดำเนินการชุดทดสอบหรือไม่ ใน postExecutionCheck
จะเรียก deviceSoftRestarted
ซึ่งกำหนดไว้ใน NativeDevice
เพื่อตรวจสอบว่ากระบวนการ system_server
เริ่มอีกครั้งหรือไม่
การดำเนินการแต่ละรายการจะแสดงผลเป็น StatusCheckerResult
ซึ่งจะช่วยให้แฮนเดิลตัดสินใจได้ว่าควรบันทึกข้อมูลเพิ่มเติม เช่น รายงานข้อบกพร่อง หรือไม่
รายการเหล่านี้ได้รับการกําหนดไว้ใน CTS ตรงไหน
เครื่องมือตรวจสอบสถานะระบบ CTS จะกำหนดไว้ใน /test/suite_harness/tools/cts-tradefed/res/config/cts-system-checkers.xml
วิธีค้นหาข้อผิดพลาดของโปรแกรมตรวจสอบ
โดยค่าเริ่มต้น ความล้มเหลวของโปรแกรมตรวจสอบระบบจะแสดงเฉพาะในบันทึกและรายงานข้อบกพร่องที่บันทึกไว้สําหรับการเรียกใช้ที่มีชื่อตามรูปแบบ bugreport-checker-post-module-<module name>.zip
ซึ่งจะช่วยให้คุณทราบว่ารายงานข้อบกพร่องสร้างขึ้นหลังจากโมดูลใด
คุณทำให้โปรแกรมตรวจสอบระบบรายงานการทดสอบไม่ผ่านได้โดยการกําหนดตัวเลือก --report-system-checkers
เป็น true
ซึ่งส่งผลให้การทดสอบแสดงเป็น "ไม่สําเร็จ" โดยมีสาเหตุมาจากการตรวจสอบสถานะการตรวจสอบหนึ่งๆ
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา 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,["# Check system status\n\nSystem status checkers (SSCs) are defined at the suite-level configuration and\nrun between each module. They perform checks to determine if the module changed\nand didn't restore some given states, for example changing a system property\nvalue.\n\nSSCs are mainly used to ensure that module writers do not forget to clean up\nafter their tests; but if they do, provide a trace of it so it can be addressed.\n\nA secondary use is to also restore the original state when possible, for example\ndismissing the keyguard if it was left open.\n\nSystem status checker XML definition\n------------------------------------\n\n \u003csystem_checker class=\"com.android.tradefed.suite.checker.KeyguardStatusChecker\" /\u003e\n \u003csystem_checker class=\"com.android.tradefed.suite.checker.LeakedThreadStatusChecker\" /\u003e\n \u003csystem_checker class=\"com.android.tradefed.suite.checker.SystemServerStatusChecker\" /\u003e\n\nSSCs are defined under the `system_checker` tag in the Tradefed configuration\nXML.\n\nImplementation\n--------------\n\nEvery SSC must implement the [`ISystemStatusChecker`\ninterface](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/suite/checker/ISystemStatusChecker.java),\nwhich provides the two main methods `preExecutionCheck` and `postExecutionCheck`\nthat run before and after each module execution.\n\nIt's possible for a checker to implement only one of the two, or to implement\nboth if there's a need to check the state before the module and compare it to\nthe state after the module.\n\nSeveral [example\nimplementations](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/suite/checker)\nexist in Tradefed. Each implementation is recommended to focus on a single check\nto improve reusability. For example,\n[`SystemServerStatusCheck`](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/suite/checker/SystemServerStatusChecker.java)\nchecks if the `system_server` process restarted on the device during the\ntest suite execution. In the `postExecutionCheck`, it calls `deviceSoftRestarted`,\nwhich is defined in\n[`NativeDevice`](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/device/NativeDevice.java)\nto check if the `system_server` process restarted.\n\nEach operation returns\n[`StatusCheckerResult`](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/suite/checker/StatusCheckerResult.java),\nwhich lets the harness decide if additional information, like a bug report,\nshould be captured.\n\nWhere are they defined in CTS?\n------------------------------\n\nCTS system status checkers are defined in\n[/test/suite_harness/tools/cts-tradefed/res/config/cts-system-checkers.xml](https://android.googlesource.com/platform/cts/+/refs/heads/android16-release/tools/cts-tradefed/res/config/cts-system-checkers.xml).\n\nHow to find checker failures\n----------------------------\n\nBy default, system checker failures show only in the logs and as bug reports\ncaptured for the invocation with name following the format\n`bugreport-checker-post-module-\u003cmodule name\u003e.zip`.\n\nThis lets you find out after which module the bug report was generated.\n\nIt's possible to make the system checker report as a test failure itself by\nsetting the `--report-system-checkers` option to `true`. This results in a\ntest run showing as failed with the reason for failure being the status checker\nparticular check."]]