Few things are as delightfully divisive as Android’s dark mode.

Some phones now ship with Android’s darker-style interface activated by default. Most reasonably recent devices offer it as a swift ‘n’ simple toggle. And most people, in my experience, have amusingly strong preferences about which approach they prefer — the standard Android “light” mode, in which screens tend to be bright and with shades of white as a foundation, and the dark mode (a.k.a. “dark theme”), where black and dark gray dominate and everything is much more muted and muddy.

It really is a night and day difference, so to speak — but no matter where you fall on the light vs. dark preference spectrum, it’s well worth your while to noddle over two pertinent points:

1. Android’s dark mode doesn’t have to be an all-or-nothing decision. With the right setup, you can use it as a dynamically activated sometimes switch that enables itself automatically based on different variables and gives you a darker, less glary motif when conditions call for it while leaving you with the lighter, brighter look the rest of the time.
2. Regardless of how often you’re using dark mode, a few easy adjustments will make it meaningfully more complete and effective as an end-to-end interface style for whatever you’re doing on your device.

It occurred to me recently that we’ve gone over several smart Android dark mode enhancements over the past weeks and months — and that, put together into a single power-pack bundle, these small-seeming items can add up to create a pretty dramatic difference in your Android-using experience, whether you’re a full-fledged dark mode convert or a more light-preferring vampire skeptic.

Here, specifically, are five easy ways to make Android’s dark mode meaningfully better for you.

[Keep the nerdy knowledge coming with my free Android Intelligence newsletter — something new and useful in your inbox every Friday!]

Android dark mode power-up #1: The app expansion

Up first is a feature that arose as part of our Android 17 discussion and sparked the entire idea for this collection — and that’s the one-tap switch in the latest Android version that forces every app on your phone to follow your dark mode preference, whether the program technically supports such a setting or not.

In Android 17, finding and flipping that switch will make every app turn dark whenever the system-wide dark mode is active. It eliminates the irksome exceptions that’ve traditionally stayed stubbornly light (due to developer laziness) even when your dark theme is on.

If you’ve got Android 17 on your phone already, it couldn’t be much easier to make it happen. Just look in the Display section of your system settings, tap the words “Dark theme,” then change the setting that shows up next from “Standard” to “Expanded.”

No Android 17? No problem: On devices with reasonably recent pre-Android-17 system software, you can actually find a switch buried deep in some developer settings that’ll let you enable the exact same option without any waiting.

Follow these instructions and enjoy your new universally consistent darkened dynamic.

Android dark mode power-up #2: A darkened web

That first trick fixes the issue of certain apps not following your dark mode preference — but what about the web? Most of us spend a fair amount of time in our browsers these days, and most websites won’t follow a dark mode setting and adjust their interfaces accordingly.

They absotively can, though. With the flip of a single switch buried within your browser’s bowels, you can force every website into a darkened motif whenever your system-level dark mode is up and running.

See?

Here’s the secret:

• Open up Chrome on whatever Android device you’re using. (And note that this will also work with any Chromium-based Chrome alternative, like Brave, Edge, or Vivaldi.)
• Type chrome:flags into the address bar.
• Type darken into the search box at the top of the screen that comes up next.
• See the line labeled “Darken websites checkbox in themes setting”? Tap the “Default” box beneath it, and change its setting to “Enabled.”
• Tap the blue “Relaunch” button at the bottom of the screen.

Now, when Chrome comes back a second or so later…

• Tap the three-dot menu icon in its upper-right corner.
• Tap “Settings” in the next menu.
• Scroll down until you see “Appearance.” Tap it, then tap “Theme.”
• Make sure the newly added box for “Apply dark theme to sites, when possible” — which we just magically made appear via our last little modification — is checked and active.

And that’s it: From that moment onward, whenever your Android device is switched into its dark mode, any website you’re viewing within Chrome will automatically follow suit. Nothing more to it, and no further thought or action ever required on your part.

Not bad, eh?!

Android dark mode power-up #3: A dark mode schedule

Even as someone who isn’t into dark mode as a 24/7 sort of thing, I can definitely appreciate the presence of a dimmer, less glary look on my device in certain specific scenarios.

It’s incredibly easy to overlook or forget, but Google’s actually got a way to handle that for you. In fact, it’s been built into Android itself since 2020’s Android 11 release.

Just look in the Display section of your system settings and tap the line for either “Dark theme” or “Dark mode settings.” If you see a toggle alongside that line, make sure you’re tapping the actual words next to it — not the toggle itself.

Then look for the option to create a schedule.

You can create a time-based rule for when your device’s dark mode turns on and back off again, or — more intelligent yet — you can set it to automatically activate at sunset, wherever you are at any given moment, and then turn itself back off and switch you back over to light mode at sunrise.

You can also integrate dark mode into Android’s rarely noticed Bedtime Mode so that the screen getting dimmer is part of your pre-sleep winddown routine, if you really wanna get wild.

Or — ahem…

Android dark mode power-up #4: Contextual dark mode

A dark mode schedule is pretty forkin’ sensible. But the reality is that even with a time-based setup or a sunset-driven activation approach, you’ll still be using your phone in bright rooms with dark mode active and vice-versa.

And if you want Android’s dark theme present only when you’re actually in a dark room — as makes the most sense in my mind — there’s an even more intelligent option.

It comes our way via a handy little free app called Adaptive Theme. That app does one thing and only thing only: It automatically adjusts your device’s dark mode setting based on the actual ambient light around you, using your phone’s sensors rather than an arbitrary time or a not-always-relevant sunset status as a guide. It makes so much sense, you’ll find yourself wondering why your phone didn’t just work that way from the get-go.

The app does unavoidably have a slightly complex one-time setup, which I outline step-by-step here. It’s perfectly safe to do, though, and it shouldn’t take you more than a couple minutes to pull off.

And once you’ve done that, your Android dark mode will just work for you — flipping on when the lighting around you is dim (to your exact specifications) and flipping back off when you’re in brighter surroundings.

Yes, please — and thank you. Last but not least…

Android dark mode power-up #5: The wallpaper wizard

Superficial as it may seem, the one piece of the puzzle we haven’t yet addressed — that isn’t ordinarily affected by Android’s dark mode setting — is your home screen wallpaper.

By default, whatever wallpaper you set at the system level stays the same even as your interface moves between its dark and light states — and when you’re anglin’ for a dimmer, less glary look in dark environments, that can be pretty darn jarring.

An app called, rather aptly, Dark/Light Wallpaper Scheduler is the answer you never knew you needed. It’s pretty self-explanatory — you tell it which wallpaper you want when your phone is in dark mode and light mode, then it automatically switches ’em out for you based on that status — but I wrote about it in detail here, if you’re interested in reading more about how exactly it works and how you can make the most of it.

And with that, my fellow Android-appreciating animal, your dark mode power-pack is complete. Now, would someone please turn off the lights? I don’t know about you, but all this talk of darkness has me hankering for a nap.

Wake up to even more useful Android wisdom every Friday with my free Android Intelligence newsletter — one practical new trick to try each week, straight from me to ye.

Microsoft has been pushing hard to make Visual Studio Code a major way to consume its AI services, mostly in the form of GitHub Copilot. GitHub Copilot’s deep integration with VS Code brings many conveniences — inline autocomplete, for instance — but it’s frustrating for those, like me, who would rather use another model provider, or even a locally hosted LLM, for those functions.

Visual Studio Code 1.122 introduced a new feature, “Use BYOK [Bring Your Own Key] without a GitHub sign-in,” that allows you to “use chat, tools, and MCP servers in air-gapped or restricted environments where GitHub sign-in isn’t possible.” More importantly, it “enables fully offline workflows with local models like Ollama.”

In other words, you can now use locally hosted LLMs for chat, tools, and Model Context Protocol servers inside Visual Studio Code. The one thing you still can’t do is use a local LLM for inline and next-edit suggestions — at least, not without additional tooling.

Choosing a model for BYOK mode

If you want to use a local LLM with VS Code’s bring-your-own-model system, the first thing you need is a way to host the model. VS Code lacks a model-hosting mechanism of its own, although it’s conceivable that a VS Code extension may offer something like that in the future. That said, hosting models is complicated enough that a dedicated app is really needed for the job.

One easy way to host models is via a product like LM Studio, a convenient GUI for standing up, serving, and managing LLMs on one’s own hardware. The model host does not have to be the same system you run VS Code on, either. It can be on a server box you control, or on a cloud instance.

The choice of model is also important. Many models are powerful but won’t run well on commodity hardware because they’re simply too big. A good rule of thumb is to choose a model that fits into existing VRAM, along with the memory needed for a sizable token context (the more, the better). Also, the model should be suited to coding and development work. Some models in this vein that fit comfortably into 8GB VRAM include:

• Gemma4 (effective 2 billion parameters version)
• Qwen3.5 9B
• Codestral 22B v.0.1 (proprietary license)

Setting up BYOK mode in VS Code

Once you have a model up and running, you can integrate it with Visual Studio Code. If you’ve disabled VS Code’s AI features, you will need to turn them on. Make sure the setting chat.disableAIFeatures is turned off. You can find it in Settings | Chat | Miscellaneous.

Third-party language models are managed through Visual Studio Code’s language model list. Press Ctrl-Shift-P and type Manage Language Models to open the list of existing language models.

First you will see a list of the built-in models, which are all externally hosted. To add a new model, select Add Models at the top right and select Custom Endpoint.

You’ll then get a series of prompts:

• Group Name: This is “Custom Endpoint” by default, but you can choose any name you want. The name is strictly for organizing the model list and doesn’t affect things like model recognition or connectivity.
• API Key: If you’ve configured LM Studio to use an API key for serving models, provide it here. If you’re hosting the model locally and you haven’t explicitly set up API keys, you can leave this blank.
• API Type: The options here are Chat Completions, Responses, and Messages. Most of the time you’ll want to use Responses, as it’s the most general-purpose option of the three.

Once you finish providing those answers, you’ll be dropped into a modal editor for a JSON file that holds the details about the endpoint you’re configuring.

You’ll need to provide a few more details by typing them into the labeled fields:

• id: A text field that uniquely identifies this particular entry. The choice of ID is pretty much arbitrary; if you’re using only a single model, the ID could be the model name.
• name: The name of the model that is used to identify it on the model server. In LM Studio, you can get this name by clicking on My Models in the main interface, then selecting the three-dot icon for the model in question and clicking Copy Default Identifier. For Qwen 2.5, for instance, name might be something like qwen2.5-coder-7b-instruct.
• url: The URL to the server’s endpoint. On LM Studio, this defaults to something like http://127.0.0.1:1234/v1. The /v1 at the end is important because that endpoint is used for autodiscovery of models and their capabilities.

The other fields generally don’t need editing. Most models have tool calling functionality. If you know for a fact that the model you’re using doesn’t have vision support, then set vision to false.

Once you have these fields filled in, you can close the modal editor to save the changes. If you reload the Manage Language Models page, you’ll now see your new endpoint:

You should now be able to launch the chat window and use the defined model for conversation and utilities:

One current, and major, limitation of Visual Studio Code’s BYOK functionality is that it only works for chat and utility tasks. It doesn’t allow you to use a local model for inline suggestions or code completions. The only way to take advantage of local models for expanded functionality with VS Code is to use a third-party tool like Continue.

It isn’t clear if Microsoft will eventually lift this restriction. GitHub Copilot integration in VS Code is a large part of how Copilot as a service reaches its target audience. For the time being, you can certainly use third-party and local models for a significant part of your AI-assisted development work in VS Code, and you can close the functionality gap with additional tooling.