Inspiration
A lost-device application must stay responsive in the background, but constant GPS, Bluetooth, Wi-Fi and network activity can drain the battery. A phone with an empty battery cannot be recovered. DJINZIN was created to let an owner communicate securely with protected devices while keeping them recoverable for as long as possible.
What it does
DJINZIN is a native Android device-security and recovery application. Devices appear like contacts in a secure messaging interface. An owner can link devices, request a current position, start live tracking, ring a device, run nearby Bluetooth or Wi-Fi Direct search, inspect device status and send recovery commands through Firebase-backed synchronization.
For the Arm Create Mobile AI track, DJINZIN adds AdaptiveSafetyIntelligence, an offline, explainable local engine that evaluates battery level, charging state, network readiness, GPS accuracy and freshness, Bluetooth, Wi-Fi Direct, screen state, recovery activity and lost-device status. It returns a priority of LOW, MEDIUM, HIGH or CRITICAL and adapts the background recovery strategy.
Mobile AI optimization approach
The adaptive strategy changes:
- GPS request interval
- Bluetooth scan interval
- network-check frequency
- Wi-Fi Direct usage
- foreground-service behavior
Normal conditions reduce unnecessary work. Active recovery increases responsiveness. Low battery preserves autonomy while maintaining essential recoverability. Urgent recovery commands remain prioritized.
DJINZIN also embeds a real 824-byte TensorFlow Lite model that classifies emergency commands locally into locate_device, trigger_alarm, lock_device, call_recovery_contact and request_status. No remote AI request is required for this classification.
How we built it
The Android application is written in Java and uses Android location and foreground services, Bluetooth/BLE concepts, Wi-Fi Direct, Firebase Realtime Database, Firebase Hosting and local TensorFlow Lite inference. The local intelligence layer is versioned with the application and remains available when the network is unavailable.
Architecture: Android safety signals → AdaptiveSafetyIntelligence → risk score and offline command intent → adaptive recovery strategy → DJINZIN security services.
Optimization evidence
Only directly measured or file-derived values are reported:
- TensorFlow Lite intent model: 824 bytes
- Adaptive safety metadata: 1,058 bytes
- Network AI requests avoided: one per offline demo classification
- Android unit tests: passed
- Debug APK build: passed
- Real-device battery drain and Arm CPU utilization: not measured
The in-app benchmark screen records GPS requests, Bluetooth scans, command-response time, process memory, model size and avoided network inference requests. Unmeasured fields are explicitly shown as not measured.
Challenges
The hardest problem was balancing recovery strength with battery safety. Android OEM restrictions also vary for background services, Bluetooth permissions and battery optimization. DJINZIN therefore combines adaptive local decisions with transparent permission and readiness guidance.
Accomplishments
- A real local intelligence layer integrated into the recovery workflow
- Explainable priority decisions
- Offline TensorFlow Lite emergency-command recognition
- Messaging-style interaction between owners and devices
- A public source repository with secrets and user data excluded
- A downloadable, reproducible Android APK
What we learned
Mobile AI is most valuable when it improves the core product. In DJINZIN, local AI is not a decorative chatbot: it decides when to conserve energy and when recovery services should become more aggressive.
What's next
Next steps are real Arm64 hardware battery profiling, additional command-training examples, stronger encrypted command payloads, improved BLE and Wi-Fi Direct recovery, and production signing for Play Store distribution.
Log in or sign up for Devpost to join the conversation.