Support Android 15

[mrjones-plip]

Is your feature request related to a problem? Please describe. Android 15 is schedule to be released in the next 2 or 3 months.

Describe the solution you'd like We should ensure CHT Android 15, doesn't have an regressions, doesn't need any new features in CHT Core etc.

Describe alternatives you've considered Hope that Android 14 work is sufficient or wait until a problem is found in the field.

Additional context NA

[m5r]

Progress so far: most behavior changes mentioned in the Android 15 changelog are covered by the code in the PR or don't affect cht-android. The last remaining behavior change affecting us is the edge-to-edge enforcement (see screenshots in the PR description).

Google recommends handling overlaps using insets with ViewCompat.setOnApplyWindowInsetsListener but following their example doesn't scale with the app as the handler in charge of repositioning stuff on the screen doesn't get called when swapping the displayed content with setContentView so the elements are back to overlapping with the status and navigation bars. On top of this, it adds a lot of boilerplate code in each of our 12 activity classes that we have.

I've found the view property android:fitsSystemWindows="true" to have the same effect as the code implemented before which would be the preferred solution as all the layout stuff is handled by Android itself. But it suffers the same issue as the implemented code... I did run into some suggested solutions but I could not make it work so far.

It doesn't seem to affect us past the initial CHT instance selection screen, that's the only activity I found where the content gets swapped with setContentView where all other activities have only one view. It's mainly an issue for partners with multiple CHT instances in a single app (like MoH KE) and for our development/testing purposes.

Android 15 phones can install and run the app as is without any changes (but with the layout bug mentioned above). And we will be able to publish the app to the play store without upgrading the target SDK until August 31, 2025 according to Google's schedule.

[mrjones-plip]

Thanks for all the research on this @m5r ! We can pause the effort on this ticket for now.

cc @derickl & @PhilipNgari - i think eCHIS KE is the only production deployment that is affected by this when selecting an county on first time app launch.

cc @garethbowen - to be sure you're aware of the research done on this ticket and the timeline of target SDK

[paulpascal]

Sorry @mrjones-plip for the delay in reporting back here.

I've also explored the insets handling issue, and like @m5r found out, while ViewCompat.setOnApplyWindowInsetsListeneroffers more granular control, the added complexity and boilerplate, particularly across multiple activities, remains a concern. Given our use of dynamic content swapping via setContentView, we should expect inconsistency in repositioning UI elements :). (same issue occurs with android:fitsSystemWindows="true" resulting in the same problem).

@m5r By the way, I've noticed that using fitsSystemWindows on a view that contains the entire layout(and the bg), prevents the app from achieving a true edge-to-edge appearance. I've learnt that fitsSystemWindows manages insets on all edges, causing gaps that shouldn't be there.

For more control, I started exploring WindowInsetsCompat and WindowInsetsController to manage insets programmatically and reduce the need for boilerplate across activities, though I haven't fully tested it yet.

[mrjones-plip]

Awesome - thanks for the update @paulpascal - I hope your explorations with WindowInsetsCompat and WindowInsetsController help us find a solution!