Android Native App

PrivateDAO now includes a first-class Android-native app under `apps/android-native/`.

This is not a hybrid wrapper and not a generic wallet demo. It is a Kotlin Android counterpart of the current PrivateDAO product and follows the same governance lifecycle and protocol assumptions already used by the Solana program, scripts, tests, and live web surface.

Why Android-first

PrivateDAO is Android-first on mobile because Solana Mobile Wallet Adapter is the official mobile dApp path for Android wallets today. This app therefore uses:

• Kotlin native
• Jetpack Compose
• Solana Mobile Wallet Adapter
• Devnet by default

Seed Vault is intentionally not used for the dApp transaction flow. Seed Vault is the wallet-app path; PrivateDAO is implemented here as a mobile dApp.

Path

apps/android-native/

What Was Ported From The Current Project

The Android app is derived from the existing repository and mirrors these repo-native truths:

• program ID: `5AhUsbQ4mJ8Xh7QJEomuS85qGgmK9iNvFqzF669Y7Psx`
• devnet explorer conventions from `scripts/utils.ts`
• PDA derivations from the program/tests:
• DAO PDA
• Proposal PDA
• VoteRecord PDA
• Treasury PDA
• Delegation PDA
• proposal/DAO account layouts from `programs/private-dao/src/lib.rs`
• proposal phase logic from the current frontend/docs product
• commit-reveal hash semantics from `sdk/src/index.ts`
• action naming from the existing program and scripts:
• `create_proposal`
• `commit_vote`
• `reveal_vote`
• `finalize_proposal`
• `execute_proposal`

Architecture

The Android app is intentionally separated from the current web frontend.

High-level layers:

• `config/`
• devnet RPC
• program ID
• explorer links
• `model/`
• DAO / proposal / treasury action / wallet state models
• `solana/`
• binary helpers
• base58
• PDA derivation
• account decoding
• Anchor discriminator encoding
• legacy transaction building
• `repository/`
• live DAO/proposal loading
• tx construction for current governance actions
• `wallet/`
• Mobile Wallet Adapter integration
• auth token persistence
• `presentation/`
• Compose UI
• dashboard
• proposals
• proposal detail action surface
• awards
• settings

Android System Diagram

Android user
  -> Jetpack Compose screens
     - splash
     - wallet connect
     - dashboard
     - proposal list / detail
     - create DAO / deposit / create proposal
     - commit / reveal / finalize / execute
     - awards / settings

Compose + ViewModel layer
  -> PrivateDaoViewModel
     - wallet session state
     - live DAO / proposal state
     - proposal phase decisions
     - transaction submission state
     - locally stored vote salt for reveal

Domain / repository layer
  -> PrivateDaoRepository
     - devnet RPC reads
     - DAO / proposal decoding
     - PDA derivation
     - instruction payload building
     - explorer link generation

Wallet layer
  -> MobileWalletAdapterManager
     - local association flow
     - authorize / reauthorize / deauthorize
     - signAndSendTransactions
     - auth token persistence

Solana layer
  -> live PrivateDAO program on devnet
  -> DAO PDA
  -> Proposal PDA
  -> VoteRecord PDA
  -> Treasury PDA
  -> SPL token accounts

Verification surface
  -> tx signature returned to app
  -> Solscan devnet link
  -> same lifecycle and terminology as the current web product

Mobile Wallet Adapter Integration

The app uses the official Solana Mobile Wallet Adapter Android-native path:

• local association flow
• wallet availability detection
• `authorize`
• `reauthorize`
• `deauthorize`
• `signAndSendTransactions`
• persistent auth token and wallet URI base storage

This means the Android app is designed to work with compatible Android wallets such as Phantom / Solflare when exposed through the MWA flow.

Current Native Screens

• splash / launch
• wallet connect
• home dashboard
• proposal list
• proposal detail surface
• create DAO
• deposit treasury
• create proposal
• commit vote
• reveal vote
• finalize flow
• execute flow
• awards / recognition
• settings / network info

Real On-Chain Coverage In Android

The current Android app is wired for real devnet interaction, not mock state.

Implemented mobile transaction paths:

• create DAO
• deposit treasury
• create proposal
• commit vote
• reveal vote
• finalize proposal
• execute proposal for SOL and token treasury paths

Implemented mobile read paths:

• load DAO accounts from the live devnet program
• load proposal accounts from the live devnet program
• decode proposal state and phase
• fetch recent proposal transaction signatures
• generate explorer links

Honest Current Limitations

These are real limitations, not hidden gaps:

• `SendToken` execution is now wired in the Android client, but it still depends on the recipient associated token account existing on-chain for the configured mint
• the Android app currently prioritizes the governance lifecycle and treasury/operator essentials; the broader browser-only proof center and judge-mode surfaces still live primarily in the web product
• full local build verification was limited in this session by missing local Android SDK / Gradle execution environment in the workspace shell

None of these change the protocol or on-chain behavior. They only define the current mobile surface area.

Build

Open the Android app in Android Studio from:

apps/android-native/

Typical steps:

• Install Android Studio with Android SDK support
• Open `apps/android-native`
• Let Gradle sync dependencies
• Run on an Android device or emulator
• Install an MWA-compatible wallet on the target device for real wallet flows

Run / Judge Flow

Recommended review path for judges:

• Install an Android wallet that supports Mobile Wallet Adapter
• Launch the PrivateDAO Android app
• Connect wallet
• Load live proposals from devnet
• Select a proposal
• Run one of the lifecycle actions that matches the current phase
• Verify the resulting signature in Solscan devnet explorer

Relation To The Current Web Product

The web/docs surface remains the main live public frontend.

The Android-native app is:

• a mobile-native counterpart
• Android-first
• wallet-native
• protocol-faithful

It does not replace the web frontend and does not change the on-chain protocol.