Alama bel Qalam Update Postmortem

Posted on by Sarah Alazab

Introduction

Updating and maintaining old projects is always a challenge, and that’s what I’ll be sharing today. I had the chance to work on Alama bel Qalam, a valuable but fairly old project originally developed by another fellow developer. My role was to maintain and extend it with new features, but since the project was several years old, I soon began to run into problems.

In this post, I’ll walk you through the issues I faced, how I tried to salvage the project, and what I learned in the process.

The Challenge

Let me introduce Alama Bel Qalam, a valuable and helpful project that I had the pleasure of working on. The project was originally created by a fellow developer, and my role was to update it with new features and maintain it over time.

The problem was that this project was developed quite a while ago, back when Unity’s capabilities were not as advanced. As a result, the developer had to rely heavily on a few plugins, some of which were tightly integrated into the entire project. Fast forward a couple of years, Unity introduced those long-awaited features, which made the plugins redundant. Naturally, the plugin creators decided it wasn’t worth maintaining them anymore, so they marked them as obsolete and stopped supporting them. This meant that, eventually, projects depending on those plugins would start to malfunction.

Today, I want to share the process I went through to try to salvage this project: the issues I faced and how I fixed them. It’s important to mention that my solution wasn’t permanent. In the end, I couldn’t keep the project alive because Google Play requires developers to regularly update the API level, and this project wasn’t sustainable under those conditions. Still, the fixes worked at the time, and I believe that for other projects where the plugins weren’t so tightly integrated, this approach could have extended their lifespan much longer. Unfortunately, I wasn’t that lucky 🙂 

And one more note before diving in: I develop solely on Linux, so some of the points I’ll mention will only apply to Linux users, or may require different solutions on Windows or Mac.

Opening old Unity version (2018.4.14) issue

Changing API level to the current highest (33)

This issue is regarding Google’s new policy that makes it mandatory for developers to update their apps to be a maximum of two API levels away from the newest API level https://stackoverflow.com/questions/75515890/this-app-isnt-available-for-your-device-because-it-was-made-for-an-older-versio

https://developer.android.com/google/play/requirements/target-sdk

  • To solve this issue, I needed to open build settings (Android) and set Target API to 33, but I needed to install the SDK first. I tried to use the command line to do that, but it didn’t work, and the easiest alternative (after some searching ) was to download Android Studio using snap => update then sudo snap install android-studio –classic https://snapcraft.io/install/androidsdk/ubuntu
  • But it seems the reason it wasn’t showing the option to select 33 was that it didn’t load the levels in the SDK folder, so closing Unity and opening it again fixed this issue, and now I can select API level 33 
  • I tried to change the scripting runtime version from 3.5 to 4, but after that, the API level wasn’t loading again, so just to avoid any possible issues, I reset it to 3.5
  • Now I added the key and password and changed the version and attempted to build an AAB, but Unity said it didn’t detect the NDK, so I opened Android Studio and checked the NDK to download it.
  • Trying to build again asked me to browse for NDK, and I have to choose the appropriate NDK version from inside “Android/SDK/ndk/”. Choosing the up-to-date version installed produced a prompt from Unity telling me that it requires version r16b
  • I found I can download any version I want by showing package details from the SDK manager and selecting the version I want. https://developer.android.com/studio/projects/install-ndk

Note: I still can’t build and run on a device, and the error log above has the errors that appear when I attempt to do that, but since I can copy the APK to the device manually and test it, I decided to leave this for another day.

Publishing to Google Play

  • Attempting to publish to Google Play required me to answer some prompts that had accumulated over the past years since the last release. I answered all and sent it for review, and the data safety one was rejected(invalid data safety form split_bundle 4). It gave examples of advertising ID, so I opened the project and removed the packages for advertising and analytics (which I wasn’t using) and rebuilt, and uploaded. I used this link to quickly remember how to upload a new release: https://support.google.com/googleplay/android-developer/answer/9859348?sjid=17511800181861709061-EU#create
    • The only option for me then was to change my data safety answers, but thankfully, my privacy policy seems to already include all statements needed, so at least I won’t need to change that. 
    • I reviewed the data safety quiz again and checked that I am collecting data (Android ID or device ID), and checked collected and that it is encrypted and that it still complies with the family policy. Now I sent it for review along with the updated game version from before, and waiting again.
    • IT WORKED 🙂 Passed the data safety and published the update, and it didn’t affect the family category. 
  • One small thing to check later is that now, when I search by the name without the accent, it doesn’t show, but when I choose the family category, it appears easily.

Final thoughts

Through this post, we explored the process of salvaging a large project that otherwise might have been decommissioned. I hope this was helpful to whoever is reading, and I’d be glad to hear your thoughts—especially if you have alternative solutions to any of the issues mentioned.

Thank you! 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *