Deployment capabilities
Jugg deployment capabilities apply APKs, DEX, resource overlays, Manifest changes, .so files, runtime agents, and other compilation artifacts to target devices. Jugg selects install, Apply Changes, restart, Direct Overlay, or recover/retry according to artifact type, device state, and historical checkpoints.
Capability overview
Deployment strategies
| Capability | Current support | Typical result |
|---|---|---|
| Clean Reinstall | Supports reinstallation and optional app-data cleanup | Re-establishes the APK, deployment history, and overlay baseline |
| Code Swap | Supports method-body-level class updates that can be replaced online | Keeps the app process running; regular non-empty deployments usually recreate the Activity |
| Full Swap | Supports Apply Changes that must restart the Activity | Restarts the current Activity after updating code or overlays |
| Hot Reload | Supports online incremental overlay and class updates | Keeps the app running and restarts only the Activity when needed |
| Restart | Supports restarting the app based on deployment results or user choice | Lets hot fixes, agents, or debugging changes take effect |
State recovery and complex targets
| Capability | Current support | Typical result |
|---|---|---|
| Direct Overlay | Supports writing overlays directly when the device is not ready | Completes overlay updates without the online Apply Changes transport |
| Recover and Retry | Supports state recovery, compatible deployment, and failure retries | Avoids continuing hot updates from an inconsistent baseline |
| Multiple APKs | Supports routing ownership for base, split, test, and other APKs | Delivers artifacts to the correct APK/applicationId in the same run |
| Multiple devices | Supports deployment to each selected device | Aggregates success state and failure fallback eligibility |
| Deployment history and cache | Maintains Jugg history and the Android Studio deployment cache | Determines whether an overlay checkpoint is trustworthy |
| JVMTI Runtime | Prepares the Jugg agent after deployment and detects compatibility | Supports compatible deployment, runtime instrumentation, and later tool capabilities |
IMPORTANT
The deployment strategy depends on both the current compilation result and device state. A successful Gradle compilation proceeds to install. A successful Jugg incremental compilation proceeds to incremental deployment; failures enter recover, retry, or Gradle fallback according to failure type.
How the deployment flow fits together
Run starts
-> Collect artifacts for the current deployment
-> Generate deployment data
-> Choose install / Hot Reload / Hot Fix / Full Swap
-> Route by device and APK ownership
-> Run install, Apply Changes, or Direct Overlay
-> Commit deployment history and the overlay checkpoint after successUsers do not need to select a deployment type manually. Jugg chooses the strategy from class-structure changes, resource and APK updates, device readiness, overlay checkpoint consistency, and related information.