I plan on releasing a lot of my old work as GPL open source, but most of it has aged to the point that it no longer functions, or if it does work it’s running in compatibility mode. Basically it’s no longer best practices. Not a good way to start off any new public GPL projects, in my opinion.
The current project I’m working on is an Android app that calculates star trails meant to help photographers get or avoid that in their night time photos.
For now I’m going to skip some of the import process because I didn’t document it exactly. It’s been mostly trial and error as I poke around Android Studio post import.
- The Android Studio import process…
- Removing Admob Google Play code before the project would run at all.
- After removing dependencies, it kind of worked, but when running it in the emulator it shows a pop-up message saying that the app was developed for an old version of Android.
Going through the process of updating code to match current best practices…
- I had the IDE convert the project to Gradle.
- I updated the target SDK to 31 in AndroidManifest.xml as well as the build.gradle until I found out it no longer needs to be in the AndroidManifest file. The import process should handle this, in my opinion. This will be an ever changing number.
- I had the IDE migrate the entire app to AppCompat. Latest developer documents I’ve seen said avoid trying to migrate to AndroidX. Odd, but okay, whatever.
- The process is ongoing…
I try running the program after messing with AppCompat and GPS code. It instantly crashes. At first I thought it was my GPS code changes so I ended up wasting time on that.
 |
| The primary error creating an instant crash? The application builds, but instantly crashes with this error… |
java.lang.IllegalStateException: You need to use a Theme.AppCompat theme (or descendant) with this activity.Code language: plaintext (plaintext)
You need a single tag parameter in AndroidManifest.xml to fix the issue.android:theme="@style/Theme.AppCompat"Code language: plaintext (plaintext)
That parameter should be inside the application tag, not the activity tag. If it’s not on the top level then you will get your primary activity sort of working, but going to another activity will crash the application with a slightly different message.
What do you need to do:
<application android:icon="@drawable/icon"
android:label="@string/app_name"
android:theme="@style/Theme.AppCompat">
 |
| A one parameter fix that should be fast and easy, but Android Studio doesn’t help much. |
Since starting, I’ve not been a big fan of Android development due to the constant changing and rough feel of official tools. First with Eclipse and now with Android Studio.
I’ve got questions…
- Why isn’t that issue caught and explained when the application is being
- Why isn’t that issue caught and explained when the application is being built?
- Why isn’t that picked up by the refactoring engine when viewing AndroidManifest.xml?
I’m going to assume it’s not something that existed back when I first developed these applications. Or maybe the import and/or refactoring processes did something? Who knows.
It’s dumb because it’s such a simple issue, but I don’t think it’s handled well by the IDE. The program shouldn’t compile without that line if it needs it.
The application is still very broken, but at least the GUI and basic functionality works now.
I took out important GPS code because at first I thought the theme issue was an issue with the GPS code, oops! Not cool.
In my opinion, Android Studio should handle the import process of old apps flawlessly, but I suspect it’s a very low priority. I’ve made attempts years prior, which were even worse than this.
It should also automatically, or at least give you the option to update everything to use the latest ways of doing things. At this point I don’t know if I’m even using the latest best practices. It’s possible that Java itself is out the door for Kotlin which would explain the word “AppCompat”. I had made a new project and the main activity extends AppCompatActivity, so based on wording alone this doesn’t feel like the current best code to keep it as future proof as possible.
Transitioning to Kotlin is another thing I should consider too. Maybe there is a magical unicorn document out there somewhere to list off what needs to be done to get an Android project into the current era. I should start looking in more detail.