Update to Gradle 8.0 and Android 34 requires build system update

[codeanticode]

Right now the entire build system is stuck at Gradle 7.2 and Android 33 because anything higher would require moving to Gradle 8. which is not backwards-compatible.

The official upgrade docs may be useful: https://docs.gradle.org/current/userguide/upgrading_version_7.html

[sandrobenigno]

Google is denying the use of Android 33 and Gradle 7.2 for publishing apps.

"We've detected that your app is targeting an old version of Android. To provide users with a safe and secure experience, Google Play requires all apps to meet target API level requirements.

From August 31, 2024, if your target API level is not within 1 year of the latest Android release, you won't be able to update your app."

Your highest non-compliant target API level is Android 13 (API level 33).

To ensure that you can continue to make updates to your app you must:

Update your app to target Android 14 (API level 34) or higher.
Publish a new version of your app to production. Before you do this, you can test your app using internal, closed, or open testing.

[codeanticode]

So this needs to be fixed asap :-)

[SableRaf]

Thanks for the heads up @sandrobenigno 🙏

@codeanticode: what amount of work would be needed for this update? Can I help coordinate this in any way?

cc @ranaaditya @Stefterv

[codeanticode]

It may take a substantial amount of work because there is quite a bit of custom Gradle code that needs to be updated to be compatible with 8.0.

[sandrobenigno]

(FYI) From now on, Google will no longer accept apps created using the current Processing for Android mode.
I asked for an extension for my app, but now they no longer allow updates or even closed testing.

[codeanticode]

@sandrobenigno I'm sorry that there is no solution currently for this issue, I will do my best to find a time sometime soon (although I don't think I will be able to work on it until next month or so). For the time being, a workaround would be to export your sketch as Gradle project, so you continue the development from Android Studio. You should be able to fully utilize the Processing API, while upgrading the latest version of Gradle, etc. to pass through Google's latest review requirements.

[Stefterv]

Maybe it makes sense for me and @SableRaf to write a tutorial on how to do the upgrade from within Android Studio?

[codeanticode]

@Stefterv yes that would be a great resource, thank you. The processing android book has an appendix precisely on that that you could use as a starting point.

[SableRaf]

Thanks for the nudge @Stefterv!

Please file in an issue on the Processing for Android website repo describing the tutorial needed:

https://github.com/processing/processing-android-website/issues/new

Could be a good opportunity for a contributor maybe? @ranaaditya @JakubValtar would you be up for it or can you recommend anyone?

[JakubValtar]

@SableRaf Thanks for the ping, sadly I'm not up to date with the state of the Android SDK and don't have the bandwidth right now to look into it. I hope somebody else will be able to pick this up!

[SableRaf]

I made an (uneducated) attempt to update to Gradle 8.0 and Android 34 together, but I ran into a few issues. One tricky problem seems to be that GoogleVR is deprecated, which creates compatibility issues with Gradle 8 and Android 34. I know @p4puniya put a lot of effort into the Cardboard SDK migration, but they hit some roadblocks and would take more work to finish so we don't have an obvious path forward right now.

@codeanticode: Would it make sense to temporarily drop VR support if that helps people keep shipping apps to the Play Store? Maybe @phanirithvij or @ranaaditya have some thoughts too?

PS: There’s an untested draft PR made with @morisil's custom AI agent (using Claude 3.5) at #773

[codeanticode]

Oh that's cool, I will review the AI code then :-)

[morisil]

I believe that due the the knowledge cut off of the LLM the SDK version is not the latest one, but 33. At least claudine was able to make the code pass gradle build, after I manually removed one module from the build.

[p4puniya]

Hi all, so something to note about the new Cardboard SDK is that It can't be integrated with the older versions of processing as I've mentioned this earlier as well, since it's a library that's build on C++ and Processing is a Java Multi-module library. What can be done is create a new library that works entirely on the newer versions of Cardboard SDK and Gradle and build custom tutorials for the same.
Ps. This is as far as Google VR & Cardboard SDK is concerned.

About the issue with Gradle 8.0 compatibility, when I was working on P-Android, I had to download and manually import multiple versions of different libraries in order to get the Android Library working. One thing that I suggest here is, that instead of trying to build backward compatibility with the already existing apps, we can build a similar library with all the updated SDKs and dependencies. (Like a fresh new start for the Android Library)
This will be a time taking process and we will have educate the audience regarding the new changes, but I do believe that this is something worth investing in. This will also allow ease of access for the new generation of developers to start working processing android, as currently, just setting up the work environment with all the dependencies and libraries breaking seems like a really big roadblock for anyone starting afresh.
I know that this may seem like too much work, but If you are considering the bigger picture, this can be a much needed upgrade for the Android Library.
What are your thoughts? @SableRaf @codeanticode @ranaaditya

[SableRaf]

@p4puniya: thank you for the detailed insights and suggestions. I’m not entirely up-to-speed on the technical side but can add a few thoughts based on recent discussions. Please excuse any approximations.

First off, @Stefterv and I have been exploring the possibility of migrating the Processing4 build system and sketch runner to Gradle. This could allow Android to become just another build target within Processing, and would help minimize fragmentation, using a unified build system.

Currently, there seems to be a lot of coupling between core and specific SDKs, which adds complexity and makes the system more vulnerable to changes when Google updates or deprecates these SDKs. Modularizing the Cardboard SDK, Watch Face Format, AR Core, and Live Wallpapers could be a solution.

By treating individual SDKs as optional libraries (or separate modules), we’d avoid unnecessary dependencies in the core, allowing us to maintain a more stable codebase for building standard Android apps, which is likely the most common use case. I also suspect it might make it easier to continue to support older devices (?) but that's outside of my area of expertise.

Would love to hear any thoughts on this approach.