Android 17 enters beta with new privacy, media, and dev tools
Updated on February 20, 2026 7 minutes read
Google shipped Android 17 Beta 1 on 13 February 2026, expanding testing beyond early previews and into the Android Beta Program for Pixel devices. The release centers on three themes: mandatory large-screen adaptivity for apps targeting API level 37, tighter secure-by-default behavior changes, and new camera and media capabilities.
Beta 1 also marks a process change, with Google replacing the traditional Developer Preview track with an always-on Android Canary channel. For teams, the practical message is to start compatibility testing now, especially for tablets and foldables, networking defaults, and media pipelines.
What happened
Google announced the first beta of Android 17 on 13 February 2026 via the Android Developers Blog, describing it as a more stable environment for development, testing, and feedback.
The same post introduced a shift in how early Android builds are distributed: the long-running Developer Preview model is replaced by a continuous Android Canary channel intended to surface features earlier and reduce churn during Beta.
In the official Android 17 release notes, Beta 1 is listed with a release date of 13 February 2026 and a build number of CP21.260116.011.B1. The notes also list CP21.260116.011.A1 for Pixel 6 Pro, Pixel 6, Pixel 6a, Pixel 7 Pro, and Pixel 7. Emulator support is provided for x86 (64-bit) and ARM (v8-A). The release notes specify a security patch level of 2026-01-05 and Google Play services version 25.47.33.
Android 17 Beta builds are available for a defined set of Google devices. The official “Get Android 17” page lists supported hardware including Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, Pixel 9a, Pixel 10, Pixel 10 Pro, Pixel 10 Pro XL, and Pixel 10 Pro Fold.
For developers who prefer a simulator-first workflow, Google documents Beta setup in Android Studio and specifies Android Studio Meerkat (2024.3.1) for creating virtual devices.
The Android 17 emulator system image is named “Baklava,” and Google highlights a resizable emulator configuration that can switch between phone, foldable, and tablet reference devices.
Finally, Google provided a timeline: Platform Stability is targeted for March 2026, and Google intends a year of quarterly updates. Google also states that the upcoming release in Q2 is the only one planned to introduce app-breaking behavior changes, with a minor SDK release planned for Q4 that adds APIs and features.
Why it matters
Mandatory large-screen adaptivity is not a niche requirement anymore. In Android 17, apps targeting API level 37 running on large screens (sw greater than or equal to 600dp) can no longer opt out of resizing or orientation changes.
Android will ignore attributes such as screenOrientation, resizeableActivity, minAspectRatio, and maxAspectRatio on large screens, with exemptions for devices below 600dp and apps categorized as games. If your UI relies on locked orientation or fixed sizing, Beta 1 is where those assumptions will surface.
Security changes in Android 17 are also likely to impact real apps, not just edge cases. Google introduces a new install-time permission, USE_LOOPBACK_INTERFACE, to restrict cross-app and cross-profile communication over localhost (127.0.0.1 or ::1).
In practical terms, teams using localhost bridges for IPC, debug features, or plugin architectures may need to redesign or at least add explicit permissions on both sides. Google also enables certificate transparency by default for apps targeting Android 17, moving this from an opt-in behavior on Android 16. If you operate custom TLS stacks, pinned certs, or complex proxies, this is a compatibility checkpoint.
Another notable tightening is around dynamic code loading. Android 17 extends the “Safer Dynamic Code Loading” protection to native libraries for apps targeting Android 17 or higher.
Native files loaded via System.load() must be read-only, or the system throws UnsatisfiedLinkError. This is the kind of change that can break plugin systems or update mechanisms that write shared objects at runtime.
On the media side, Android 17 Beta 1 brings new capabilities that map directly to product features. Google added CameraCaptureSession.updateOutputConfigurations() so camera apps can attach or detach output surfaces without rebuilding the entire capture session.
The goal is smoother transitions between camera modes with fewer user-visible glitches. Android 17 also adds platform support for Versatile Video Coding (VVC, also known as H.266) and defines a video/vvc MIME type, plus profiles and extractor integration for devices with compatible hardware and drivers. Video creators get another lever with MediaRecorder.setVideoEncodingQuality(), which enables constant-quality encoding modes beyond basic bitrate choices.
For learners, this beta is a strong study package. It connects adaptive UI, permissions, performance profiling, and media APIs in one release cycle. That combination mirrors real mobile engineering work more closely than a single “headline feature” does.
Key numbers
- Android 17 Beta 1 release date: 13 February 2026
- Builds listed in release notes: CP21.260116.011.B1 and CP21.260116.011.A1
- Android 17 API level: 37
- Large-screen threshold for mandatory adaptivity: sw greater than or equal to 600dp
- Emulator architectures supported (Beta 1 notes): x86 (64-bit) and ARM (v8-A)
- Security patch level listed for Beta 1: 2026-01-05
- Google Play services version listed for Beta 1: 25.47.33
- Android Studio version referenced for emulator setup: Android Studio Meerkat (2024.3.1)
- Android 17 emulator system image name: Baklava
- Platform Stability target: March 2026
- Quarterly cadence note: app-breaking behavior changes planned in Q2; minor SDK release planned in Q4
Context
Google has been pushing Android toward better experiences on foldables, tablets, and windowed desktop-like environments for several releases. Android 16 introduced platform changes that ignore certain orientation, resizability, and aspect-ratio restrictions on large screens for apps targeting newer SDK levels, but it still allowed developers to opt out. Android 17 removes that opt-out for apps that choose to target API level 37, raising the baseline for “works everywhere” UI quality.
The Canary change matters because it reshapes how teams discover and respond to platform changes. Instead of waiting for a quarterly preview cadence, Canary is positioned as the place where features and APIs land after internal testing, while Beta aims to be closer to final behavior. For organizations with CI device labs, that separation can be useful: Canary for early signal, Beta for compatibility hardening.
Android 17’s security direction also follows a broader platform pattern: fewer “optional” protections and more secure defaults that only show up when you advance your target SDK.
That is a deliberate forcing function. Teams that treat targetSdkVersion updates as routine maintenance will be better positioned than teams that defer targeting until it becomes a release scramble.
What’s next
For most teams, the best next step is compatibility testing without changing targeting. Google’s Android 17 migration guidance recommends installing your existing app on Android 17, testing flows, fixing issues, and publishing an update while keeping the same targetSdkVersion. That approach lets you protect users upgrading their OS while you plan a more deliberate API 37 targeting effort.
A practical Android 17 Beta checklist:
Test on large screens early, not last. Use a Pixel Tablet, Pixel Fold, or the resizable emulator to validate resizing, posture changes, and multi-window behavior.
Identify localhost dependencies. If any part of your stack relies on cross-app loopback, plan for USE_LOOPBACK_INTERFACE and confirm both communicating apps declare it.
Review network security configuration. If you previously relied on android:usesCleartextTraffic, move to explicit Network Security Configuration rules and verify certificate transparency assumptions.
Audit native loading paths. If you load shared libraries dynamically, ensure the files are marked read-only before calling System.load().
Profile real performance regressions. Android 17 adds new ProfilingManager triggers (COLD_START, OOM, KILL_EXCESSIVE_CPU_USAGE) and a lock-free MessageQueue implementation; use these tools to pinpoint missed-frame or startup problems that show up only on new builds.
Validate media features with fallback. If you adopt VVC or constant-quality recording, implement capability checks and graceful degradation for devices lacking hardware support.
Google’s timeline indicates Platform Stability in March 2026, so teams that ship widely used apps should aim to have major compatibility risks surfaced before that milestone. That makes it easier to validate fixes against APIs and behaviors that are close to final.