Android app "forced" to dark mode

1

I have an app that always displays in dark mode on a Lenovo tablet running Android 10 (API 29) even though dark mode is turned off. I have the backgroundColor in Project Properties set to inherit. If I set it to white, the initial form looks fine with a white background until I scroll it, at which time the scrolled portion only shows up in dark mode with a black background.

My Android engine in config.xml is 10.1.2. This is not a problem with the web app or iOS – just Android.

I did find this which seems to point to the problem (but I’m not sure how to fix this in AppStudio): bug: Android forces Dark Mode on my Ionic apps · Issue #24771 · ionic-team/ionic-framework · GitHub.

Has anyone seen this before? My customer was able to reproduce on an Android 11 device as well. Oh, and I don’t see the problem in Android Studio emulators running API 28 to 31.

2

More experimentation is needed here.

The link you point to is for Ionic, another development environment. It adds some CSS to the app which causes the dark mode to happen. An AppStudio project will not have the same CSS.

If you want to change the CSS in an AppStudio app, you can do so in Open ProjectCSS under the Project menu.

Do you have a device with exhibits the issue? If so, do you see it with a simple HelloWorld app?

3

Yes, this happens consistently (i.e. 100% of the time) on a Lenovo TB-8505F tablet running Android 10.

I forgot to mention in my original post that in addition to my own app, the sample DarkMode app is also forced to dark mode. So, whether dark mode is turned on or off in Android Settings, the apps only show dark mode.

The research that I’ve done suggests that this may be due to a WebView change back in February. The Ionic folks say it’s an Android issue – not an Ionic framework issue. I realize AppStudio doesn’t use Ionic, but if that tool is affected this way, maybe AppStudio is too.

For Cordova, somebody suggested trying the cordova-plugin-android-dark-mode-support plugin which is supported by VoltBuilder. I tried that yesterday, but it crashes my app on startup. The docs for this plugin say to do this:

You need to enable Kotlin and AndroidX in your config.xml by setting GradlePluginKotlinEnabled and AndroidXEnabled to true .

I’m not sure what the exact syntax for this looks like in config.xml, though. My plan today is to make the config changes and try again.

4

Do you see it with the AppStudio HelloWorld app?

5

Yes, the sample HelloWorld app is affected as well. This is a screenshot directly from my Lenovo device:

image
image800×1280 26.6 KB

Here is the current dark mode setting:

image
image800×1280 42.1 KB

6

Good. Can you send me your Hello World apk? I’ll try it on the devices I have here.

7

Sure, my compressed APK file is attached.

HelloWorld.debug.v1.0.0.apk.zip (3.5 MB)

8

Thanks! It’s black on my device here too.

We will look into this.

9

Thanks. At least it is consistent. Yours is the third device, in addition to mine and one of my customer’s devices.

10

Turns out the fix is easy.

In Project Properties, there is a property called backgroundColor. The default is blank, which means it gets inherited from whatever the webview is set to. That lets it pick up dark mode if that’s how it is set.

If you always want the background to be white, set it to white.

11

Unfortunately, it’s only a partial fix. If the form is longer than the screen and you scroll down, the newly visible scrolled portion is shown in dark mode. Additionally, even though the white background setting is honored, the text color is reversed for dark mode as illustrated in the two screen shots for sample AppScrollLongForm below:

image
image800×1280 17.3 KB

image
image800×1280 41.4 KB

Android seems to be very insistent that the WebView display in Dark mode regardless of the actual Display setting.

12

There is a post in this board “background image doesnt fill scrolled form”.dont know whether it helps.

13

Thanks, I’ll study that post and see if it leads to a workaround, but something is fundamentally broken between Cordova and Android. It seems to have happened in February.

The apps work fine on iOS and in the web browser.

14

Although my app is a responsive app,i increased my form height in the form properties until the color flows to the whole form .see this might help?

15

Yes, that is a reasonable idea, but it didn’t work for my Android version of the app.

16

Hi,anyway,at that time of my app release,it wasn’t a real issue,may be you can ask nsb to sent you nsb appstudio that was released before feb . hopefully it could solve your problem.best rdgs,tst

17

my summary for the link u provided(1)temporarily remove dark mode support by disabling the @media (prefers-color-scheme: dark).(2)remove the color-scheme meta tag in your app’s index.html file.

(3)the issue appears to be fixed with WebView 99,but not on all phone.---------------------
(4)Some phone OS have automatic “dark mode fixer” (MIUI).filter out the entire media query from the css when building for android or iOS. Works, but not ideal.----
ionic and capacitor says it is not concerning them,the new web-view opts for dark mode.ask the user to open an error report at
https://bugs.chromium.org/p/chromium/issues/list
several user(may be 5)actively joins in.chromium says user are able to change mode.app work as expected,case closed.

18

If you are using VoltBuilder, how do you disable @media or remove the color-scheme meta tag?

19

Hi,anyone good at css,give it a shot…thanks in advance,tst

20

Hi, tst. I’m a step closer to a workaround. For the AppScrollLongForm sample app (see screen shots farther above), it uses container controls. I found that if you put those containers inside of another “master” container and then set all container background colors to white, it will display properly on Android.

For the master container bounds, I also set the width to 100% and the height about 100px larger than the form. Everything else is auto.

I don’t understand why this works. It’s all been pure experimentation. My app, though, uses the Bootstrap controls, so now I have to adapt this workaround to that.