https://syedzubyl.space Syed Zubyl N — Software Developer focused on Java, Spring Boot, backend development, REST APIs, databases, Flutter and production-oriented applications. Zola en Wed, 05 Aug 2026 00:00:00 +0000 Wed, 05 Aug 2026 00:00:00 +0000 Syed Zubyl N https://syedzubyl.space/blog/old-android-release-to-modern/ https://syedzubyl.space/blog/old-android-release-to-modern/ <h3 id="the-problem">The Problem</h3> <p>A few years ago, I built and published an Android application to the Google Play Store. Fast forward to 2026, and Google Play policies had evolved significantly. The original application was targeting an older Android version (around API 33). Google now required updates to target modern specifications (API 36). To make matters worse, the original development environment, including the local source code and the original signing keystore, had been lost on a dead hard drive.</p> <h3 id="context">Context</h3> <p>Updating an app on the Google Play Store is not just about uploading an APK. The new release must:</p> <ol> <li>Retain the exact same Application ID (package name).</li> <li>Be signed with the exact same cryptographic key (or use Play App Signing).</li> <li>Meet the latest <code>targetSdkVersion</code> requirements.</li> </ol> <h3 id="what-i-tried">What I Tried</h3> <p>I initially tried to create a brand new application with a slightly different package name (<code>com.myapp.v2</code>).</p> <h3 id="what-failed">What Failed</h3> <p>Creating a new application means starting from scratch. All previous reviews, download history, and existing users are lost. Existing users will not receive the update automatically; they would have to find the new app manually. This was unacceptable.</p> <h3 id="what-worked-technical-explanation">What Worked &amp; Technical Explanation</h3> <p>I had to recover the original identity and modernize the codebase.</p> <p><strong>1. Source Recovery and Preservation</strong> Fortunately, I was able to recover a backup of the source code. The very first step was initializing a Git repository and pushing it to GitHub. Once the source was recovered, the code was preserved in GitHub so that the project would no longer depend on a single local copy.</p> <p><strong>2. Modernizing the API Level</strong> I updated the <code>build.gradle</code> file to reflect modern requirements:</p> <ul> <li>Updated <code>compileSdkVersion</code> and <code>targetSdkVersion</code>.</li> <li>Upgraded deprecated dependencies that were incompatible with newer Android versions.</li> <li>Tested the application on Android 14+ emulators to ensure permissions and UI rendering remained functional.</li> </ul> <p><strong>3. The Keystore Crisis</strong> The Android signing key is critical. Without it, Google Play rejects the update because it cannot cryptographically prove the update came from the original author. Luckily, I had enrolled the app in <strong>Play App Signing</strong> during the original upload.</p> <p>This meant the actual production signing key was securely stored by Google. I only needed an “Upload Key.” Because I had lost the original upload key, I contacted Google Play Developer Support to reset it. I generated a new secure keystore, provided Google with the new <code>.pem</code> certificate, and they linked it to my app.</p> <p><strong>4. Production Release (Version 4)</strong> With the code modernized and the new signing configuration securely backed up (with passwords stored in a password manager, NOT in the Git repo), I built the release bundle. I uploaded Version 4 to the Play Console, filled out the new Data Safety declarations, and successfully rolled it out to production.</p> <h3 id="lessons-learned">Lessons Learned</h3> <p>Losing the original development environment does not necessarily mean the application itself is lost, but package identity, signing credentials, source code, and release history must be treated as critical assets.</p> <h3 id="what-i-would-do-differently">What I Would Do Differently</h3> <p>I will never rely on a local machine for code storage again. Every project, no matter how small, gets pushed to a remote version control system immediately. Furthermore, keystore files and their credentials must be treated as high-priority secrets and stored in redundant, encrypted cloud backups.</p>