Shiply Hotfix Publishing Platform Guide

1. Prerequisites

1.1 Create a Project and Product

Create a project and corresponding Android product on the Shiply platform. You can also follow How to Create a Project and Product.

After creating the product, the platform assigns appId and appKey, which serve as SDK authentication credentials.

1.2 Integrate the Hotfix SDK

Complete hotfix SDK integration and successfully build patch files. You can also follow Shiply Hotfix Android SDK Integration.

2. Create a Patch Release Task

2.1 Create a Release Task

Click New in the top-right corner to open the new release page and fill in the required information.

• Task name: Display name in the task list
• Fix version: Target version for patch delivery; used as a delivery rule (must match the value passed during SDK initialization; defaults to the app's versionName)
• Hotfix artifact: Signed patch package to deliver for this task
• Developers: Task developers; serve as approvers in the release approval stage
• Testers: Task testers; serve as approvers in the release approval stage
• Rule template: Default release rules applied when the task is created, such as experience accounts, delivery rules, and gray rollout rules

After the task is created, a new task with status In experience appears in the task list. Click details to view full task information.

2.2 Configure Task Information

Tasks use specified default configuration at creation. These settings can be modified before release.

1. Configure basic information

• Developers: Task developers; serve as approvers in the release approval stage
• Testers: Task testers; serve as approvers in the release approval stage
• Experience accounts: Allowlist that can fetch this task before release (during experience/gray rollout), for pre-release testing

Note: Experience accounts should use the userId value passed during SDK initialization.

2. Configure delivery rules and rollout strategy

• Delivery rules: Which devices receive this task. Defaults support system version, manufacturer, device model, and number packages; you can also extend custom attributes for delivery control
• Gray rollout rules: Batch count, batch limits, duration, and other gray rollout settings

2.3 Test and Verify the Patch

After configuring experience accounts and delivery rules, restart the app or trigger a config request from the debug page to verify the patch delivery channel and installation.

If the patch is fetched and installed successfully, restart the app again to trigger patch loading (patches take effect on the next cold start after installation).

If the patch cannot be fetched, check whether experience accounts and delivery rules match the app state. If fetch succeeds but installation fails, verify SDK integration and patch build steps.

Note: Tinker installation can take 1–2 minutes on some higher OS versions.

3. Patch Release Rollout

3.1 Release Approval

After verifying the patch via experience accounts, proceed to release approval. Once all approvals pass, the task automatically enters gray rollout and non-experience users can fetch it.

Note: If approvers are missing during gray rollout approval, go to Hotfix Settings and configure Gray release approvers.

3.2 Gray Rollout

During gray rollout, the system automatically rolls out batch by batch according to the gray strategy. Real-time activation statistics are displayed in charts.

• Delivered: Number of devices that received the patch
• Installed: Number of devices where the patch was installed
• Activated: Number of devices where the patch was activated (requires process restart)

Note: Statistics are cumulative per day, starting from midnight, to reflect daily patch coverage.

3.3 Task Status Control

Task list and detail pages provide status controls to change task state. After release, if you need to control rollout or roll back an active patch, use these controls.

• Pause: Users who already fetched the patch continue using it; users who have not will no longer match this task
• Stop: All users who fetched the patch will uninstall it (equivalent to rolling back the patch)

4. Other Features

4.1 Release Approvers

Release approvers are the final gate before patch release, ensuring release safety and preventing accidental or misconfigured releases that could cause live incidents.

Note: New integrations should configure this; otherwise the final approval step cannot proceed.

4.2 Rule Templates

Different release scenarios may require different task rules—for example, lower gray batch limits when the gray user base is small.

Create rule templates for different scenarios in advance so you can select a template when creating tasks instead of reconfiguring complex rules each time.