Case Overview
The project focuses on local face detection for smart glasses. It is not an identity-recognition system. The delivered capability detects front, left-profile and right-profile face targets on device, and returns face boxes, confidence, five landmarks, yaw/pitch/roll, orientation class and session-level trackId values for the upper-layer Android application. The delivery includes an Android Face SDK, an installable Demo APK, source projects, model files, integration guidance, troubleshooting notes and a delivery-status record. The public case does not disclose the customer name, field samples or internal evaluation data; it presents the engineering method, deliverables and confirmed boundaries.
Project Background and Requirement
Smart glasses, mobile inspection devices and edge vision terminals often need visual perception to run without network dependency because of privacy constraints, response requirements or field connectivity. Compared with cloud recognition, on-device offline detection must balance device compute, memory, camera frame formats, Android lifecycle behavior and power constraints. The project requirement was to provide an Android application with offline face detection on RK3588 smart glasses, covering real-time camera frames and local image input, and returning data structures that can be used for preview overlays, counting, orientation judgement and later business logic.
The delivery boundary was defined at the beginning. The SDK provides face boxes, confidence, five landmarks, yaw/pitch/roll, front/left-profile/right-profile classification, synchronous and asynchronous detection, Camera2 real-time frame examples and local-image detection examples. The SDK does not provide face enrollment, feature extraction, 1:1 or 1:N identity matching, name or ID recognition, cloud APIs, camera drivers, USB Host drivers or UVC capture drivers. This boundary helps separate face-detection delivery from identity-recognition system delivery and keeps later expansion work explicit.
Technical Approach
The algorithm path uses offline CPU detection based on OpenCV Java API and a YuNet model. The Android engineering package is split into Core and Face AAR modules. Core AAR provides common runtime, status and utility support, while Face AAR provides face-detection interfaces, option configuration and result structures. Both AARs must use the same SDK version and be integrated with OpenCV 4.10.0 for Android. The target platform is an RK3588 Android device; the first-stage verified ABI is arm64-v8a, the minimum Android API level is 24, and compileSdk/targetSdk are 30.
The input layer supports YUV_420_888, NV21 and RGBA_8888. In the real-time preview path, Camera2 supplies 1280 x 720 YUV_420_888 frames. The application must copy plane data into its own DirectBuffer before closing the Image, then submit that buffer to the SDK. For local image detection, JPG or PNG data can be converted to an RGBA DirectBuffer. Preview mirroring, scaling and overlay drawing are UI-layer mappings; SDK results are based on the original input-image coordinates and must be transformed according to the actual preview area and mirror setting.
Android SDK Integration Points
The recommended integration path is to run the Demo first and then integrate the AARs. The customer can install the Debug Demo APK, grant camera permission, validate front, left-profile, right-profile and multi-face outputs, and then add Core AAR, Face AAR, OpenCV dependency and model files to the customer Android project. Model installation and SDK creation should happen during application initialization, not per frame. For real-time detection, the asynchronous interface is recommended. One SDK instance runs one asynchronous task at a time; if the previous frame is still running, the SDK returns a BUSY state so the application can drop or throttle frames according to its product logic.
The demo project uses an approximately 100 ms submit interval, equivalent to about 10 detection submissions per second as a demonstration strategy. This is not a fixed SDK limit. Actual detection frequency should be confirmed with the RK3588 device load, input resolution, thread count, scene complexity and power policy. Detection options include maximum face count, minimum face size in pixels, confidence threshold, NMS threshold, pose and landmark output, and session tracking. For profile faces, near-silhouette pose, insufficient visible facial features, yaw outside the sample distribution, motion blur, display glare, low light or incorrect rotation handling can reduce detection stability and must be validated with real samples.
Deliverables and Validation
The delivery package is named EyeAlgo-Face-SDK-0.4.5-fix5-CUSTOMER_TEST-NOT_PRODUCTION-20260729. It is intended for customer functional testing and Android engineering integration assessment, not as a production-signed release. The package includes eye-algo-core-0.4.5-release.aar, eye-algo-face-0.4.5-release.aar, Eye-Algo-Face-Combined-Demo-0.4.5-fix5-debug-NOT_PRODUCTION.apk, FaceSdkProject, DemoProject, integration guidance, troubleshooting notes, delivery-status documentation, third-party license information and verification scripts.
| Validation Item | Result | Notes |
|---|---|---|
| Package integrity | Passed | 138 packaged files matched SHA256SUMS.txt, with no unlisted files. |
| SDK source build | Passed | Build passed with JDK 11, Gradle 7.5.1 and AGP 7.4.2. |
| Unit tests | Passed | Core 6/6, Face 1/1 and Demo 13/13 tests passed. |
| Lint errors | Passed | 0 errors and 19 warnings. Warnings should be reviewed against the customer project rules. |
| Production signing and mass-production acceptance | Out of scope | Production signing, customer-frozen accuracy and long-duration stability acceptance require validation in the customer environment. |
Reusable Value
This case is relevant to smart glasses, mobile inspection terminals, edge AI boxes and Android industrial handheld devices that need offline face-detection SDK delivery. Reusable assets include on-device model packaging, modular AAR delivery, Camera2 frame handling, real-time preview overlays, orientation-class outputs, static-image detection, error-code design, integration documentation and validation checklists. For projects that require local visual perception without uploading images to a cloud service, this delivery model can be used for Validation, prototype validation and customer SDK handoff.
The public case records only verified engineering delivery facts. It does not present unconfirmed customer accuracy, eight-hour stability, production signing or mass-production readiness as achieved results. A formal project still requires independent validation using customer-frozen samples, actual camera modules, lighting range, wearing angles, device thermal behavior, application threading model and agreed acceptance criteria.
FAQ
What is included in the RK3588 smart glasses offline face detection SDK delivery?
The delivery includes Core AAR, Face AAR, a Debug Demo APK, source projects, model files, Android integration guidance, troubleshooting notes, a delivery-status record, license information and verification scripts for customer functional testing and engineering integration assessment.
Does the SDK include identity recognition?
No. The delivery scope is face detection and orientation classification. It returns face boxes, confidence, landmarks, pose angles and session-level trackId values. It does not provide enrollment, face libraries, 1:1 or 1:N matching, name recognition or ID recognition.
What should be verified before production release?
The customer should verify detection accuracy, long-duration stability, production signing, power consumption, thermal behavior, camera driver behavior, lighting and wearing-angle coverage on the actual device and with agreed test samples.