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

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

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

หัวข้อสำคัญ

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

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

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

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

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

Context Hub HAL

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

ในกรณีที่เอกสารนี้ขัดแย้งกับคำจำกัดความของ HAL คำจำกัดความของ HAL จะมีผลบังคับใช้

การเริ่มต้น

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

โหลดและยกเลิกการโหลด nanoapp

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

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

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

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

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

ภาพรวมระบบ CHRE

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

ระบบบิลด์

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

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

CHRE API

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

ดูข้อมูลสรุปของแต่ละเวอร์ชันได้ที่ version.h

ฟีเจอร์ของระบบที่จำเป็น

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

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

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

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

• ข้อยกเว้น C++ และข้อมูลประเภทรันไทม์ (RTTI)
• การรองรับมัลติเธรดของไลบรารีมาตรฐาน ซึ่งรวมถึงส่วนหัว C++11 <thread>, <mutex>, <atomic>, <future>
• ไลบรารีอินพุต/เอาต์พุตมาตรฐาน C และ C++
• ไลบรารีเทมเพลตมาตรฐาน C++ (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

แม้ว่าแพลตฟอร์มพื้นฐานบางแพลตฟอร์มจะรองรับฟังก์ชันการทำงานเพิ่มเติม แต่ระบบจะไม่ถือว่า nanoapp สามารถทำงานได้ใน CHRE API เวอร์ชันต่างๆ เว้นแต่ว่า nanoapp จะจำกัดการพึ่งพาอาศัยกันภายนอกไว้ที่ฟังก์ชัน 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) กับจุดเข้าใช้งานที่รองรับฟีเจอร์นี้ ซึ่งช่วยให้กำหนดตำแหน่งสัมพัทธ์ได้อย่าง แม่นยำ

WWAN

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

เสียง

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

บลูทูธ

CHRE มี API ที่รองรับฟังก์ชันการทำงานของบลูทูธบางส่วนซึ่งได้รับประโยชน์จากการโอนการประมวลผลไปยังโปรเซสเซอร์พลังงานต่ำ CHRE ช่วยให้ nanoapp ทำการสแกน BLE, ตรวจสอบ RSSI และประมวลผลข้อมูลการโฆษณา BLE ได้โดยไม่ต้องปลุก AP นอกจากนี้ ยังสามารถย้ายการเป็นเจ้าของของการเชื่อมต่อซ็อกเก็ตบลูทูธที่สร้างขึ้นไปยังโดเมนการลดภาระ ซึ่งต้องใช้พลังงานน้อยลงในการบำรุงรักษา และช่วยให้ nanoapp สื่อสารผ่านการเชื่อมต่อซ็อกเก็ต BLE ที่ลดภาระได้

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

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

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