Lock Screen Notification Text Color Inverted in Dark Mode

[nickb24]

Subject of the issue

Link to the discussion thread: #3617
Every time a new reading comes in with the screen off and you turn the screen on, the xDrip ongoing notification colors are inverted.

Your environment

• 20240807
• G6 and Nightscout Follower for testing
• Android 14

Expected behavior

In dark mode, text should be white on the xDrip notifications at all times.

Actual behavior

Untitled-1.mp4

It has to do with the specific color you set in the Android theme settings. I had mine set to blue, and with that setting when setting the target sdk to 24 it causes the bug. sdk 23 or 29 don't have it. I was able to reproduce on an emulator as seen in the video. The bug is weird though since as you can see in the video, if you go past the lock screen and pull down the notification once, then it fixes the color. It stays correct until the notification refreshes after 5 minutes (when the next glucose reading comes in).

Steps to reproduce the behavior:

See video above.

[jamorham]

You mention target sdk level 29, do you know about 25, 26, 27, 28 ? The reason I ask is that we would plan to incrementally advance targetsdk levels because there are associated issues with each level - some of which we may not be able to overcome. So if this problem doesn't exist on the next target sdk level than that would be a convenient fix compared to anything more drastic.

[nickb24]

You mention target sdk level 29, do you know about 25, 26, 27, 28 ?

I just tested API level 25-28 and they all show the issue. I then compiled with 29 and the issue went away. I'm using an emulator in Android Studio running Android 14. I will re-try with an emulator running Android 15.

To be clear, the only line I'm modifying between builds is the following:

xDrip/app/build.gradle

Line 95 in 5345dd5

targetSdkVersion 24

[jamorham]

Ok thanks, that is useful but changing targetSdk level to 29 is a gigantic change in terms of app behavior so I am hoping to find a resolution which doesn't involve doing that.

[Navid200]

changing targetSdk level to 29 is a gigantic change

I agree.

When we retired Android 6 a few months ago, there were complaints even though Android 6 is really old.

If we change the target to 29, we will be retiring 7, 8 and 9. If we do that now, we will be denying access to xDrip to a significant population worldwide. It is too soon for that now.
The next step should be retiring Android 7 and I hope we can delay that as much as possible.

[nickb24]

If we change the target to 29, we will be retiring 7, 8 and 9.

I don't know if that's entirely true. Changing the targetsdk is not the same as changing the minsdk.

• minSDK: The minimum API level that your app requires to run. This means that your app will only be available to users with devices that have this API level or higher.

• targetSDK: The API level that your app is designed to run on. This means that your app will use the features and APIs that are available in this API level.

[Navid200]

I see. Thanks for correcting me.

[nickb24]

I also just tried API 28 on an emulator running the latest image of Android 15 and the issue is still there.

[jamorham]

The most significant thing about changing the targetSdk level is that it opts the app in to new behaviors and restrictions.

[Navid200]

If we had a fully functional alpha channel, many would be using it and the Nightly channel would then be what it in my opinion should really be to test things like this.

We could then release a Nightly going forward one step changing the target sdk and I would announce its purpose.
Then, we could go over every step to 29. Say 1 week for each. We would then know which targets have serious compatibility issues for the users. And hopefully we could identify if any issues affect only an intermediate target.

Having all of that knowledge, we could then decide if we should really switch the target to 29 or not now.

In the meantime, those who like to have more updates than only twice a year could use the alpha channel.
But, currently, our alpha and beta channel both provide two releases a year. So, there is no incentive for any user to use the alpha channel over the beta channel.

I am happy to maintain the alpha channel.