Target Android API 37

[TimoPtr]

Summary

I had some doubt that we were going to loose the control of the volume from the notification commands but it seems that it continue to works properly since our app meets the requirements. https://developer.android.com/about/versions/17/behavior-changes-17#bg-audio

All the rest seems to work ok, wake word that use C code is working and the rest is not impacting us (if I didn't miss anything).

Checklist

• New or updated tests have been added to cover the changes following the testing guidelines.
• The code follows the project's code style and best_practices.
• The changes have been thoroughly tested, and edge cases have been considered.
• Changes are backward compatible whenever feasible. Any breaking changes are documented in the changelog for users and/or in the code for developers depending on the relevance.
• I have read the Open Home Foundation AI Policy.

Select exactly one option that describes AI usage in this contribution:

• I have not used AI for this contribution.
• AI assistance was used for this contribution.
• AI fully generated the code for this contribution, but I've reviewed and understood it before submitting and will respond without AI during review.

[Copilot]

Pull request overview

Updates the project’s target SDK to Android API 37, aligning the app’s target level with the already configured compile SDK in libs.versions.toml.

Changes:

• Bump androidSdk-target from 36 to 37 in the shared Gradle versions catalog.

[github-actions]

Test Results

  330 files    334 suites   13m 41s ⏱️
2 876 tests 2 875 ✅ 1 💤 0 ❌
2 932 runs  2 931 ✅ 1 💤 0 ❌

Results for commit 270ec21.

♻️ This comment has been updated with latest results.

[TimoPtr]

Strict mode violation on API 37

java.lang.AssertionError: Unhandled FailFast exception caught during test
at io.homeassistant.companion.android.util.TestFailFastHandler.handleException(HAAndroidJUnitRunner.kt:22)
at io.homeassistant.companion.android.common.util.FailFast.failWith(FailFast.kt:75)
at io.homeassistant.companion.android.common.util.HAStrictMode.enable$lambda$1(HAStrictMode.kt:55)
at io.homeassistant.companion.android.common.util.HAStrictMode$$ExternalSyntheticLambda1.onThreadViolation(D8$$SyntheticClass:0)
at android.os.StrictMode$AndroidBlockGuardPolicy.lambda$onThreadPolicyViolation$1(StrictMode.java:2128)
at android.os.StrictMode$AndroidBlockGuardPolicy$$ExternalSyntheticLambda0.run(D8$$SyntheticClass:0)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1100)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:1569)
Caused by: android.os.strictmode.DiskReadViolation
at android.os.StrictMode$AndroidBlockGuardPolicy.onReadFromDisk(StrictMode.java:1897)
at libcore.io.BlockGuardOs.open(BlockGuardOs.java:269)
at libcore.io.ForwardingOs.open(ForwardingOs.java:410)
at android.app.AndroidForwardingOs.open(AndroidForwardingOs.java:120)
at android.system.Os.open(Os.java:510)
at com.android.i18n.timezone.internal.MemoryMappedFile.mmapRO(MemoryMappedFile.java:50)
at com.android.i18n.timezone.ZoneInfoDb.loadData(ZoneInfoDb.java:192)
at com.android.i18n.timezone.ZoneInfoDb.loadTzDataWithFallback(ZoneInfoDb.java:127)
at com.android.i18n.timezone.ZoneInfoDb.<clinit>(ZoneInfoDb.java:50)
at java.util.TimeZone.getTimeZone(TimeZone.java:633)
at java.util.TimeZone.getDefaultRef(TimeZone.java:804)
at java.util.TimeZone.getDefault(TimeZone.java:777)
at java.util.Calendar.defaultTimeZone(Calendar.java:1704)
at java.util.Calendar.getInstance(Calendar.java:1674)
at java.text.SimpleDateFormat.initializeCalendar(SimpleDateFormat.java:762)
at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:706)
at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:685)
at android.util.TimeUtils.<clinit>(TimeUtils.java:52)
at android.os.Message.toString(Message.java:676)
at android.os.Message.toString(Message.java:669)
at androidx.test.espresso.base.UiControllerImpl$MainThreadInterrogation.setMessage(UiControllerImpl.java:625)
at androidx.test.espresso.base.Interrogator.loopAndInterrogate(Interrogator.java:127)
at androidx.test.espresso.base.UiControllerImpl.loopUntil(UiControllerImpl.java:513)
at androidx.test.espresso.base.UiControllerImpl.loopMainThreadUntilIdle(UiControllerImpl.java:434)
at androidx.test.espresso.Espresso.lambda$onIdle$2(Espresso.java:340)
at androidx.test.espresso.Espresso$$ExternalSyntheticLambda1.call(D8$$SyntheticClass:0)
at java.util.concurrent.FutureTask.run(FutureTask.java:328)
at android.os.Handler.handleCallback(Handler.java:1082)
at android.os.Handler.dispatchMessageImpl(Handler.java:135)
at android.os.Handler.dispatchMessage(Handler.java:126)
at android.os.Looper.loopOnce(Looper.java:295)
at android.os.Looper.loop(Looper.java:398)
at android.app.ActivityThread.main(ActivityThread.java:9572)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:575)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:842)

[jpelgrom]

I had some doubt that we were going to loose the control of the volume from the notification commands but it seems that it continue to works properly since our app meets the requirements. https://developer.android.com/about/versions/17/behavior-changes-17#bg-audio

#7211 suggests otherwise, are you sure? Did you test with the websocket service enabled by any chance instead of FCM? That would give the app a FGS so foregrounded which is more permissive, while most users will probably use FCM so background.

[TimoPtr]

I had some doubt that we were going to loose the control of the volume from the notification commands but it seems that it continue to works properly since our app meets the requirements. https://developer.android.com/about/versions/17/behavior-changes-17#bg-audio

#7211 suggests otherwise, are you sure? Did you test with the websocket service enabled by any chance instead of FCM? That would give the app a FGS so foregrounded which is more permissive, while most users will probably use FCM so background.

I did indeed tested without fcm but based on your comment on the pr it is already impacting the app.

[jpelgrom]

based on your comment on the pr it is already impacting the app

At least partially for any app on Android 17. Apps targeting Android 17 get another restriction with the FGS needing WIU capabilities. Looks like the websocket FGS satisfies that at least. As the impact doesn't seem to change with or without the target SDK level, let's not discuss on this PR and move any further discussion about this to the issue.

[jpelgrom]

Only other relevant behavior change should be local network permission but we've already had this impact us. I agree nothing else should break and I don't see issues either, so let's merge and see if we missed something this week.