mirror of
https://github.com/d4rken-org/capod.git
synced 2026-09-15 10:46:12 -04:00
Remove Moshi dependency entirely, completing the migration to kotlinx.serialization. All JSON serialization now uses kotlinx with explicit @SerialName annotations for wire format stability. - Migrate PodDeviceCache from Moshi to kotlinx Json injection - Add MapIntByteArrayBase64Serializer for BleScanResult cache compat - Strip @JsonClass/@Json annotations from all dual-annotated classes - Delete Moshi adapters, ProGuard rules, and build config - Convert compat tests to pure kotlinx round-trip tests
2.8 KiB
2.8 KiB
description, globs
| description | globs | |||
|---|---|---|---|---|
| Architecture overview, module structure, key components, data flow, and dependencies |
|
Architecture
Multi-Module Structure
- app/: Main Android application with FOSS and Google Play flavors
- app-common/: Shared code between main app and Wear OS app
Core Patterns
- MVVM: ViewModels with LiveData/StateFlow for UI state management
- Dependency Injection: Hilt/Dagger for dependency management
- Coroutines: Kotlin coroutines for async operations
- Repository Pattern: Data layer abstraction for monitoring and settings
Key Components
PodMonitor System
PodMonitor: Core service that detects and tracks AirPods via Bluetooth LEMonitorControl: Manages MonitorService lifecycleMonitorService: Foreground service that continuously scans for AirPodsBluetoothEventReceiver: Handles system Bluetooth events
Reaction System
ReactionSettingsFragment: Configuration for popup notificationsPopUpWindow: Displays AirPods status when case is openedPopUpPodViewFactory: Creates UI components for different pod models
Common Utilities
EdgeToEdgeHelper: Handles Android edge-to-edge display insets
Build Configuration
Flavors
- FOSS: Open-source version without Google Play dependencies
- Google Play (gplay): Version with billing client for in-app purchases
Build Types
- debug: Unobfuscated, full logging, no minification
- beta: Obfuscated, production-ready with strict lint checks
- release: Fully optimized for production distribution
Data Flow
The app follows a unidirectional data flow:
BluetoothEventReceiverdetects Bluetooth eventsMonitorServicescans for AirPods beacon dataPodMonitorprocesses and stores device information- ViewModels observe monitor data via repositories
- UI components react to ViewModel state changes
ReactionSystemtriggers popups and notifications
Bluetooth LE Implementation
The app uses Android's Bluetooth LE APIs to scan for Apple device advertisements. The core scanning logic is in MonitorService which runs as a foreground service.
Multi-Platform Considerations
Code shared between phone and Wear OS apps is placed in app-common. When modifying shared functionality, ensure compatibility across both platforms.
Testing Strategy
- Unit Tests: Located in
app-common/src/test/for shared logic - Test Flavors: Separate test configurations for FOSS and Google Play variants
Key Dependencies
- Hilt: Dependency injection framework
- AndroidX Navigation: Fragment navigation with SafeArgs
- kotlinx.serialization: JSON serialization for configuration and caching
- Material Design: UI components following Material Design guidelines