Outdated Android release (last release from Feb 24, 2023) lacking new style expression features compared to iOS

[JannikGM]

Android and iOS have diverged because of a lack of releases on the Android side.
This means we can't roll out style updates which depend on new features of the style-spec due to lack of support in Android (iOS should be fine already).

Effectively, the last Android release is: https://github.com/maplibre/maplibre-native/releases/tag/android-v10.0.2 (aliased by https://github.com/maplibre/maplibre-native/releases/tag/android-v10.2.0).
This is from Feb 24, 2023.

• Since then, there was a breaking-change release which got rolled back: https://github.com/maplibre/maplibre-native/releases/tag/android-v10.1.0 which introduced index-of expression in Implement index-of expression #1113, but due to the rollback it's still missing.
  - Not supported on Android: https://maplibre.org/maplibre-style-spec/expressions/#index-of

• Also since then, slice expression was merged in Implement slice expression #1133, but due to being even later, there's absolutely no release ever of it (despite being in codebase for almost half a year by now).
  - Not supported on Android: https://maplibre.org/maplibre-style-spec/expressions/#slice

So, please, release another Android maplibre 10.x version with these features (although there might be more relevant changes).
Especially do this if the plan is to work on Android maplibre 11.x with the breaking OpenGL ES 3.x changes.
There should still be some OpenGL ES 2.x version with the new expressions (so we can support the new styles).

The current situation is pretty bad, seeing how https://github.com/maplibre/maplibre-native?tab=readme-ov-file#platforms says that Android is a Core platform. Yet, there have been plenty of Node.js releases (which isn't even Core) but no Android release in almost a year despite countless features and bugfixes.

Tagging @louwers who is Maintainer and did the previous Android releases.

[acalcutt]

Just an FYI there is a style-spec PR to add the support for 'slice' and 'index-of' in android at maplibre/maplibre-style-spec#362
It does look like it is waiting for a release. it has been released in node-v5.3.1, but right now node isn't on that supported chart.

Also you mention making a OpenGL-2 release with slice and index-of. I did just merge those features into the opengl-2 branch so I could make the latest node release. Maybe with some effort a android release could be made from that branch.

[acalcutt]

btw, the many node releases are mainly due to my efforts as a community contributor. I have been pestering @ntadej for weeks with cherry picks in the OpenGL-2 branch to try and get it to a place I could make those node releases and get the features that have been requested here and tileserver-gl.

[acalcutt]

What would actually be needed to create a android release from the OpenGL-2 branch? I think the android bits of 'index-of' and 'slice' were already cherry picked in https://github.com/maplibre/maplibre-native/pull/2023/files#diff-4e06a39501bf8a9fb6567951884cfb53d821195d1812f0b6a97a8504fcdf6b35

I ran a test of the android-ci for a copy of that branch at https://github.com/WifiDB/maplibre-native/actions/runs/7751082715 and it still seems to build

Would a release basically be running the android-release workflow on the OpenGL-2 branch? I wouldn't mind assisting in getting the workflows for the ci working, but it almost looks like a release could be run from that branch now since the ci seems to pass.

[JannikGM]

I'm not even sure if I need OpenGL ES 2.x - that's beyond my control.

Here's some background on how I work:

• Among other things our company creates mapbox / maplibre styles and host tileservers with those styles.
  • I'm responsible for the expressions in the styles (= advanced features you wouldn't do with style editors).
  • I have to ensure that I can tell other teams what version of a map client they should be using.
• These tiles / styles are used products which use maplibre or mapbox.
  • We have inhouse coding teams which create mobile apps for iOS and Android.
  • We have an inhouse coding team which does web apps.
  • We also have third-party business partners which use our tileservers and styles in their own apps.
    • Some of these products might even be on life support where code changes aren't possible, but upgrading dependencies for features / security / bugs is possible.

Often inhouse designers (not coders!) or partners ask for new features in the styles.
We can develop and deploy it for them, but it's of no use to them if their product is unable to handle the style (e.g. their maplibre / mapbox doesn't support it).
Upgrading such mapbox/maplibre dependencies is done by another team (coders) beyond my control, as they might be busy with other things (so major version upgrades are problematic, or even impossible due to breaking other requirements like device compatibility).
So the only good solution is to upgrade to the latest minor version of a library (which they likely do on a regular basis and it's very cheap - it might not even be done by coders but release-managers), then we can safely deploy the map style.

For Android, we likely must also support legacy devices in some of our apps; one of these apps alone has 1+ million downloads.
If we break device compatibility or require code changes, we'd likely run into trouble - both inhouse and with partners.
Even if a small percentage of users are affected, this would affect hundreds of users and cost partners a lot of money in revenue (aside from potential backlash if the sold products suddenly stop working on devices).
Therefore the hardware requirements they have is also a business decision - and the decisions of our partners can be beyond our control.

All I want to be able to say is: "Update your map renders to the latest minor version you are already using, and you'll be fine" (= no code changes / no loss in device compatibility / cheap to do by a click of a button).
- that would be the solution, as soon as Android maplibre 10.x had these features.
- that would not be the solution if this required modifying codebases and system requirements for maplibre 11.x (= requires code changes and might break device compatibility which also involves updating docs for system requirements, etc. etc.).

[JannikGM]

Ah, thanks. Now I read it properly. Feel free to try to make another Android 10.x.x release from the opengl-2 branch!

To me, the next android-10.3 should be based on android-10.2.x.
Otherwise, wouldn't there be a risk of introducing other breaking features or bad code which introduces more bugs (= code which is part of opengl-2 but not part of android-10.2.x)?

I feel like these branches should exist:

• main branch (development continuing at Android 11.x and iOS 6.x): which is for development of current major version.
• android-10 branch (development continuing at Android 10.2): which can be used to cherry-pick new features in (leading to android-10.3 branch and release); iOS might to have this in form of ios-5?
• android-10.2 branch (development continuing at Android 10.2.0): which can be used for cherry-picking security/bugfixes (leading to android-10.2.1 release); interestingly, this does not exist at all.

Unless backporting is exclusively done by maintainers.. which is fine, but this didn't seem to happen in the past? There'd also have to be a process of how backporting can be requested then.

[louwers]

To me, the next android-10.3 should be based on android-10.2.x.
Otherwise, wouldn't there be a risk of introducing other breaking features or bad code which introduces more bugs (= code which is part of opengl-2 but not part of android-10.2.x)?

Yes, that makes sense. This is the same approach we use when a security problem is found.

Unless backporting is exclusively done by maintainers..

Right now, we don't officially have LTS releases. So I am not backporting stuff, but if you need something backported, you can step up as a co-maintainer yourself and make it happen. Your plan sounds good!

There'd also have to be a process of how backporting can be requested then.

You just did! But maybe it would be good to have a more formal process in place.

By the way, there was a short discussion about LTS releases during the technical steering committee meeting of August last year.

[louwers]

@JannikGM I created the branches you requested. Feel free to make cherry pick PRs to get them ready for release. It is possible that some changes to the release workflow have to be made to accommodate backporting.

[JannikGM]

Done: #2094 - this should be done; let me know if you need any changes.

I also had to enable CI (as I didn't have any Android SDK locally and CI is misconfigured): #2095 - this will require further cleanup of the existing branches on this repository (by maintainers).

I'm not sure if there's anything else that should be backported to 10.x (bugfixes or so?); it's a bit hard to figure out what to backport as each platform has its own changelog.
Ideally the slice and index-of changes also would never appear in the Android specific changelog (as they were never Android specific) but in a generic changelog.

[wipfli]

Thanks for the feedback @JannikGM.

We had some performance regressions in Android due to the modularization and decided to fix these before making a new release.

@sjg-wdw can you comment where things stand with respect to Android performance?

[louwers]

This has indeed been delaying the Android release. The next release will be a breaking release, so we want to batch it with the new renderer.

These are the latest numbers from @alexcristici.

The target was within 5-10% performance of the legacy renderer. So if these numbers are valid it looks like we could go ahead with an Android release sometime this month. Does that sound OK @JannikGM ?

[JannikGM]

Ideally index-of and slice would also be in maplibre 10.3, not just 11.x.

As I explained in #2078 (reply in thread) it might be problematic if developers have to get involved to adapt code from 10.x for 11.x (breaking changes in API) or if it breaks device compatibility (breaking changes for the end-user).

In other words: Follow proper semver + ensure the release management allows new minor versions (at least for non-breaking style-spec changes) for the last major version (temporarily):

• For breaking changes in the API, this only has to be a couple of weeks or months probably, so developers can upgrade their products.
• For breaking changes affecting the end-user, this has to be much longer so business decisions can be made, the support staff can change documentation and end-users potentially have time to upgrade their devices (or developers can switch to another solution altogether to avoid breakage.. this might involve forking / setting up infrastructure).

[ntadej]

And as @acalcutt said, I'm happy to merge stuff in the OpenGL 2 branch, but you'll have to do the final testing yourself.

[louwers]

The 10.3.0 release has these features. Thanks for helping with the backporting @JannikGM.