Since it’s a static method, the value is always available, and isn’t beholden to the Activity lifecycle. This is the crux of why you should now prefer setDefaultNightMode(), to minimize unnecessary recreations. In fact, any call to setLocalNightMode will trigger a recreation (if the theme changes). I recommend setting it in your application class (if you have one) like so: public class MyApplication extends Application ĭue to what we’ve spoken about above, that will now trigger a recreation in the new version of DayNight. The value you set is not persisted across process starts though, therefore you need to set it every time your app process is started.

The method is static so you can call it at any time. Changes between day/night based on the time of day. MODE_NIGHT_AUTO_TIME & MODE_NIGHT_AUTO.

Changes to dark when the device has its ‘Battery Saver’ feature enabled, light otherwise. This setting follows the system’s setting, which on Android Q and above is a system setting (more on this below). setDefaultNightMode(), which takes one of the follow values: The first API we provide to do that is AppCompatDelegate.

You then need to enable the feature in your app using one of the APIs provided. If you’re using Material Design Components (and I recommend you to do so), then you can also use the theme from their v1.1.0 release. You need to change your theme to extend from one of the DayNight variants, and then call one method to enable the feature. This has many benefits for your users, from saving power on OLED displays, to increasing usability for people with reduced-vision, and more.

The DayNight functionality in AppCompat allows your app to easily switch between a dark ⚫ and light ⚪ theme.

Android studio themes not w