AI Skill Report Card
Configuring Myket Multi APK Releases
Configuring Myket Multi-Package Releases
Quick Start13 / 15
To publish multiple packages in one Myket release:
- Build separate APKs/AABs for each target configuration (e.g., by ABI:
armeabi-v7a,arm64-v8a,x86) - Ensure each package has a unique version code (higher for higher-priority packages)
- Upload all packages under a single release in Myket Developer Console (پنل توسعهدهنده مایکت)
- Define targeting rules for each package (device API level, screen density, ABI, or OpenGL version)
- Publish — Myket automatically serves the matching package to each user's device
Recommendation▾
Add a third example showing a failure/pitfall scenario with concrete input/output (e.g., what happens when targeting rules overlap) to strengthen the examples section
Workflow13 / 15
Progress:
- Step 1: Identify why multiple packages are needed (APK size limits, architecture-specific native libs, feature parity across API levels)
- Step 2: Build/export each variant package with distinct
versionCodevalues - Step 3: Verify each package's manifest declares appropriate
<supports-screens>,<uses-sdk>, and ABI filters - Step 4: Go to Myket Developer Panel → select app → new release (انتشار نسخه جدید)
- Step 5: Upload each package file within the same release entry
- Step 6: Set targeting criteria per package so device configurations don't overlap
- Step 7: Review the automatic conflict check (Myket flags overlapping targeting rules)
- Step 8: Submit for gradual rollout (انتشار تدریجی) or full release
Recommendation▾
Include actual manifest snippet or console screenshot-level detail (e.g., sample ABI filter XML or gradle config) to make the workflow more actionable/concrete
Examples14 / 20
Example 1:
Input: An app has a 250MB APK due to arm64-v8a and armeabi-v7a native libraries bundled together, exceeding size limits for some users.
Output: Split into two APKs — one with only arm64-v8a libs (versionCode 105), one with only armeabi-v7a libs (versionCode 104). Upload both in the same release with ABI-based targeting so Myket delivers the correct one per device.
Example 2: Input: A new feature requires Android 8.0+ (API 26) but the app currently supports back to API 21. Output: Create a "legacy" package (versionCode 40, API 21–25, without the new feature) and a "modern" package (versionCode 41, API 26+, with the new feature). Upload both in one release with API-level targeting.
Recommendation▾
Clarify version code numbering strategy with a small table mapping packages to versionCodes and targeting rules for a full worked example
Best Practices
- Always give the more feature-rich or optimized package the higher versionCode — Myket and Google Play semantics rely on this for correct resolution.
- Test targeting rules against a matrix of real device configs before rollout.
- Use gradual rollout (انتشار تدریجی نسخه) alongside multi-package releases to limit blast radius if one variant has issues.
- Keep package-specific differences minimal (native libs, API-gated features) — don't diverge core app logic across packages, since it multiplies QA effort.
- Document which versionCode maps to which targeting rule in your internal release notes for future maintenance.
Common Pitfalls
- Overlapping targeting rules: Two packages targeting the same device configuration causes ambiguous resolution — Myket will reject or flag this.
- Duplicate or lower versionCodes on richer packages: Leads to users receiving the wrong (often lesser) package.
- Forgetting signing consistency: All packages in a release must be signed with the same key as previous releases of the app.
- Ignoring update path: Users on an old single-package release must be able to migrate cleanly to the multi-package release without reinstall issues.
- Not testing the "no match" fallback: Ensure at least one package covers all remaining device configs, or users outside defined rules won't receive updates.