How eiyooooo/fold_switcher works
<explanation>
1. Identify the project type and purpose
- This is a native Android mobile application (“Fold_Switcher”) whose sole purpose is to switch a foldable device’s hardware posture (closed, half‑open, tent, open, dual‑display).
- It supports two execution modes:
• User mode (regular Android APIs)
• Shizuku mode (using the Shizuku service for elevated permissions)
2. Analyze the file structure
- Top‑level build files (build.gradle, settings.gradle, gradle/ folder) indicate a single Gradle “app” module.
- app/src/main/java/com/eiyooooo/foldswitcher contains:
• views (Activities, ViewHolders, custom Views)
• viewmodels (MainActivityViewModel) – MVVM pattern
• adapters (MainViewPagerAdapter) – UI composition
• helpers (SharedPreferencesHelper) – local storage
• wrappers (DeviceStateManager.java, Executor.kt, ShizukuExecutor.kt, UserExecutor.kt) – abstraction over hardware calls
• types (data classes) – domain model for fold states and execution modes
• MyTileService.kt – Quick Settings tile service
• ReceiverActivity.kt – broadcast receiver-style entry point for external Intents/ADB
- app/src/main/aidl/android/hardware/devicestate – AIDL interface to the Android hardware service
- res/ – standard Android UI resources (layouts, drawables, strings)
- metadata/ – Play Store listing assets
3. Examine the README for additional insights
- Describes the two modes: user vs. Shizuku
- Mentions integration points: Intents (ReceiverActivity) and ADB commands
- No external backend or network; purely on‑device hardware control
4. Main components to include in the system diagram
A. Presentation layer (UI)
- MainActivity (view)
- MyTileService (Quick Settings tile)
- ReceiverActivity (external Intent entry point)
B. ViewModel layer
- MainActivityViewModel
C. Domain/data layer
- FoldStateData, ExecuteMode, ShizukuStatus (data types)
- SharedPreferencesHelper (persistent settings storage)
D. Execution layer
- UserExecutor (calls DeviceStateManager directly via standard APIs)
- ShizukuExecutor (binds to Shizuku service for permission elevation)
E. Hardware abstraction
- DeviceStateManager (wrapper around AIDL interface)
- AIDL interface (android.hardware.devicestate.IDeviceStateManagerCallback)
- Android hardware service (system service that actually changes device posture)
F. External services
- Shizuku service (runs with elevated privileges)
- Android OS (Binder IPC, system services, Quick Settings host)
5. Relationships and data flow
1. User taps a posture in MainActivity or Quick Settings tile → MainActivityViewModel
2. ViewModel selects Executor based on ExecuteMode
• UserExecutor → invokes DeviceStateManager via standard Binder call
• ShizukuExecutor → binds to Shizuku service → relays call to DeviceStateManager
3. DeviceStateManager communicates with the Android hardware service through AIDL → hardware changes fold state
4. ViewModel observes the state change → updates UI via LiveData (or callbacks)
5. External apps or ADB trigger ReceiverActivity with Intent extras → processed exactly like a UI request
6. Architectural patterns and design principles
- MVVM (View → ViewModel → Model)
- Dependency inversion via Executor interface (allows switching implementation at runtime)
- Separation of concerns: UI, business logic, hardware interface
- Use of Android’s Binder/AIDL for IPC
- Modularization: wrappers isolate hardware calls, helpers isolate storage
7. Diagram–drawing guidelines
- Use boxes for each major component (UI, ViewModel, Executors, Manager, AIDL, Services)
- Draw arrows showing invocation flow:
• UI → ViewModel → Executor → DeviceStateManager → AIDL → Hardware Service
• ShizukuExecutor ↔ Shizuku service (side‑channel for elevated IPC)
• ReceiverActivity → ViewModel (external entry)
- Color‑code layers:
• Presentation (blue)
• Domain/logic (green)
• Hardware/IPC (orange)
• External services (purple)
- Label each arrow with the method or protocol (e.g., Binder IPC, Intent)
- Include notes on execution modes (User vs. Shizuku)
8. Tailoring the diagram to a native Android app
- Emphasize the layered architecture within the Android process
- Show Android OS as the platform box encompassing your app’s process, binder kernel, and system services
- Highlight integration points (Quick Settings, Intent API, ADB) as external arrows entering ReceiverActivity or MyTileService
- If desired, annotate resource directories (res/layout, res/drawable) as part of the Presentation layer
By following these steps and mapping each directory/package name to a component in your diagram, you ensure full coverage of the app’s architecture—from UI widgets through platform‑level hardware controllers—while making clear the two execution modes and external integration points.