Wear OS 64-bit Migration Checklist: Audit, Build, Test and Release
Start with the exact Wear OS artifact you plan to release, including third-party SDKs. A project written in Kotlin can still package native libraries. The checklist below turns the architecture requirement into evidence your engineering and release owners can review.
What changed, and who needs to act
Google’s 1 April 2026 announcement sets 15 September 2026 as the enforcement date for new Wear OS apps and updates containing native code. Those submissions must provide 64-bit versions alongside their 32-bit versions; non-compliant uploads are blocked. This deadline has passed as of this review on 27 October 2026.
Google says existing 32-bit device delivery continues. Do not remove 32-bit support simply to satisfy the new requirement. Apps and all their dependencies written only in Java or Kotlin need no native-code migration.
1. Inventory the release artifact
- Build the release variant for the watch module, not only its companion phone app. Record the commit, version code, build tools and artifact name.
- Open the APK or app bundle in Android Studio APK Analyzer. Check for .so libraries; inspect bundled SDKs as well as code your team owns.
- Create a register with library name, supplying SDK/version, packaged ABIs, owner and replacement or upgrade action. No native libraries is a useful finding—retain the artifact inspection evidence.
2. Resolve missing native architectures
For ARM libraries, compare armeabi-v7a with arm64-v8a. Inspect the equivalent 64-bit support for every native architecture shipped. The presence of one 64-bit library does not prove the complete dependency chain works.
Upgrade third-party packages that lack the required binaries, or obtain a supported build from the supplier. Changing an ABI filter cannot manufacture a missing library. If source is unavailable and no compatible release exists, plan a replacement or remove the dependent feature deliberately.
3. Rebuild and inspect what will ship
- For owned native code, review pointer-size assumptions, integer casts and JNI boundaries before rebuilding for the intended architectures.
- Review Gradle ABI filters, native build settings and packaging exclusions. Verify the generated release output again after dependency changes.
- Use the same signing and release configuration planned for distribution. Check Play Console architecture warnings before proceeding; a successful local compile is not release acceptance.
4. Test functionality on 64-bit Wear OS
Use a 64-bit Wear OS emulator environment and representative supported hardware where available. Exercise each feature that loads native code, including SDK initialization, rather than stopping after the launcher opens.
- Cold start, sign-in, SDK initialization and restoration after process recreation.
- Your actual watch features: tiles, complications, notifications, sensors or media where present.
- Phone pairing, reconnects, permission denial and unavailable-network paths where supported by the product.
- A matched regression run for retained 32-bit support. Record device/image, OS, ABI, build identifier and failures.
- Crash traces, library-load failures and native boundary issues. Keep before/after functional results; architecture support alone does not prove a battery or speed improvement.
5. Prepare the release evidence packet
- Artifact inventory: every native dependency has a named owner and an architecture decision.
- Build evidence: release artifact identifier and inspection results for the packaged libraries.
- Regression evidence: test matrix, results, unresolved defects and explicit release criteria.
- Release ownership: internal test-track review, Play Console checks, rollout monitoring and a recovery plan. Keep the previous stable source/build configuration; store rules govern what can be released again.
Scope the migration before requesting an estimate
Share the watch app’s Play listing, source/build access arrangements, dependency inventory, native-code ownership, affected features and release constraints. A pure Kotlin app without native SDKs has a different scope from an app with an unsupported closed-source library.
This guide is focused on an existing app’s release readiness. For broader platform and product planning, see our watch development service page.
Planning your next Wear OS release?
Share the dependency inventory, affected watch features and release window to discuss the migration scope.
Frequently Asked Questions
Does a Kotlin Wear OS app need changes?
Only if its packaged dependencies or other modules introduce native code that lacks the required support. Inspect the release artifact before concluding that no migration is needed.
Should we remove all 32-bit libraries?
No. Google’s Wear OS announcement retains 32-bit device support and requires the relevant 64-bit versions for native-code submissions.
Is 64-bit support the same as target SDK or page-size compliance?
No. CPU architecture, target API level and native memory page-size compatibility are separate checks. Confirm all current requirements for your app in the official documentation and Play Console.