google / android-fhir

The Android FHIR SDK is a set of Kotlin libraries for building offline-capable, mobile-first healthcare applications using the HL7® FHIR® standard on Android.
https://google.github.io/android-fhir/
Apache License 2.0
481 stars 259 forks source link

Update gradle to 8.8 and AGP to 8.5.0 #2575

Closed jingtang10 closed 2 months ago

jingtang10 commented 3 months ago

IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).

Description Update gradle to 8.8 and AGP to 8.5.0

Alternative(s) considered NA

Type Builds

Screenshots (if applicable)

Checklist

jingtang10 commented 3 months ago

addressed comments thanks aditya for reviewing

jingtang10 commented 3 months ago

After taking a look at the failure:

Lint found 2 errors, 38 warnings. First failure:
[1185](https://github.com/google/android-fhir/actions/runs/9566698928/job/26372611822?pr=2575#step:5:1186)
[1186](https://github.com/google/android-fhir/actions/runs/9566698928/job/26372611822?pr=2575#step:5:1187)/home/runner/work/android-fhir/android-fhir/datacapture/src/main/java/com/google/android/fhir/datacapture/extensions/MoreLocalDates.kt:128: Error: Implicit cast from IsoChronology to Chronology requires API level 26 (current min is 24) [NewApi]
[1187](https://github.com/google/android-fhir/actions/runs/9566698928/job/26372611822?pr=2575#step:5:1188)    IsoChronology.INSTANCE,
[1188](https://github.com/google/android-fhir/actions/runs/9566698928/job/26372611822?pr=2575#step:5:1189)    ~~~~~~~~~~~~~~~~~~~~~~

and trying to fix it without updating min sdk version, I realised we do need the ISOChronology class in order to get the localized date time pattern... without using this class, it's possible to generate the date time formatter object that is localized, but we won't be able to get the actually localized pattern e.g. yyyy-mm-dd (by calling the api getLocalizedDateTimePattern)... but we do need this pattern itself as the hint text...

now an alternative is to not use that as hint text, but instead use a formatted date e.g. 2019-09-12... which might be ok but it will just diverge a bit from the behaviour we have when the entry format string is provided by the questionnaire.

so i think the easiest thing to do is actually update the minsdk.. which i think wasn't an issue only because of the build tool wasn't picking it up since the api was indeed introduced in api level 26... so this way we're only making what was already the case explicit... (device on 24 would have had problem with this already).

MJ1998 commented 3 months ago

We dropped the minSdk (for all libraries) to 24 due to this issue #2077.

pld commented 3 months ago

Just to confirm, we're fine raising the min level to 26

jingtang10 commented 2 months ago

discussed today at the developers call and no objection so far to this api level change.

if we don't hear anything else we'll include this change in the next release