Android 16 Developer Preview 1 (DP1) has landed early, giving us a sneak peek at 2025’s Android upgrade. Beyond the headline features Google announced, there are several lesser-known additions tucked into DP1 (and subsequent previews) that can significantly impact developers and power users. From new APIs that unlock advanced capabilities to subtle UX improvements, Android 16 is packed with hidden gems.
In this article, we’ll dive into 8 hidden Android 16 features you must try, explaining what they do, how they compare to Android 15, and why they matter.
1. Embedded Photo Picker (Now with Cloud Search)
One welcome change for developers in Android 16 is the embedded photo picker. Previously, when an app prompted you to select images or videos, Android would launch a full-screen system picker interface. In Android 16 DP1, apps can now embed the system photo picker directly into their own UI via new APIs. This makes the file selection experience feel like a native part of the app, while still benefiting from Android’s privacy protections (only granting access to chosen media, not your whole library). In practical terms, a social media app could, for example, display the image picker within a post creation screen, maintaining visual consistency with the app’s design.
To integrate the embedded picker, developers will use the new Jetpack library (forthcoming alongside Android 16) instead of starting an external ACTION_PICK intent. The benefit is a smoother UX — no more context switching to a separate picker window. Compared to Android 15, which only allowed the overlay picker, this gives developers much more control over the user experience.
code snippet:
// In your Fragment or Activity
private val pickMedia = registerForActivityResult(
PickVisualMediaRequest(ActivityResultContracts.PickVisualMedia.ImageOnly)
) { uri: Uri? ->
// handle chosen image URI
}
fun showEmbeddedPicker() {
// Launches the system picker inline
pickMedia.launch(PickVisualMediaRequest())
}Android 16 DP2 goes further by adding search functionality for cloud media in the photo picker. This means users will be able to search across their linked cloud storage (Google Photos, etc.) right from the picker. The APIs for cloud search are in place in DP2, with the feature flagged as “coming soon.” Once enabled, it could allow, say, a photo printing app to let you search your Google Photos within the picker for that one picture of your dog in a Halloween costume. It’s a small addition with big convenience. For developers, it’s essentially free functionality – just adopt the updated picker and your app gains cloud search capabilities without extra work.
Real-world use case: Imagine a travel journaling app where users embed photos into entries. With Android 16’s embedded picker, the app can show a scrollable image grid inline, themed to match the app. Users could even search their cloud backups for “Eiffel Tower” directly in the picker. This tight integration wasn’t possible in Android 15 without building a custom picker (and requesting broad storage permissions). Now it’s a built-in feature, keeping user data access minimal and UX seamless.
2. Notification “Cooldown” to Tame Spammy Apps
Tired of apps bombarding you with back-to-back notifications? Android 16 introduces Notification Cooldown, a hidden feature aimed at reducing notification overload. If an app fires off a flurry of alerts in a short time, Android 16 will automatically lower the alert volume and minimize the interruptions for a brief period (up to about 1–2 minutes). Instead of your phone chiming incessantly, subsequent notifications during the cooldown window will arrive silently (you’ll still see them in the notification shade, but without sound or full interruption).
This feature actually first appeared in the Android 15 previews but never made it to stable Android 15. Now in Android 16 DP1 it’s back, more polished, and enabled by default. Users can toggle it in Settings > Notifications if needed. Compared to Android 15, which had no such throttle (aside from Do Not Disturb), this is a quality-of-life improvement. It particularly helps in scenarios like a chatty group chat or an app that sends rapid updates (think breaking news alerts or game notifications) – your phone won’t become an incessant noise machine.
For developers, Notification Cooldown is mostly handled by the system. However, it’s a gentle reminder to batch or rate-limit notifications if possible. From a UX perspective, if your app triggers the cooldown frequently, it might signal to users that your notification strategy is too noisy – and they might opt to disable your notifications entirely. Android 16’s approach benefits users by automatically controlling the deluge without the user having to tweak settings for each app.
Real-world example: Suppose you install a stock trading app on Android 15 and enable alerts. On a volatile day, it might ping you 10 times in a minute – each with sound/vibrate – which is both stressful and battery-draining. On Android 16, after the first few alerts, the system will quiet the notifications for the next minute, showing them silently. You’ll still get the info, but your phone won’t be buzzing non-stop. This gives you breathing room until the “cooldown” ends. It’s like Android is smartly applying a temporary Do Not Disturb specifically for the overactive app.
3. “Modes” Replacing Classic Do Not Disturb
Android’s Do Not Disturb (DND) is evolving into something more flexible in Android 16. Hidden in DP1 is a new “Modes” feature that is essentially DND on steroids. Instead of a single blanket DND toggle, you can create multiple custom modes – e.g. a Sleep mode, Work mode, Gaming mode, Meditation mode, you name it – each with its own settings for notifications and behaviors. This feature was teased in Android 15’s QPR (Quarterly Platform Release) betas, but now looks slated for Android 16 proper.
In Android 15 and earlier, you had to manually adjust DND settings or schedules for different scenarios (or use third-party apps). Android 16’s Modes let you switch between profiles with a couple of taps. For example, a “Bedtime” mode might silence all but emergency contacts and fade the screen to grayscale, while a “Work Focus” mode might only allow work email and Slack notifications, and maybe enable vibrate. The key is you can define these modes as you see fit.
Once set up, the old DND quick settings tile becomes a “Modes” tile, tapping which pops up your list of modes to choose from. This does make simple DND a two-step action now (open modes, then choose one – slightly less convenient if you just want total silence). But for those who want nuance, it’s powerful. Compared to Android 15, which had a single DND with perhaps some scheduling, Modes in Android 16 provide a personalized do-not-disturb experience. It’s similar to iOS’s Focus modes, bringing Android up to par in this area.
Real-world use case: You could create a “Driving” mode that activates when your phone connects to your car’s Bluetooth, blocking notifications except navigation alerts and incoming calls. Or a “Kids Time” mode that only allows whitelisted family contacts and educational app notifications. Rather than digging into DND settings each time, you just select the mode. Developers can tie into these modes too – for instance, a meditation app might prompt the user to enable a custom Meditation mode (quieting the device and maybe even turning off ambient display). It’s a subtle feature, but one that can significantly shape user experience across contexts.
4. Bluetooth Audio Sharing (Broadcast Audio via Auracast)
Have you ever wanted to stream your phone’s audio to multiple Bluetooth devices at once? Android 16 might finally make that possible with its resurrected Audio Sharing feature. In DP1, the Bluetooth settings reveal an Audio Sharing option that wasn’t present in Android 15 stable. This feature is built on Bluetooth LE Audio’s Auracast broadcasting technology – allowing one device to act as an audio transmitter to many receivers. In plain terms, your phone could broadcast music and any nearby Auracast-compatible earbuds, headphones, or speakers could tune in.
Audio Sharing was actually spotted in Android 15 DP2 but never made it to release. Its return in Android 16 DP1 suggests Google is still working on it. The DP1 implementation already shows a polished UI: you can set a broadcast name (e.g. “John’s Party Playlist”) and even a PIN code if you want to restrict who can join. There’s a compatibility toggle as well, hinting that it can be optimized for specific device types like hearing aids.
Why is this exciting? For one, it enables new social and multi-user experiences. Think sharing a podcast with a friend on their own earbuds during a commute, or a group of runners each with headphones listening to the same workout playlist from one phone. Previously on Android, you were mostly limited to streaming to one device at a time (some manufacturers like Samsung had a dual audio feature, but it’s not common). Android 16’s approach is standardized and part of the OS, so any app can leverage it without special hacks.
From a developer’s standpoint, there might be new APIs to control or detect broadcasts, but much of it will be at the system level. Media apps, however, should test how they behave when multiple outputs are active. For instance, does your music player keep playing smoothly when two listeners connect? It should, thanks to LE Audio’s design, but it’s worth verifying.
Real-world example: You’re watching a movie on your tablet with a friend – instead of playing the audio on loudspeaker (disturbing others) or sharing a single pair of earbuds (hygiene issues aside), Android 16 would let your friend tune into your tablet’s audio stream with their own earbuds. Both of you hear the movie in sync, each with your individual volume control. Or imagine in a gym class, the instructor broadcasts music from an Android 16 phone, and everyone with compatible earbuds hears the high-fidelity audio directly, instead of blasting it over speakers. These scenarios become possible with Audio Sharing in Android 16.
5. Auto-Hiding of Sensitive Notifications on Lock Screen
Privacy gets a boost in Android 16 with a feature that automatically redacts sensitive notification content on the lock screen. If you’ve ever gotten a two-factor authentication SMS (OTP code) or other sensitive info, you know how it shows up on your lock screen for anyone nearby to peek at. In Android 16 DP1, the system can now hide the content of certain notifications (like 2FA codes) on the lock screen by default. You’ll still see that an app (say Messages or your authenticator) has a notification, but the preview will say something like “Sensitive content hidden.”
Android actually took a step in this direction in Android 15 by preventing third-party apps from reading these sensitive notifications even if they had notification access permission. Android 16 extends the protection to what you see on your own lock screen. Importantly, this happens regardless of your notification settings. Even if you’ve set “Show all notification content on lock screen,” Android 16 will intelligently redact things deemed sensitive by Android System Intelligence (the on-device AI that parses notifications). So far, OTP codes are confirmed to trigger it, but it could apply to other categories as Google refines the detection.
How is this different from Android 15? Previously, if you wanted privacy, you had to manually enable the option to hide sensitive notifications (which hides content for all notifications). Android 16’s approach is granular – truly sensitive ones (like login codes) get special handling, while others still show normally. It’s like having the best of both worlds: you don’t miss important info on your lock screen, but your one-time passcodes or possibly things like medical appointment details won’t display for prying eyes.
For app developers, there’s not much you need to do – the OS handles it. But it’s good to be aware of this behavior. If your app sends notifications containing OTPs or similar info, know that users on Android 16 might not see the content until unlocking the phone. You might consider the new Notification Trampoline API (if provided) to direct users straight to the relevant app screen when they tap such a notification, since the preview is hidden.
Real-world impact: Suppose you’re using a password manager app that sends a push notification with a one-time code for login. On Android 15, if you hadn’t hidden sensitive notifications, that code would pop up on your lock screen for anyone around to glimpse. On Android 16, that notification would show the app name but not the code itself, unless the phone is unlocked. It’s a subtle but important security upgrade. Or consider ride-share apps sending one-time pickup codes, or banking apps sending transaction OTPs – all that info stays out of sight on the lock screen by default, potentially foiling shoulder surfers and opportunists.
6. Writing Tools API – Let Apps Disable AI Autocorrects/Rewrites
With the rise of AI-powered features in keyboards (like Gmail’s Smart Compose or Gboard’s AI-driven “proofread and rewrite” capabilities), Android 16 introduces a developer API to give apps control over these AI writing tools. The new WritingTools API (added in Developer Preview 2) lets an app indicate that in certain text fields, generative AI writing assistance should be disabled. In essence, your app can opt-out of AI suggestions or rephrasing for specific inputs.
Why would you want to do that? Think of fields where AI-suggested text makes no sense or could be risky: passwords, PINs, phone numbers, email addresses, or maybe an essay exam app where AI assistance would be cheating. By default, AI writing tools are enabled for all text inputs (Google’s Gboard and some third-party keyboards offer options to rewrite text using AI). With Android 16’s new API, an app can say “no thanks” for a given EditText
Under the hood, this is achieved via two new methods on the EditorInfosetWritingToolsEnabled(boolean)isWritingToolsEnabled()
Comparison to Android 15: Previously, apps had no control over keyboard features beyond basics like input type (text, password, etc.). If the keyboard decided to offer a “fix grammar” or “generate reply” button, it would appear even in places it shouldn’t, unless the keyboard itself internally suppressed it. Android 16 empowers app developers to explicitly disable those writing aids where they’re not appropriate. It’s a proactive step to prevent AI from interfering in contexts it doesn’t belong.
It’s worth noting that this doesn’t guarantee a user can’t use AI – a determined user could still use an external tool or another app to generate text and paste it. But it removes the convenience of doing it inline, which is often enough to deter casual use in restricted scenarios. Ultimately, the onus is on keyboard developers to honor the flag. Most mainstream ones likely will, especially Google’s own keyboard.
Real-world use case: A banking app could mark its Account Number and Password fields with setWritingToolsEnabled(false)
code snippet:
EditText secureField = findViewById(R.id.password_input); EditorInfo info = secureField.getEditorInfo(); info.setWritingToolsEnabled(false); // disable AI suggestions here
On Android 16, Gboard would then not show options like “Improve this sentence” or “Rewrite” (which obviously don’t apply to a password or numeric field). Or consider a secure messaging app that wants to ensure messages are user-authored – it might disable AI suggestions in the message input to encourage genuine communication. Another example: an exam application can disable AI writing help in answer fields, to at least prevent built-in tools from offering to “complete” the student’s answer. While not foolproof against cheating, it sets a boundary within the platform’s UX.
7. Richer Haptic Controls for Developers
Android 16 gives developers deeper control over device haptics (vibrations) than ever before. Until now, haptic feedback on Android was limited to a handful of pre-defined effects or simple on/off patterns. Android 11 introduced some advanced effects (like textured vibrations) for devices with richer actuators, but it was still relatively constrained. In Android 16, new haptic APIs let apps define custom vibration waveforms by specifying amplitude and frequency curves for the effect.
This essentially means if the device’s hardware supports it, you can program exactly how a vibration should feel – its intensity over time and even the vibration frequency (which can create different sensations). Importantly, the API abstracts away differences in hardware. Some phones have a linear resonant actuator (fancy vibrator that can do varied frequencies), others just have basic motors. The Android 16 API will do the best it can on each device to approximate your desired effect.
How is this different from Android 15? Prior to Android 16, if you wanted a complex vibration pattern, you might use VibrationEffect.createWaveform(timings, amplitudes, repeatIndex)VibrationEffect.Composition
For performance, Android handles the heavy lifting natively. Developers just define the curve. You might specify, for example, a haptic effect that starts at 150 Hz and ramps down to 80 Hz over 1 second while amplitude goes from 0 to 70% – producing a “vrrrrrm” that simulates a power-down feeling. On Android 15, you simply couldn’t do that; you were stuck with amplitude control only or preset effects like EFFECT_HEAVY_CLICK
Use case: A meditation app could create a custom haptic pattern that feels like a pulsing heartbeat to aid relaxation. Or a messaging app’s custom notification vibe could have a distinct “signature” – maybe a quick buzz, slight pause, followed by a gentle low-frequency rumble for a second. With Android 16’s richer haptics, these nuanced experiences are possible and can help apps stand out. Developers should also be mindful to use this power judiciously – not every notification needs to shake the user’s hand off! But for truly meaningful feedback, like confirming a user’s action with a satisfying haptic “click” that used to be only on high-end devices, Android 16 makes it broadly available.
code snippet:
Vibrator vibrator = (Vibrator) getSystemService(Context.VIBRATOR_SERVICE);
VibrationEffect effect = VibrationEffect.createPredefined(
VibrationEffect.EFFECT_HEAVY_CLICK
);
// For custom waveforms in Android 16+
VibrationEffect custom = VibrationEffect.createWaveform(
new long[]{0, 100, 50, 200},
new int[]{0, 100, 50, 150},
-1
);
vibrator.vibrate(custom);
On devices that don’t support advanced haptics, the API will degrade gracefully. So even if you design a fancy pattern, a budget phone’s basic motor might just do a simplified version. It’s still supported, just not as intricate. The key thing is, test your haptic effects on a range of phones if possible. And remember, users can always turn off haptic feedback OS-wide, so it should be an enhancement, not the sole channel of important info.
8. Adaptive Refresh Rate API Enhancements
Android 16 brings improvements to how apps can leverage Adaptive Refresh Rate (ARR) displays. ARR was introduced in Android 15 (notably with the Pixel 9 series) to let screens dynamically adjust their refresh rate to match content – saving power and reducing stutter by avoiding unnecessary frame rate switches. In Android 16 DP2, Google added new APIs to make it easier for developers to tap into these variable refresh rates.
The key additions are: Display.hasArrSupport()Display.getSuggestedFrameRate()Display.getSupportedRefreshRates()
Compared to Android 15, where ARR was mostly automatic (and developers had to rely on setting a preferred frame rate per window and hoping the system did the rest), Android 16 gives more insight and control. A concrete improvement: Android 15’s ARR sometimes didn’t work well if apps forced certain configurations, partially due to lack of awareness of device support. Now, with a simple if (display.hasArrSupport()) { ... }getSuggestedFrameRate()
Google has also been updating Jetpack libraries to support ARR out of the box. In fact, RecyclerView 1.4 will automatically handle fling animations to take advantage of ARR. This means smoother scrolling that adapts refresh rate for you – a big win for app performance with zero extra work if you use the latest libraries. For custom rendering (games, custom UI frameworks), these new APIs in Android 16 are the tools you’ve been waiting for to fully exploit those 120Hz or higher screens.
Real-world impact: Say you’re developing a mobile game. On Android 15, you could set it to prefer 90fps, but if the device only supported 60Hz or 120Hz, you didn’t have a straightforward way to know that. With Android 16, your game could query getSupportedRefreshRates()[60.0, 120.0]. Then you know to either cap at 60 FPS or go for 120 FPS on that device. If hasArrSupport()getSuggestedFrameRate()
code snippet:
Display display = windowManager.getDefaultDisplay();
if (display.hasArrSupport()) {
float[] rates = display.getSupportedRefreshRates();
Log.d("ARR", "Supported: " + Arrays.toString(rates));
// Optionally set window frame rate:
WindowManager.LayoutParams params = getWindow().getAttributes();
params.preferredRefreshRate = rates[rates.length - 1]; // highest rate
getWindow().setAttributes(params);
}
Apps that adapt will offer slicker visuals and better battery efficiency on high-refresh devices.
FAQ: Android 16 Developer Preview Hidden Features
Q: When will Android 16 be officially released?
Google is planning to launch the Android 16 stable release in Q2 2025 (a bit earlier than past versions, which were Q3). The Developer Previews and Betas run from late 2024 through early 2025. By March 2025, Android 16 reached Platform Stability (final APIs) according to Google’s timeline. So, expect the official release (likely named Android 16 “Baklava”) to roll out to Pixel devices by around May or June 2025, with other manufacturers following later in the year.
Q: How can I try Android 16’s Developer Preview features now?
If you have a compatible Pixel device (Pixel 6 or newer), you can flash the Android 16 Developer Preview or enroll in the Android Beta program once it’s available. For DP1/DP2, you need to manually download and flash the system image. Keep in mind these early previews are intended for developers – they can be unstable for daily use. Alternatively, you can install Android 16 in the Android Emulator via the latest preview SDK in Android Studio. That’s a safe way to test the new APIs (like the photo picker or haptics) without risking your main phone. Always back up your data before flashing a developer preview on a device, and note that you may need to wipe your device to move from Android 15 Beta programs to 16 DP builds.
There’s no absolute guarantee – Google has been known to pull or postpone features during the preview period (for example, Notification Cooldown first appeared in Android 15 DP1 but was removed before release, then resurfaced in 16). However, all eight features we’ve highlighted are present in Android 16’s previews and many were even functional in DP1. The fact they’ve persisted (and even improved) in later previews is a good sign they’ll stick around. Features like the embedded photo picker, health records API, and adaptive refresh rate APIs are officially announced, so those are very likely to ship in the final release. More experimental ones (e.g. the exact implementation of Modes or certain AI-related APIs) could change based on tester feedback. It’s always wise to read the final Android 16 release notes – but so far, these hidden gems look poised to reach Android devices in 2025.
Some of these features are active by default (e.g. Notification Cooldown and OTP redaction just work in the background). Others are available under settings if you know where to look: for instance, Audio Sharing is found under Connected Devices > Bluetooth > Audio Sharing when using compatible hardware, and Modes will replace the Do Not Disturb menu under Sound & vibration settings. For developers, new APIs like the WritingTools or haptics require coding against the Android 16 SDK – you won’t “see” anything on the device UI, but you’ll notice their effects when running an app that uses them. If you’re using the Android 16 emulator or flashed a DP build, try exploring Developer Options as well – Google often places flags for in-progress features there. For example, there might be a toggle to force enable adaptive refresh rate changes or a verbose logging option for haptic feedback to help developers test their integrations.
Q: Where can I learn more about implementing these features?
Check out the official Android 16 Developer Documentation and API reference on developer.android.com – it’s continually updated as new previews land. For instance, the Android 16 features and changes list highlights the new haptic APIs and provides guidance on usage. The Android Developers Blog is also a great resource; Google has posted preview highlights (we’ve linked a few in this article) that explain the motivations behind these changes. And of course, keep an eye on communities like r/androiddev and Android developer forums for real-world insights. If you’re specifically interested in improving your Android development workflow (beyond just Android 16 features), you might enjoy our Android Studio plugin guides for boosting productivity in Android Studio.
With these hidden features in Android 16 Developer Preview, Google is refining the developer and user experience in subtle but significant ways. Early adopters can play with these now to get a feel for the future of Android. From seamless media sharing to smarter privacy and sharper tools for devs, Android 16 is shaping up to be an exciting release. As you explore these features, consider how you can incorporate them into your apps or daily usage to stay ahead of the curve. Android 16 isn’t just about the flashy changes – it’s the under-the-hood improvements like these that will delight users in everyday interactions.
