Android 17 Beta 1 is the first major Android release to skip the developer preview phase entirely, landing directly as a public beta on February 13th. A new pipeline, a compressed schedule, a release model that’s never been tested at this scale before: the conditions were right for a rough build. After several days on a Pixel 10 Pro XL, the more striking thing is how solid it actually is.
The Release Model Has Changed
Before getting into features, it’s worth understanding what’s different about how Android 17 is shipping. Google replaced the traditional Developer Preview program with a continuous Canary channel that runs on top of Android 16, pushing new APIs and framework changes as they clear internal testing rather than bundling them into quarterly preview drops. Android 17 itself never went through that preview stage at all.
The logic makes sense. By the time a feature reaches beta, it’s already been exposed to developers in Canary for weeks or months. Fewer surprises, smoother feedback cycles, and betas that are actually stable enough to run daily. Based on what we’ve seen so far, it’s working. Beta 1 has none of the typical first-build roughness. It feels less like a preview and more like a release candidate that happens to be missing a few things.
The Thing Google Is Finally Forcing Developers to Do
Android 17’s internal codename is “CinnamonBun” and its API level is 37. The most important change in this release has nothing to do with end users directly. It’s about making developers fix something they’ve been ignoring for years.
Apps targeting API 37 can no longer opt out of screen resizing or orientation changes on devices wider than 600dp. That covers tablets, foldables, and any large-screen device running the OS. Attributes like screenOrientation, resizeableActivity, minAspectRatio, and maxAspectRatio are now simply ignored on those form factors. The only exception is games that declare android:appCategory. Everyone else has to handle landscape, portrait, and arbitrary aspect ratios, whether they want to or not.
This has been a long time coming. Google spent years trying to make large screen support attractive, adding guidance, tooling, and design resources to nudge developers toward building proper tablet layouts. Some listened. Most didn’t. The result was Android’s most embarrassing persistent problem: phone apps stretched across 11-inch displays in a letterbox, edges capped with gray bars, as if the OS itself were apologizing for the experience. Google’s approach of carrots and gentle encouragement clearly wasn’t working. The stick was the only thing left.
For developers who relied on activity restarts to reload resources, there’s a new escape hatch. The android:recreateOnConfigChanges attribute gives explicit opt-in for full lifecycle restarts on specific configuration changes, including keyboard state, navigation type, and new color mode constants. It’s a reasonable accommodation. The core requirement isn’t going anywhere.
Android 17 Beta 1 Review: Camera
Camera apps on Android have long had a frustrating limitation: switching between modes meant tearing down the entire capture session. Photo to video, photo to night mode, any transition that required changing output configurations forced the hardware to close and reopen. The brief freezes and shutter delays that resulted were annoying in Google’s own camera app and far worse in third-party ones.
Android 17 fixes this with a new updateOutputConfigurations() method in CameraCaptureSession. Apps can now reconfigure active sessions without destroying and rebuilding them. Switching modes on the Pixel 10 Pro XL is smooth in the stock camera. Third-party apps haven’t adopted the API yet, so the real test comes later in the cycle, but the infrastructure is now there.
Multi-camera devices also gain a new metadata key, LOGICAL_MULTI_CAMERA_ADDITIONAL_RESULTS, which provides data from all active physical sensors during capture rather than just the primary lens. Computational photography apps can now pull real-time data from the ultra-wide or telephoto while the main sensor is shooting, which opens up multi-frame processing and live depth estimation in ways that weren’t cleanly possible before.
VVC Support and What It Means
Video compression hasn’t had a meaningful generational leap on Android in years. HEVC is now over a decade old, and the files it produces at high resolutions are large enough to be a genuine constraint for streaming apps and local storage alike. Android 17 adds platform support for H.266, better known as VVC, which targets roughly 50% better compression at equivalent quality. The new video/vvc MIME type in MediaFormat and updated profiles in MediaCodecInfo are in place. Hardware decode support is required, so availability will be uneven at launch and will expand as newer silicon becomes the baseline.
Background audio handling also changed in a way that’s overdue. Apps not in a valid lifecycle state will now have playback requests, focus requests, and volume changes fail silently. It closes a loophole that let poorly-written apps hold audio sessions they had no business keeping. Invisible to users when apps behave, and a genuine fix when they don’t.
Performance
Google is claiming up to 10% CPU load reduction, which is a bold number to put in a press release. The mechanism behind it is legitimate: ART’s Concurrent Mark-Compact garbage collector now supports generational collection, running frequent low-cost passes on short-lived objects instead of stopping everything for full heap scans. That’s a well-understood optimization that languages like Java and Kotlin benefit from significantly. The android.os.MessageQueue also gets a lock-free implementation designed to reduce the dropped frames that come from lock contention on busy threads.
On the memory side, custom notification views now have enforced size limits, closing a loophole that let apps use URIs to sidestep existing restrictions. Apps targeting API 37 also lose the ability to modify static final fields via reflection or JNI. That sounds obscure, but it matters because it lets the runtime make optimization assumptions it previously had to skip.
Geekbench 6 multi-core scores on the Pixel 10 Pro XL came in over 30% higher than the previous beta build. Single-core was consistent. In daily use that translates to app launches that feel immediate and zero dropped frames across everything we threw at it. Benchmark numbers don’t always reflect real use, but in this case they do.
The Small Stuff
The Pixel Launcher got a few changes people have been asking for. The home screen search bar is now customizable: the default AI Mode shortcut can be swapped for Gemini Live, Translate, Song Search, Weather, and a handful of others. The bar itself is slightly slimmer than it was on Android 16. At a Glance, the widget sitting above the date on the home screen, can finally be removed entirely. That’s been a standing request since at least Android 11. The volume panel gains a settings icon where three dots used to live.
Reports from other testers have the brightness slider behaving backwards on some devices, decreasing brightness when dragged right. That didn’t reproduce on the Pixel 10 Pro XL. Likely device-specific or already patched.
VoIP calls from apps like WhatsApp now appear in the system dialer alongside regular cellular calls, which is a change regular users will actually notice. Under the hood, the CompanionDeviceManager gets dedicated profiles for medical devices and fitness trackers, bundling Bluetooth, location, and nearby device permissions into a single association dialog instead of three separate prompts. Wi-Fi Ranging gains proximity detection for secure peer-to-peer discovery. None of these are headliners, but they’re the kind of polish that accumulates into a platform that feels considered rather than assembled.
Stability and Battery Life
The complaints common in beta threads: battery drain, device running warm, Bluetooth drops, 5G instability. Most of those didn’t materialize on the Pixel 10 Pro XL. Battery spiked after the initial install while the system reindexed and recompiled apps, then settled to slightly below Android 16 levels within 24 hours. Temperature was normal throughout. Bluetooth and 5G held up across the testing period, with 5G on Visible hitting near-gigabit downloads consistent with Android 16. The build ships with a newer baseband than Android 16, and there were no regressions.
App compatibility was solid across a wide range of apps, banking and productivity included. Nothing crashed. Google recommends giving the system 24 to 72 hours to stabilize after install. The 24-hour mark is the more accurate figure based on what we observed.
Should You Install It?
Developers should treat this as urgent. The mandatory large screen changes are going to break apps that have been coasting on the opt-outs, and Platform Stability is in March. Finding those breakages now, rather than six weeks from now, is the difference between a clean June release and a scramble. The build is stable enough to run as a daily driver alongside testing.
For enthusiasts comfortable with minor rough edges, this is one of the more stable early betas in recent memory. Battery settles within a day, app compatibility is good, and nothing critical is broken. If complete reliability is a requirement, Beta 2 is the safer target. For anyone who has run every beta since Android 11 and understands the tradeoffs, the build holds up well enough for daily use. Everyone else should wait for the stable release in June.
Android 17 Beta 1 is available for Pixel 6 through Pixel 10 devices. Enroll at the beta website.