สภาพแวดล้อมรันไทม์ Context Hub (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 ผ่านการเข้าถึงที่ จำกัด ContextHubManager APIs ระบบ

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

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

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

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

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

Context Hub HAL

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

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

การเริ่มต้น

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

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

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

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

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

ศูนย์กลางบริบทเริ่มต้นใหม่

แม้ว่า CHRE จะไม่ถูกคาดหวังให้รีสตาร์ทระหว่างการดำเนินการตามปกติ แต่ก็อาจจำเป็นต้องกู้คืนจากสภาวะที่ไม่คาดคิด เช่น ความพยายามในการเข้าถึงที่อยู่หน่วยความจำที่ไม่ได้แมป ในสถานการณ์เหล่านี้ CHRE จะรีสตาร์ทโดยอิสระจาก Android ฮาลแจ้ง Android นี้ผ่าน RESTARTED เหตุการณ์ซึ่งจะต้องส่งเฉพาะหลังจากที่ได้รับการ CHRE reinitialized ไปยังจุดที่จะสามารถยอมรับคำขอใหม่เช่น 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 ซึ่งเหมาะสำหรับแอปพลิเคชันที่จำกัดทรัพยากร

CRE API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • ข้อยกเว้น C++ และข้อมูลประเภทรันไทม์ (RTTI)
  • ห้องสมุดมาตรฐาน multithreading สนับสนุนรวมทั้งหัว 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 และระบบ ซึ่งรวมถึงแต่ไม่จำกัดเพียง:

  • String / สาธารณูปโภคอาร์เรย์: 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 ที่กำหนด แต่ nanoapps ที่อ้างอิงฟังก์ชันเหล่านั้นจะต้องสามารถสร้างและโหลดได้

เซนเซอร์

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

GNSS

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

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