สภาพแวดล้อมรันไทม์ของฮับบริบท (CHRE)

สมาร์ทโฟนมีโปรเซสเซอร์หลายตัว โดยแต่ละตัวจะเพิ่มประสิทธิภาพให้ทำงานอย่างแตกต่างกัน แต่ Android ทำงานได้บนโปรเซสเซอร์เพียงตัวเดียวเท่านั้น ซึ่งก็คือแอปพลิเคชันประมวลผล (AP) AP ได้รับการปรับแต่งให้มีประสิทธิภาพยอดเยี่ยมสำหรับกรณีการใช้งานแบบเปิดหน้าจอ เช่น การเล่นเกม แต่ใช้พลังงานมากเกินไปที่จะรองรับฟีเจอร์ที่ต้องประมวลผลเป็นระยะเวลาสั้นๆ บ่อยครั้งตลอดเวลา แม้ว่าหน้าจอจะปิดอยู่ก็ตาม โปรเซสเซอร์ขนาดเล็กจะจัดการกับปริมาณงานเหล่านี้ได้อย่างมีประสิทธิภาพมากขึ้น ทำงานให้เสร็จสมบูรณ์โดยไม่ส่งผลกระทบต่ออายุการใช้งานแบตเตอรี่อย่างเห็นได้ชัด อย่างไรก็ตาม สภาพแวดล้อมของซอฟต์แวร์ในโปรเซสเซอร์ที่ใช้พลังงานต่ำเหล่านี้มีข้อจำกัดมากกว่าและอาจแตกต่างกันไป ทำให้การพัฒนาข้ามแพลตฟอร์มทำได้ยาก

สภาพแวดล้อมรันไทม์ของฮับบริบท (CHRE) เป็นแพลตฟอร์มทั่วไปสำหรับการเรียกใช้แอปในโปรเซสเซอร์พลังงานต่ำ โดยมี API ที่ใช้งานง่ายเป็นมาตรฐานและเหมาะสำหรับการฝัง CHRE ช่วยให้ OEM ของอุปกรณ์และพาร์ทเนอร์ที่เชื่อถือได้สามารถถ่ายโอนการประมวลผลจาก AP ได้อย่างง่ายดาย เพื่อประหยัดแบตเตอรี่และปรับปรุงประสบการณ์ของผู้ใช้ในด้านต่างๆ รวมถึงเปิดใช้ฟีเจอร์ที่ทำงานอยู่ตลอดเวลาและรับรู้ตามบริบท โดยเฉพาะฟีเจอร์ที่เกี่ยวข้องกับการใช้แมชชีนเลิร์นนิงในการวัดค่าสภาพแวดล้อม

หัวข้อสำคัญ

CHRE คือสภาพแวดล้อมซอฟต์แวร์ที่แอปเนทีฟขนาดเล็กที่เรียกว่า Nanoapp ทำงานบนโปรเซสเซอร์พลังงานต่ำและโต้ตอบกับระบบพื้นฐานผ่าน CHRE API ทั่วไป การติดตั้งใช้งาน CHRE แบบข้ามแพลตฟอร์มที่รวมอยู่ใน AOSP จะช่วยเร่งการติดตั้งใช้งาน CHRE API อย่างถูกต้อง การใช้งานอ้างอิงประกอบด้วยโค้ดทั่วไปและข้อมูลทั่วไปเกี่ยวกับฮาร์ดแวร์และซอฟต์แวร์พื้นฐานผ่านชุดเลเยอร์การแยกแยะแพลตฟอร์ม (PAL) Nanoapps มักจะเชื่อมโยงกับแอปไคลเอ็นต์อย่างน้อย 1 แอปที่ทำงานใน Android ซึ่งโต้ตอบกับ CHRE และ Nanoapps ผ่านการเข้าถึงแบบจำกัดการเข้าถึง ContextHubManager API ของระบบ

ในระดับสูง สถาปัตยกรรมของ CHRE และ Android นั้นมีความคล้ายคลึงกัน อย่างไรก็ตาม มีความแตกต่างที่สำคัญบางประการ:

  • CHRE รองรับเฉพาะการเรียกใช้ NanoApp ที่พัฒนาด้วยโค้ดเนทีฟ (C หรือ C++) และไม่รองรับ Java
  • CHRE ไม่เปิดให้แอป Android ของบุคคลที่สามใช้เนื่องจากข้อจำกัดด้านทรัพยากรและข้อจำกัดด้านความปลอดภัย มีเพียงแอปที่ระบบเชื่อถือเท่านั้นที่เข้าถึงได้

นอกจากนี้ ยังมีความแตกต่างที่สำคัญระหว่างแนวคิด CHRE กับฮับเซ็นเซอร์ แม้ว่าการใช้ฮาร์ดแวร์เดียวกันเพื่อติดตั้งใช้งานฮับเซ็นเซอร์และ CHRE จะเป็นเรื่องปกติ แต่ CHRE เองไม่ได้ให้ความสามารถของเซ็นเซอร์ที่จําเป็นต่อ Android Sensors HAL CHRE จะเชื่อมโยงกับ HAL ของฮับบริบท และทำหน้าที่เป็นไคลเอ็นต์ของเฟรมเวิร์กเซ็นเซอร์เฉพาะอุปกรณ์เพื่อรับข้อมูลเซ็นเซอร์โดยไม่เกี่ยวข้องกับ AP

สถาปัตยกรรมเฟรมเวิร์ก CHRE

รูปที่ 1 สถาปัตยกรรมเฟรมเวิร์ก CHRE

HAL ของฮับบริบท

เลเยอร์การแยกแยะฮาร์ดแวร์ (HAL) ของฮับบริบทคืออินเทอร์เฟซระหว่างเฟรมเวิร์ก Android กับการใช้งาน CHRE ของอุปกรณ์ ซึ่งกำหนดไว้ที่ hardware/interfaces/contexthub HAL ของฮับบริบทจะกำหนด API ที่เฟรมเวิร์ก Android ใช้ค้นพบฮับบริบทและนาโนแอปที่พร้อมใช้งาน โต้ตอบกับนาโนแอปเหล่านั้นผ่านการรับส่งข้อความ และอนุญาตให้โหลดและยกเลิกการโหลดนาโนแอป การใช้งานข้อมูลอ้างอิงของ HAL ของ Context Hub ที่ทำงานร่วมกับการใช้งานข้อมูลอ้างอิงของ CHRE อยู่ที่ system/chre/host

ในกรณีที่เอกสารประกอบนี้ขัดแย้งกับคำจำกัดความ HAL ให้ถือว่าคำจำกัดความ HAL มีความสำคัญเหนือกว่า

การเริ่มต้น

เมื่อ Android เริ่มทำงาน ContextHubService จะเรียกใช้ฟังก์ชัน getHubs() HAL เพื่อตรวจสอบว่ามีฮับบริบทใดในอุปกรณ์หรือไม่ วิธีนี้เป็นการบล็อกและการเรียกใช้ครั้งเดียว ดังนั้นจึงต้องดำเนินการอย่างรวดเร็วเพื่อไม่ให้เกิดความล่าช้าในการเปิดเครื่อง และต้องแสดงผลลัพธ์ที่แม่นยำ เนื่องจากฮับบริบทใหม่จะใช้ไม่ได้ในภายหลัง

โหลดและยกเลิกการโหลดนาโนแอป

ฮับบริบทอาจมีชุดนาโนแอปที่รวมอยู่ในรูปภาพอุปกรณ์และโหลดเมื่อ CHRE เริ่มทำงาน เรียกกันว่า "นาโนแอปที่โหลดไว้ล่วงหน้า" และควรรวมอยู่ในการตอบกลับ queryApps() ครั้งแรกที่เป็นไปได้

นอกจากนี้ Context Hub HAL ยังรองรับการโหลดและยกเลิกการโหลด NanoApp แบบไดนามิกในรันไทม์ผ่านฟังก์ชัน loadNanoApp() และ unloadNanoApp() Nanoapps ให้บริการใน HAL ในรูปแบบไบนารีเฉพาะสำหรับการใช้งานฮาร์ดแวร์และซอฟต์แวร์ CHRE ของอุปกรณ์

หากการติดตั้งใช้งานสำหรับการโหลดนาโนแอปเกี่ยวข้องกับการเขียนลงในหน่วยความจำแบบไม่ระเหย เช่น พื้นที่เก็บข้อมูลแฟลชที่เชื่อมต่อกับโปรเซสเซอร์ที่เรียกใช้ CHRE การติดตั้งใช้งาน CHRE จะต้องบูตขึ้นด้วยนาโนแอปแบบไดนามิกเหล่านี้ในสถานะปิดอยู่เสมอ ซึ่งหมายความว่าจะไม่มีโค้ดของ Nanoapp ใดทำงานจนกว่าจะได้รับคำขอ enableNanoapp() ผ่าน HAL นาโนแอปที่โหลดไว้ล่วงหน้าจะเริ่มต้นได้ในสถานะเปิดใช้

ฮับบริบทรีสตาร์ท

แม้ว่า CHRE จะไม่รีสตาร์ทในระหว่างการดำเนินการตามปกติ แต่อาจจำเป็นต้องกู้คืนจากเงื่อนไขที่ไม่คาดคิด เช่น การพยายามเข้าถึงที่อยู่หน่วยความจำที่ไม่ได้แมป ในกรณีเหล่านี้ CHRE จะรีสตาร์ทโดยอิสระจาก Android HAL จะแจ้งให้ Android ทราบผ่านเหตุการณ์ RESTARTED ซึ่งจะต้องส่งหลังจากที่ CHRE ได้รับการรีนิไทซ์ใหม่แล้วเท่านั้นถึงจะยอมรับคําขอใหม่ได้ เช่น queryApps()

ภาพรวมของระบบ CHRE

CHRE ออกแบบจากสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ โดยหน่วยการคำนวณหลักคือเหตุการณ์ที่ส่งไปยังจุดแรกเข้าของการจัดการเหตุการณ์ของ Nanoapp แม้ว่าเฟรมเวิร์ก CHRE จะเป็นแบบมัลติเทรดได้ แต่ nanoapp ดังกล่าวจะไม่ดำเนินการจากเทรดหลายรายการพร้อมกัน เฟรมเวิร์ก CHRE จะโต้ตอบกับนาโนแอปหนึ่งๆ ผ่านจุดแรกเข้าของนาโนแอป 1 ใน 3 จุด (nanoappStart(), nanoappHandleEvent() และ nanoappEnd()) หรือผ่านคอลแบ็กที่ระบุในการเรียก CHRE API ก่อนหน้า และนาโนแอปจะโต้ตอบกับเฟรมเวิร์ก CHRE และระบบพื้นฐานผ่าน CHRE API CHRE API มีชุดความสามารถพื้นฐาน รวมถึงสิ่งอํานวยความสะดวกในการเข้าถึงสัญญาณตามบริบท ซึ่งรวมถึงเซ็นเซอร์, GNSS, Wi-Fi, WWAN และเสียง และสามารถขยายความสามารถเพิ่มเติมที่เจาะจงตามผู้ให้บริการเพื่อใช้กับนาโนแอปที่เจาะจงตามผู้ให้บริการ

ระบบบิลด์

แม้ว่า Context Hub HAL และคอมโพเนนต์อื่นๆ ที่จำเป็นฝั่ง AP จะสร้างขึ้นควบคู่ไปกับ Android แต่โค้ดที่ทำงานภายใน CHRE อาจมีข้อกำหนดที่ทำให้ใช้งานร่วมกับระบบบิลด์ของ Android ไม่ได้ เช่น ต้องใช้เครื่องมือเฉพาะ ดังนั้น โปรเจ็กต์ CHRE ใน AOSP จึงมีระบบการสร้างที่เรียบง่ายซึ่งอิงตาม GNU Make เพื่อคอมไพล์ NanoApp และเฟรมเวิร์ก CHRE (ไม่บังคับ) ให้เป็นไลบรารีที่ผสานรวมกับระบบได้ ผู้ผลิตอุปกรณ์ที่เพิ่มการรองรับ CHRE ควรผสานรวมการรองรับระบบบิลด์สำหรับอุปกรณ์เป้าหมายของตนไว้ใน AOSP

CHRE API เขียนขึ้นตามมาตรฐานภาษา C99 และการใช้งานอ้างอิงใช้ชุดย่อยของ C++11 แบบจํากัดซึ่งเหมาะกับแอปที่มีทรัพยากรจํากัด

API CHRE

CHRE API คือคอลเล็กชันไฟล์ส่วนหัว C ที่กําหนดอินเทอร์เฟซซอฟต์แวร์ระหว่างนาโนแอปกับระบบ ภาษานี้ออกแบบมาเพื่อให้โค้ดของ Nanoapp เข้ากันได้กับอุปกรณ์ทั้งหมดที่รองรับ CHRE ซึ่งหมายความว่าไม่จำเป็นต้องแก้ไขซอร์สโค้ดของ Nanoapp เพื่อรองรับประเภทอุปกรณ์ใหม่ แต่อาจต้องคอมไพล์อีกครั้งโดยเฉพาะสำหรับชุดคำสั่งของโปรเซสเซอร์หรือ Application Binary Interface (ABI) ของอุปกรณ์เป้าหมาย สถาปัตยกรรมและการออกแบบ API ของ CHRE ยังช่วยให้มั่นใจว่า Nanoapp จะใช้ร่วมกันได้กับไบนารีของ CHRE API เวอร์ชันต่างๆ ซึ่งหมายความว่า Nanoapp ไม่จำเป็นต้องคอมไพล์ใหม่เพื่อใช้งานในระบบที่ใช้ CHRE API เวอร์ชันอื่นเมื่อเทียบกับ API เป้าหมายที่ใช้คอมไพล์ Nanoapp กล่าวคือ หากไบนารีของ Nanoapp ทำงานในอุปกรณ์ที่รองรับ CHRE API v1.3 และอุปกรณ์ดังกล่าวได้รับการอัปเกรดให้รองรับ CHRE API v1.4 ไบนารีของ Nanoapp เดียวกันจะยังคงทำงานต่อไป ในทํานองเดียวกัน นาโนแอปสามารถทํางานบน CHRE API v1.2 และสามารถระบุได้เมื่อรันไทม์ว่าต้องใช้ความสามารถจาก API v1.3 เพื่อให้ใช้งานได้ หรือสามารถทํางานได้หรือไม่ ซึ่งอาจมีการลดระดับฟีเจอร์อย่างราบรื่น

CHRE API เวอร์ชันใหม่จะเปิดตัวพร้อมกับ Android อย่างไรก็ตาม เนื่องจากการติดตั้งใช้งาน CHRE เป็นส่วนหนึ่งของการติดตั้งใช้งานของผู้ให้บริการ เวอร์ชัน CHRE API ที่รองรับในอุปกรณ์จึงไม่จำเป็นต้องเชื่อมโยงกับเวอร์ชัน Android

ข้อมูลสรุปของเวอร์ชัน

CHRE API เป็นไปตามการกำหนดเวอร์ชันแบบเชิงความหมายเช่นเดียวกับรูปแบบการกำหนดเวอร์ชัน HIDL ของ Android เวอร์ชันหลักจะระบุความเข้ากันได้ของไบนารี ส่วนเวอร์ชันรองจะเพิ่มขึ้นเมื่อมีการเปิดตัวฟีเจอร์ที่ใช้งานร่วมกันย้อนหลังได้ CHRE API ประกอบด้วยคำอธิบายประกอบซอร์สโค้ดเพื่อระบุเวอร์ชันที่เปิดตัวฟังก์ชันหรือพารามิเตอร์ เช่น @since v1.1

การติดตั้งใช้งาน CHRE ยังแสดงเวอร์ชันแพตช์เฉพาะแพลตฟอร์มผ่านchreGetVersion() ซึ่งจะระบุเวลาที่ทำการแก้ไขข้อบกพร่องหรือการอัปเดตเล็กน้อยในการติดตั้งใช้งาน

เวอร์ชัน 1.0 (Android 7)

รวมถึงรองรับเซ็นเซอร์และความสามารถหลักของนาโนแอป เช่น เหตุการณ์และตัวจับเวลา

เวอร์ชัน 1.1 (Android 8)

แนะนำความสามารถด้านตำแหน่งผ่านตำแหน่ง GNSS และการวัดผลดิบ การสแกน Wi-Fi และข้อมูลเครือข่ายมือถือ รวมถึงการปรับแต่งทั่วไปเพื่อเปิดใช้การสื่อสารระหว่างแอปย่อยกับแอปย่อย และการปรับปรุงอื่นๆ

เวอร์ชัน 1.2 (Android 9)

เพิ่มการรองรับข้อมูลจากไมโครโฟนพลังงานต่ำ การวัดระยะทาง RTT ของ Wi-Fi การแจ้งเตือน AP ตื่นและเข้าสู่โหมดสลีป และการปรับปรุงอื่นๆ

เวอร์ชัน 1.3 (Android 10)

ปรับปรุงความสามารถที่เกี่ยวข้องกับข้อมูลการปรับเทียบเซ็นเซอร์ เพิ่มการรองรับการล้างข้อมูลเซ็นเซอร์แบบเป็นกลุ่มตามคําขอ กําหนดประเภทเซ็นเซอร์ตรวจจับการเดิน และขยายเหตุการณ์ตําแหน่ง GNSS ด้วยช่องความแม่นยําเพิ่มเติม

เวอร์ชัน 1.4 (Android 11)

เพิ่มการรองรับข้อมูลเซลล์ 5G, ดัมพ์การแก้ไขข้อบกพร่องของ NanoApp และการปรับปรุงอื่นๆ

ฟีเจอร์ของระบบที่ต้องระบุ

แม้ว่าแหล่งที่มาของสัญญาณตามบริบท เช่น เซ็นเซอร์ จะจัดหมวดหมู่เป็นพื้นที่ฟีเจอร์ที่ไม่บังคับ แต่การใช้งาน CHRE ทั้งหมดต้องใช้ฟังก์ชันหลัก 2-3 รายการ ซึ่งรวมถึง API หลักของระบบ เช่น API สำหรับการตั้งค่าตัวจับเวลา การรับส่งอีเมลบนตัวประมวลผลแอปพลิเคชัน การบันทึก และอื่นๆ ดูรายละเอียดทั้งหมดได้ที่ส่วนหัว API

นอกจากฟีเจอร์หลักของระบบที่กำหนดไว้ใน CHRE API แล้ว ยังมีฟีเจอร์ระดับระบบ CHRE ที่ต้องระบุที่ระดับ HAL ของ Context Hub ด้วย สิ่งสำคัญที่สุดคือความสามารถในการโหลดและยกเลิกการโหลดนาโนแอปแบบไดนามิก

ไลบรารีมาตรฐาน C/C++

เพื่อเป็นการลดการใช้งานหน่วยความจำและความซับซ้อนของระบบ ระบบต้องใช้ CHRE เพื่อรองรับเฉพาะชุดย่อยของไลบรารี C และ C++ มาตรฐานและฟีเจอร์ภาษาที่ต้องใช้การสนับสนุนรันไทม์เท่านั้น ตามหลักการเหล่านี้ ระบบจะยกเว้นฟีเจอร์บางอย่างอย่างชัดเจนเนื่องจากมีการใช้หน่วยความจำและมีการพึ่งพาระดับระบบปฏิบัติการอย่างกว้างขวาง และยกเว้นฟีเจอร์อื่นๆ เนื่องจากมี API สำหรับ CHRE โดยเฉพาะที่เหมาะสมกว่า ความสามารถต่อไปนี้ไม่ได้มีไว้สำหรับนนาแอป แม้ว่าจะไม่ใช่รายการที่ครอบคลุมทั้งหมด

  • ข้อยกเว้น C++ และข้อมูลประเภทรันไทม์ (RTTI)
  • การรองรับการแยกหลายเธรดของไลบรารีมาตรฐาน รวมถึงส่วนหัว C++11 <thread>, <mutex>, <atomic>, <future>
  • ไลบรารีอินพุต/เอาต์พุตมาตรฐาน C และ C++
  • C++ Standard Template Library (STL)
  • ไลบรารีนิพจน์ทั่วไปมาตรฐาน C++
  • การจัดสรรหน่วยความจําแบบไดนามิกผ่านฟังก์ชันมาตรฐาน (เช่น malloc, calloc, realloc, free, operator new) และฟังก์ชันมาตรฐานอื่นๆ ในไลบรารีที่ใช้การจัดสรรแบบไดนามิกโดยเนื้อแท้ เช่น std::unique_ptr
  • การแปลภาษาและการรองรับอักขระ Unicode
  • คลังวันที่และเวลา
  • ฟังก์ชันที่แก้ไขโฟลว์ปกติของโปรแกรม ซึ่งรวมถึง <setjmp.h>, <signal.h>, abort, std::terminate
  • การเข้าถึงสภาพแวดล้อมโฮสต์ ซึ่งรวมถึง system, getenv
  • POSIX และไลบรารีอื่นๆ ที่ไม่ได้รวมอยู่ในมาตรฐานภาษา C99 หรือ C++11

ในหลายกรณี ความสามารถที่เทียบเท่าจะมีอยู่ในฟังก์ชัน CHRE API และไลบรารียูทิลิตี เช่น chreLog จะใช้สำหรับการบันทึกการแก้ไขข้อบกพร่องที่กำหนดเป้าหมายไปยังระบบ Logcat ของ Android ได้ โดยโปรแกรมแบบดั้งเดิมอาจใช้ printf หรือ std::cout

ในทางตรงกันข้าม ความสามารถบางอย่างของไลบรารีมาตรฐานเป็นสิ่งจําเป็น ขึ้นอยู่กับการใช้งานแพลตฟอร์ม เพื่อแสดงสิ่งเหล่านี้ผ่านไลบรารีแบบคงที่เพื่อรวมไว้ในไบนารี nanoapp หรือโดยการเชื่อมโยงแบบไดนามิกระหว่าง nanoapp กับระบบ ซึ่งรวมถึงแต่ไม่จำกัดเพียงรายการต่อไปนี้

  • ยูทิลิตีสตริงและอาร์เรย์: memcmp, memcpy, memmove, memset, strlen

  • ไลบรารีคณิตศาสตร์: ฟังก์ชันตัวเลขทศนิยมแบบละเอียดเดี่ยวที่ใช้กันโดยทั่วไป

    • การดำเนินการพื้นฐาน: ceilf, fabsf, floorf, fmaxf, fminf, fmodf, roundf, lroundf, remainderf
    • ฟังก์ชันเลขชี้กำลังและฟังก์ชันยกกำลัง: expf, log2f, powf, sqrtf
    • ฟังก์ชันตรีโกณิตและไฮเปอร์โบลิก: sinf, cosf, tanf, asinf, acosf, atan2f, tanhf

แม้ว่าแพลตฟอร์มพื้นฐานบางแพลตฟอร์มจะรองรับความสามารถเพิ่มเติม แต่ระบบจะไม่ถือว่านาโนแอปสามารถพอร์ตไปยังการใช้งาน CHRE ได้ เว้นแต่ว่าจะมีการจำกัดการพึ่งพาภายนอกไว้ที่ฟังก์ชัน CHRE API และฟังก์ชันไลบรารีมาตรฐานที่ได้รับอนุมัติ

ฟีเจอร์เสริม

CHRE API แบ่งออกเป็นพื้นที่ฟีเจอร์เพื่อโปรโมตฮาร์ดแวร์และซอฟต์แวร์ ซึ่งถือว่าไม่บังคับจากมุมมองของ API แม้ว่าฟีเจอร์เหล่านี้อาจไม่จำเป็นต้องรองรับการใช้งาน CHRE ที่เข้ากันได้ แต่ก็อาจจำเป็นสำหรับการรองรับ Nanoapp บางอย่าง แม้ว่าแพลตฟอร์มจะไม่รองรับชุด API หนึ่งๆ แต่ Nanoapp ที่อ้างอิงฟังก์ชันเหล่านั้นต้องสร้างและโหลดได้

เซ็นเซอร์

CHRE API ช่วยให้คุณขอข้อมูลจากเซ็นเซอร์ต่างๆ ได้ ซึ่งรวมถึงตัวตรวจวัดความเร่ง เครื่องวัดการหมุน เซ็นเซอร์แม่เหล็ก เซ็นเซอร์แสงแวดล้อม และเซ็นเซอร์ตรวจหาบุคคลในบริเวณใกล้เคียง API เหล่านี้มีไว้เพื่อให้บริการชุดฟีเจอร์ที่คล้ายกับ Android Sensors API ซึ่งรวมถึงการรองรับตัวอย่างเซ็นเซอร์แบบกลุ่มเพื่อลดการใช้พลังงาน การประมวลผลข้อมูลเซ็นเซอร์ภายใน CHRE ช่วยให้การประมวลผลสัญญาณการเคลื่อนไหวใช้พลังงานน้อยลงและมีความล่าช้าต่ำกว่ามากเมื่อเทียบกับการทํางานบน AP

GNSS

CHRE มี API สำหรับขอข้อมูลตำแหน่งจากระบบดาวเทียมนำทางทั่วโลก (GNSS) ซึ่งรวมถึง GPS และกลุ่มดาวเทียมอื่นๆ ซึ่งรวมถึงคําขอแก้ไขตําแหน่งเป็นระยะๆ และข้อมูลการวัดผลดิบ แม้ว่าทั้ง 2 อย่างจะเป็นความสามารถอิสระ เนื่องจาก CHRE มีลิงก์ไปยังระบบย่อยของ GNSS โดยตรง พลังงานจึงลดลงเมื่อเทียบกับคำขอ GNSS ที่มาจาก AP เนื่องจาก AP สามารถอยู่ในโหมดสลีปได้ตลอดวงจรของเซสชันตำแหน่ง

Wi-Fi

CHRE ช่วยให้คุณโต้ตอบกับชิป Wi-Fi ได้ โดยหลักๆ แล้วเพื่อวัตถุประสงค์ในการระบุตำแหน่ง แม้ว่า GNSS จะทำงานได้ดีในสถานที่กลางแจ้ง แต่ผลลัพธ์ของการสแกน Wi-Fi จะให้ข้อมูลตำแหน่งที่แม่นยำภายในอาคารและในพื้นที่ที่พัฒนาแล้ว นอกจากการหลีกเลี่ยงค่าใช้จ่ายในการปลุก AP เพื่อทำการสแกนแล้ว CHRE ยังรับฟังผลลัพธ์ของการสแกน Wi-Fi ที่ดำเนินการโดยเฟิร์มแวร์ Wi-Fi เพื่อวัตถุประสงค์ในการเชื่อมต่อ ซึ่งโดยปกติแล้วจะไม่ส่งไปยัง AP เพื่อประหยัดพลังงาน การใช้การสแกนการเชื่อมต่อเพื่อวัตถุประสงค์ตามบริบทจะช่วยลดความถี่ในการสแกน Wi-Fi ทั้งหมด ซึ่งจะช่วยประหยัดพลังงาน

เพิ่มการรองรับ Wi-Fi ใน CHRE API v1.1 ซึ่งรวมถึงความสามารถในการตรวจสอบผลการสแกนและทริกเกอร์การสแกนตามคำขอ ความสามารถเหล่านี้ได้รับการขยายการให้บริการใน v1.2 ด้วยความสามารถในการวัดเวลาในการไปและกลับ (RTT) กับจุดเข้าใช้งานที่รองรับฟีเจอร์นี้ ซึ่งช่วยให้ระบุตำแหน่งสัมพัทธ์ได้อย่างแม่นยำ

สงครามโลกครั้งที่ 1

CHRE API มีความสามารถในการเรียกข้อมูลการระบุเซลล์สำหรับเซลล์ที่กำลังแสดงผลและเซลล์ข้างเคียง ซึ่งโดยปกติแล้วจะใช้สำหรับวัตถุประสงค์ด้านตำแหน่งแบบละเอียด

เสียง

CHRE สามารถประมวลผลข้อมูลเสียงเป็นกลุ่มๆ จากไมโครโฟนพลังงานต่ำ ซึ่งโดยทั่วไปจะใช้ประโยชน์จากฮาร์ดแวร์ที่ใช้ติดตั้งใช้งาน HAL ของ SoundTrigger การประมวลผลข้อมูลเสียงใน CHRE ช่วยให้สามารถผสานรวมข้อมูลดังกล่าวกับข้อมูลอื่นๆ เช่น เซ็นเซอร์การเคลื่อนไหว

การใช้งานอ้างอิง

โค้ดอ้างอิงสำหรับเฟรมเวิร์ก CHRE จะรวมอยู่ใน AOSP ในsystem/chre โปรเจ็กต์ที่ใช้ C++11 แม้ว่าจะไม่จําเป็นอย่างเคร่งครัด แต่เราขอแนะนําให้การติดตั้งใช้งาน CHRE ทั้งหมดอิงตามโค้ดเบสนี้เพื่อช่วยในการรักษาความสอดคล้องและเร่งการนำความสามารถใหม่ๆ มาใช้ เรามองว่าโค้ดนี้เป็นเหมือนเฟรมเวิร์กของ Android หลักเนื่องจากเป็นการใช้งาน API แบบโอเพนซอร์สที่แอปใช้ โดยทำหน้าที่เป็นพื้นฐานและมาตรฐานสำหรับความเข้ากันได้ แม้ว่าจะปรับแต่งและขยายความสามารถเฉพาะของผู้ให้บริการได้ แต่เราขอแนะนำให้รักษาโค้ดทั่วไปให้ใกล้เคียงกับข้อมูลอ้างอิงมากที่สุด การใช้งาน CHRE อ้างอิงใช้การแยกความคิดแพลตฟอร์มต่างๆ เพื่อปรับให้เข้ากับอุปกรณ์ที่ตรงตามข้อกำหนดขั้นต่ำได้ เช่นเดียวกับ HAL ของ Android

ดูรายละเอียดทางเทคนิคและคำแนะนำในการพอร์ตได้ที่ README ที่รวมอยู่ในโปรเจ็กต์ system/chre