medic
Support Android 15
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
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.
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
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.setOnApplyWindowInsetsListener offers 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.
Awesome - thanks for the update @paulpascal - I hope your explorations with WindowInsetsCompat and WindowInsetsController help us find a solution!
There was a question asked:
If we can't wait till he's back, how urgent is this? Do we have any of our program's that could soon be impacted by this?
While we can't know for certain, a good way to guess would be to answer "How many devices are on Android 14 and thus eligible for an update to 15?" By looking at 5 large deployments, we can see the distribution of Android versions. Here's the short, tabular version:
| Instance | Android 14 %* | Active users past 30 days |
|---|---|---|
| MoH KE Training instance | 1.8% | 560 |
| MoH KE Nairobi | 3.7% | 7800 |
| MoH Togo | 6.3% | 560 |
| MoH CIV | 0% | 590 |
| MoH Mali CHW | 5.0% | 1800 |
* These are approximations. Percentages calculated by using user-devices API, which queries end user device stats based on all telemetry. Percentage thus may not include users who, for what ever reason, were unable to send telemetry or may be biased toward newer devices.
Here's some visualizations around the same data (see raw data too):
Data gathered with these three CLI calls:
curl -qs https://USER:PASSWORD@CHT-URL/api/v2/export/user-devices > results.json
sed 's/\,/\n/g' disc-mali.ml.json > results.breaks.json
grep -i results.breaks.json |grep -vi browser| sort|uniq -c
Google Play has flagged 15 of our apps for targeting outdated Android versions. To comply with their policy and ensure user safety, all apps must target the latest Android version by August 31, 2025.
App must target Android 15 (API level 35) or higher
Thanks for commenting on this ticket @binokaryg ! I suspect that targeting API 35 or higher in a PR will not fix the edge-to-edge enforcement that m5r mentioned in his draft PR. I think this is fine and we should release new APKs with a known edge-to-edge issue on the instance selection screen. We can fix it at a later date so as not to block larger Android 15 support for the 15 instances you mentioned
I see APK 36 is out for Android 16. If it's low risk of adding complications, seems like we should go for that vs 15's 35
Google Play has flagged 15 of our apps for targeting outdated Android versions. To comply with their policy and ensure user safety, all apps must target the latest Android version by August 31, 2025.
App must target Android 15 (API level 35) or higher
I agree with @binokaryg on this, there need to target android 15 or higher is now more important due to this fixed deadline set by Google as outlined here: https://developer.android.com/google/play/requirements/target-sdk
While I'm assigning this ticket to me - I'm not sure I'm the best candidate to work on this if things get sticky. I'll be vocal if I get stuck, but trying easy changes for now (bumping version strings, seeing what sticks to the wall)
That was quick! I've no idea what I'm doing here - handing this ticket and related PR to ...someone? @jkuester ? Community?
@karimkkanji - I saw you opened a test draft PR for this issue. If you're interested in trying to complete this issue - we welcome your efforts! Let me know by responding here and I can assign you the ticket. We're available to support you if you hit any problems!
Yes @mrjones-plip started a PR but realized there are tests that need to be updated and not really conversant with Mockito
There were errors from Roboelectric, and I saw this:
we released Robolectric 4.15 today (June 19, 2025), but it does not provide support for API 36. This will come in the next version of Robolectric.
Let's see if we can target Android 15 (API level 35) for now. We might not need Android 16 yet.
@mrjones-plip created a PR here: https://github.com/medic/cht-android/pull/407 @binokaryg some of the changes in your branch are included. Thanks for the changes in the PR!
CC: @eljhkrr