ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release
แทน aosp-main
เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
HAL ที่พร้อมใช้งานแบบไดนามิก
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
Android 9 รองรับการปิดระบบย่อยของฮาร์ดแวร์ Android แบบไดนามิกเมื่อไม่ได้ใช้งานหรือไม่จำเป็นต้องใช้งาน เช่น เมื่อผู้ใช้ไม่ได้ใช้ Wi-Fi ระบบย่อยของ Wi-Fi ไม่ควรใช้หน่วยความจำ พลังงาน หรือทรัพยากรระบบอื่นๆ ใน Android เวอร์ชันก่อนหน้า HAL/ไดรเวอร์จะเปิดอยู่ในอุปกรณ์ Android ตลอดระยะเวลาที่โทรศัพท์ Android บูต
การใช้การปิดระบบแบบไดนามิกเกี่ยวข้องกับการเดินสายข้อมูลและการดำเนินการกระบวนการแบบไดนามิกตามที่อธิบายไว้ในส่วนต่อไปนี้
การเปลี่ยนแปลงคำจำกัดความ HAL
การปิดระบบแบบไดนามิกต้องใช้ข้อมูลเกี่ยวกับกระบวนการที่ให้บริการอินเทอร์เฟซ HAL ใด (ข้อมูลนี้อาจมีประโยชน์ในบริบทอื่นๆ ในภายหลังด้วย) รวมถึงไม่เริ่มกระบวนการในการบูตและไม่เริ่มกระบวนการอีกครั้ง (จนกว่าจะขออีกครั้ง) เมื่อกระบวนการออก
# some init.rc script associated with the HAL
service vendor.some-service-name /vendor/bin/hw/some-binary-service
# init language extension, provides information of what service is served
# if multiple interfaces are served, they can be specified one on each line
interface android.hardware.light@2.0::ILight default
# restarted if hwservicemanager dies
# would also cause the hal to start early during boot if disabled wasn't set
class hal
# will not be restarted if it exits until it is requested to be restarted
oneshot
# will only be started when requested
disabled
# ... other properties
การเปลี่ยนแปลงใน init และ hwservicemanager
การปิดระบบแบบไดนามิกยังกำหนดให้ hwservicemanager
ต้องบอก init
ให้เริ่มบริการที่ขอ ใน Android 9
init
มีข้อความควบคุมเพิ่มเติม 3 รายการ (เช่น
ctl.start
) ได้แก่ ctl.interface_start
,
ctl.interface_stop
และ ctl.interface_restart
ข้อความเหล่านี้สามารถใช้เป็นสัญญาณให้ init
เปิดและปิดอินเทอร์เฟซฮาร์ดแวร์บางอย่าง เมื่อมีการขอบริการและยังไม่ได้ลงทะเบียน hwservicemanager
จะขอให้เริ่มบริการ แต่ HAL แบบไดนามิกไม่จำเป็นต้องใช้สิ่งเหล่านี้
กำหนด HAL Exit
ใน Android 9 คุณต้องกำหนดการออกของ HAL ด้วยตนเอง สําหรับ Android 10 ขึ้นไป คุณสามารถกําหนดได้ด้วยวงจรอัตโนมัติ
การปิดระบบแบบไดนามิกต้องใช้นโยบายหลายรายการในการเลือกเวลาเริ่มต้น HAL และเวลาปิด HAL หาก HAL ตัดสินใจที่จะออกด้วยเหตุผลใดก็ตาม ระบบจะรีสตาร์ท HAL โดยอัตโนมัติเมื่อจําเป็นต้องใช้อีกครั้งโดยใช้ข้อมูลที่ระบุไว้ในคําจํากัดความ HAL และโครงสร้างพื้นฐานที่ได้จากการเปลี่ยนแปลง init
และ hwservicemanager
ซึ่งอาจใช้กลยุทธ์ต่างๆ 2-3 อย่าง ได้แก่
- HAL อาจเลือกเรียก exit กับตัวเองได้หากมีผู้เรียก API ที่คล้ายกันหรือเรียก API "ปิด" คุณต้องระบุลักษณะการทํางานนี้ในอินเทอร์เฟซ HAL ที่เกี่ยวข้อง
- HAL สามารถปิดเครื่องได้เมื่องานเสร็จสมบูรณ์ (บันทึกไว้ในไฟล์ HAL)
วงจรอัตโนมัติ
Android 10 เพิ่มการรองรับเคอร์เนลและ hwservicemanager
มากขึ้น ซึ่งช่วยให้ HAL ปิดโดยอัตโนมัติได้เมื่อไม่มีไคลเอ็นต์ หากต้องการใช้ฟีเจอร์นี้ ให้ทำตามขั้นตอนทั้งหมดในการเปลี่ยนแปลงคำจำกัดความ HAL รวมถึงทำตามขั้นตอนต่อไปนี้
- ลงทะเบียนบริการใน C++ ด้วย
LazyServiceRegistrar
แทนฟังก์ชันสมาชิก registerAsService
ตัวอย่างเช่น
// only one instance of LazyServiceRegistrar per process
LazyServiceRegistrar registrar;
registrar.registerAsService(myHidlService /* , "default" */);
- ยืนยันว่าไคลเอ็นต์ HAL จะเก็บการอ้างอิงไปยัง HAL ระดับบนสุด (อินเทอร์เฟซที่ลงทะเบียนกับ
hwservicemanager
) ไว้เฉพาะเมื่อใช้งานเท่านั้น เพื่อหลีกเลี่ยงความล่าช้าหากมีการทิ้งข้อมูลอ้างอิงนี้ในเธรด hwbinder ที่ยังคงทำงานอยู่ ไคลเอ็นต์ควรเรียกใช้ IPCThreadState::self()->flushCommands()
ด้วยหลังจากทิ้งข้อมูลอ้างอิงเพื่อให้มั่นใจว่าไดรเวอร์ Binder จะได้รับแจ้งเกี่ยวกับการเปลี่ยนแปลงจำนวนข้อมูลอ้างอิงที่เกี่ยวข้อง
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา Java และ OpenJDK เป็นเครื่องหมายการค้าหรือเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-07-26 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-26 UTC"],[],[],null,["# Dynamically available HALs\n\nAndroid 9 supports the dynamic shutdown of Android hardware subsystems when they are not in use or not needed. For example, when a user is not using Wi-Fi, the Wi-Fi subsystems should not be taking up memory, power, or other system resources. In earlier versions of Android, HALs/drivers were kept open on Android devices for the entire duration an Android phone was booted.\n\nImplementing dynamic shutdown involves wiring up data flows and executing\ndynamic processes as detailed in the following sections.\n\nChanges to HAL definitions\n--------------------------\n\nDynamic shutdown requires information on which processes serve what HAL\ninterfaces (this information may also be useful later in other contexts) as\nwell as not starting processes on boot and not restarting them (until\nrequested again) when they exit. \n\n```objective-c\n# some init.rc script associated with the HAL\nservice vendor.some-service-name /vendor/bin/hw/some-binary-service\n # init language extension, provides information of what service is served\n # if multiple interfaces are served, they can be specified one on each line\n interface android.hardware.light@2.0::ILight default\n # restarted if hwservicemanager dies\n # would also cause the hal to start early during boot if disabled wasn't set\n class hal\n # will not be restarted if it exits until it is requested to be restarted\n oneshot\n # will only be started when requested\n disabled\n # ... other properties\n```\n\nChanges to init and hwservicemanager\n------------------------------------\n\nDynamic shutdown also requires the `hwservicemanager` to tell\n`init` to start requested services. In Android 9,\n`init` includes three additional control messages (e.g.\n`ctl.start`): `ctl.interface_start`,\n`ctl.interface_stop`, and `ctl.interface_restart`.\nThese messages can be used to signal `init` to bring up and down\nspecific hardware interfaces. When a service is requested and isn't\nregistered, `hwservicemanager` requests that the service be\nstarted. However, dynamic HALs don't require using any of these.\n\nDetermine HAL exit\n------------------\n\nIn Android 9, HAL exit has to be manually\ndetermined. For Android 10 and higher, it can also\nbe determined with\n[automatic lifecycles](#automatic-lifecycles).\n\nDynamic shutdown requires multiple policies for deciding when to start a\nHAL and when to shutdown a HAL. If a HAL decides to exit for any reason, it\nwill automatically be restarted when it is needed again using the information\nprovided in the HAL definition and the infrastructure provided by changes to\n`init` and `hwservicemanager`. This could involve a\ncouple of different strategies, including:\n\n- A HAL could choose to call exit on itself if someone calls a close or similar API on it. This behavior must be specified in the corresponding HAL interface.\n- HALs can shut down when their task is completed (documented in the HAL file).\n\nAutomatic lifecycles\n--------------------\n\nAndroid 10 adds more support to the kernel and\n`hwservicemanager`, which allows HALs to shut down automatically\nwhenever they have no clients. To use this feature, do all of the steps in\n[Changes to HAL definitions](#changes-HAL-definitions) as well\nas:\n\n- Register the service in C++ with `LazyServiceRegistrar` instead of the member function, `registerAsService`, for example: \n\n ```scilab\n // only one instance of LazyServiceRegistrar per process\n LazyServiceRegistrar registrar;\n registrar.registerAsService(myHidlService /* , \"default\" */);\n ```\n- Verify that the HAL client keeps a reference to the top-level HAL (the interface registered with `hwservicemanager`) only when it's in use. To avoid delays if this reference is dropped on a hwbinder thread that continues to execute, the client should also call `IPCThreadState::self()-\u003eflushCommands()` after dropping the reference to ensure that the binder driver is notified of the associated reference count changes."]]