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

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

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

แนวคิดหลัก

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

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

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

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

สถาปัตยกรรมกรอบ CHRE

รูปที่ 1 สถาปัตยกรรมกรอบงาน CHRE

ศูนย์กลางบริบท HAL

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

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

การเริ่มต้น

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

กำลังโหลดและยกเลิกการโหลด nanoapps

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

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

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

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

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

ภาพรวมระบบ CHRE

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

สร้างระบบ

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

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

CHRE API

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

สรุปเวอร์ชัน

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

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

เวอร์ชัน 1.0 (แอนดรอยด์ 7)

รวมการรองรับเซ็นเซอร์ และฟังก์ชันหลักของแอปนาโน เช่น กิจกรรมและตัวจับเวลา

เวอร์ชัน 1.1 (แอนดรอยด์ 8)

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

เวอร์ชัน 1.2 (แอนดรอยด์ 9)

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

เวอร์ชัน 1.3 (แอนดรอยด์ 10)

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

เวอร์ชัน 1.4 (แอนดรอยด์ 11)

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

คุณสมบัติของระบบบังคับ

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

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

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

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

  • ข้อยกเว้น 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 เว้นแต่จะจำกัดการพึ่งพาภายนอกกับฟังก์ชัน CHRE API และฟังก์ชันไลบรารีมาตรฐานที่ได้รับอนุมัติ

คุณสมบัติเสริม

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

เซนเซอร์

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

GNSS

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

อินเตอร์เน็ตไร้สาย

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

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

WWAN

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

เสียง

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

การดำเนินการอ้างอิง

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

สำหรับรายละเอียดทางเทคนิคและคำแนะนำในการย้าย โปรดดูที่ README ที่รวมอยู่ใน system/chre project