Architecture · DTRAC Android

Follow the Android entry points and the boundaries between UI, collection, and storage.

Android entry path

:app
  M9App
    MainActivity
      AppNavHost
        UiJsonApp
          JSON loader → binding/action → renderer

App initialization, permissions, and plugin wiring live in the app layer. The UI JSON runtime connects packaged assets to screens and actions.

Main modules

Module	Responsibility
`:app`	Entry points, navigation, UI JSON runtime, permissions, submission/notification/sync wiring
`:core:plugin-api`	`Plugin`, common events and extension contracts
`:core:registry`	Plugin configuration parsing and source priority
`:core:repo`	Read/write use cases and repositories
`:core:db`	Room entities, DAOs and migrations
`:core:store`	Supporting preferences, time handling, remote data sources and sync
`:plugins:*`	Surveys, sensors, Samsung Health, Health Connect and cognitive games
`:ui`	Shared theme
Shared modules used by Android	Reusable contracts and Compose rendering

UI state flow

Screens focus on rendering and forwarding events. Durable screen state follows the ViewModel-centered architecture. Persistence and synchronization use repository and data-source boundaries. Do not add database writes or remote upload responsibilities to composables for a new feature.

Data flow

Provider / participant input
  → plugin / submission / ingestion
  → repository and Room
  → existing remote data source / worker
  → configured study backend

Not every plugin persists data by returning a pull() result. Sensors read existing batches; some health plugins perform ingestion and reconciliation during a pull. Surveys use a separate submission contract.

Extension points

Prefer JSON and existing nodes for wording/layout changes. Add provider integration through plugins and storage layers; examine new remote-storage behavior at the data-source boundary. Preserve compatibility paths until their usage is established.