DEV Community: Evan Koehler

Android 17 beta 1: what's new ?

Evan Koehler — Thu, 19 Feb 2026 12:40:42 +0000

February 19, 2026

As the Android 16 stable release happened in June 2025, which focused on new features like the desktop mode, new lockscreen settings and new AI themed icons for the home screen, it’s time for Google to finally open the Android 17 beta program. With the codename “Cinnamon bun”, this beta of Android 17 is accessible to every Google phone starting from the Pixel 6 to the Pixel 10, the Pixel Tablet and the Pixel Fold. As Google claimed, Android 16 was about “Intelligence and integration”, building the foundations for Android 17’s adaptability and polish. My name is Evan Koehler, and I tested the new Android 17 beta on my Google Pixel 9. Let me tell you what's new in this version.

Key new features

Required screen adaptability

The biggest change of this first beta is the required screen adaptability. Developers are now required to work on their app’s responsiveness, not only from one phone screen to another, but also from phones to tablets, and foldables too.

In previous Android versions, developers could opt-out from this adaptability for screens bigger than 600dp (tablets and foldables), which basically meant “This app was made for phones, and might not be displayed correctly on other devices”. This usually led to poorly rendered apps on foldable phones, or apps being displayed on one screen orientation only.

With this beta, all apps, except games, will need to be responsive, allowing the user to scale, resize and change the orientation of the app window. This completes Android 16’s desktop mode, as most apps were unusable on big 16:9 screens.

Dynamic camera sessions

Have you ever seen apps that use your phone camera have a small lag when switching from the photo to the video mode ? This comes from a platform limitation that the dynamic camera session aims to fix. In older versions, every time you switched from the photo to the video mode, or every time you switched from the standard lens to the ultra-wide one, the app had to perform some kind of hard-reset by killing the current camera session, clearing the RAM, and building a whole new session. This was resource-hungry and caused a half-second black screen while this hard reset was made.

The new developer-facing CameraCaptureSession API helps reduce lags when switching from photo to video mode. This will help developers make their app smoother when using the camera component.

UI Tweaks

Beta testers might have been disappointed to see there were not many new UI tweaks in this beta. Even if it was not the goal of this new version, Google still added a few changes here and there to keep fans engaged while waiting for the next build:

Pixel launcher search bar

Before the new Pill update of Android 16, the Google search bar on the bottom of the Pixel screen had no major redesign for a few versions (since Android 12 actually, which was released in 2021).

In Android 17, the search bar has ditched the thick Material You border for a thinner, glassy look, with more customization (color, transparency…) and now, the possibility to change the shortcut, offering lots of options like the song search, the weather, translation, and news for example, powered by Gemini.

Also, we noticed the appearance of a new search engine setting, empty at the moment, which might let the user change the engine of the widget to comply with the antitrust laws.

The At a glance widget

A long-awaited feature in the Pixel history: we can now remove the At a glance widget from the home screen, freeing up the top row for more available space.

Volume and brightness

Android 17 comes with a few very discreet UI changes that make the whole system more integrated. This first beta focuses on icons as some of them were not expressive enough.

The first one is the brightness icon, which was added on the right side of the slider. On some devices, the extra dim feature was also integrated into the slider.

The second one is the option icon in the volume slider. Instead of the previous three dots, we now have a clear “settings” icon that shows three sliders. This represents the feature better, as the option popup is literally composed of different sliders.

Installation and stability

As usual, to opt into the Android 17 beta, go to Android Beta website, and see if your devices are compatible. As of now, only Pixels are compatible (from 6 to 10, tablet and fold). Remember that beta programs are unstable builds and you might face issues that will make your device unusable until they get fixed. Even if most people who run beta software on their main device never face real issues, it might be a good idea to run unstable builds on a second non-primary device.

Conclusion

The Android 17 Beta 1, "Cinnamon Bun," is clearly focused on enhancing the foundational experience of the OS, prioritizing developer-facing improvements and system-wide consistency over flashy new consumer features. The forced screen adaptability and dynamic camera sessions are major platform shifts that promise a smoother, more unified experience across all form factors—especially foldables and tablets—building directly on the ambition of Android 16's desktop mode.

While UI changes were minimal, the subtle but significant tweaks to the Pixel Launcher search bar, the ability to remove the At a glance widget, and the clearer volume/brightness icons show Google is committed to polishing the core interface. This first beta sets a technical foundation for adaptability and performance, hinting that the larger user-facing changes may arrive in subsequent builds. And you, what features are you most hoping to see improved or added in the next Android 17 beta build, and why ?

Why I Prefer an Ultrawide Monitor Over Dual Standard Screens for Coding

Evan Koehler — Thu, 06 Mar 2025 17:14:41 +0000

Relying solely on a laptop screen for coding is uncommon among developers, as external monitors often enhance comfort and productivity. The decision then arises: should one opt for a single ultrawide monitor or dual standard 16:9 monitors? Let's explore this choice together.

Two competitors

Developers, when choosing their coding setup, usually hesitate between those two:

Setup 1: A single wide 21:9 screen

A single wide screen is a very large monitor that usually has crazy resolutions like 2560*1080, 3440*1440 or even 5120*2160. Functionning as a single continuous display, it allows for multiple windows to be viewed simultaneously or for individual windows to appear larger. This goes well with Windows 11's layout menu, as it allows you to reorganize windows more easily.

Layout menu in Windows 11

Setup 2: Two standard 16:9 monitors

Adding an extra 16:9 monitor to an already existing one allows developers to see twice as many windows at once than usual, which is priceless while coding. For example, if you are a web developer, it could be interesting to have your code on one screen, and your browser, on the other screen. It is better than pressing alt+tab for half an hour in order to find the right window.

The big winner is...

As you know, there is no "winner" as everyone has different needs, and some people will find two monitors better, while others will prefer one wide screen. I am still going to give you my opinion: I would much rather use a wide screen than two screens. Why ? Let me explain...

1- Better vision

Vision is something tricky, and a bad position can quickly cause headache, or eyestrain. Our eyes naturally focus most comfortably on central areas where both eyes converge seamlessly.

The vision system (from Wikipedia)

Here is the deal with two screens: you have only two ways of setting them, and both can cause health problems:

The two setups you can do with two monitors

On the left: your eye resting position is between the monitors, so you always have to look either on the left or the right side, which will force one eye to focus more than the other. Working like this during an extended period can cause eyestrain.
On the right, your main screen does focus both of your eyes and is positioned in the middle, but your other screen requires to turn your head, or force on your left eye even more than on the first case. This can cause eyestrain or even neck discomfort.

The only setup you need with a single wide monitor

As you can see, with a single wide monitor, you can reorganize your windows as you wish, so you can reduce eyestrain by putting them in the center, and you still have enough space to let other less important windows on the side.

2- The tiling window manager

As I am using a tiling window manager, my windows automatically divide and reorganize in order them to all appear on the screen at the same time, so what's better than a bigger monitor that can fit even more windows ?

But I can do exactly the same thing on two monitors, right ? Well yes, but what if I temporarily need my code editor to take the whole screen, to display more code at once ? I can resize my window for it to take 2/3 of my screen for example. Or I can even make it full screen while I need it.

A tiling window manager, even if you spend some time configuring it, will improve your efficiency, especially as a developer. I must agree that a wide screen with a floating window manager is not as powerful, and to be honest, it would bother me to reorganize the windows by myself every time I open a new one. That is why I think tiling window managers and wide screens get along so well.

Conclusion

Even if this fight has no clear winner, I have my preferences and they go for the wide screen, which allows me to reorganize my windows as I need them to be, while using a tiling window manager, and reduces eyestrain. But remember that everyone has different needs, and it is only a matter of point of view: choose the setup that suits your needs best ! And you, which setup would you choose ? Tell us in the comments !

Sources

What is a tiling window manager and how can it change your life as a developer ?

Evan Koehler — Thu, 27 Feb 2025 16:38:55 +0000

If you're a developer, you've probably heard of i3, Sway, or Hyprland. But what exactly are these tools, and why do so many Linux users swear by them? Have you heard of window managers but have no idea what they are ? Don't worry! In this article we'll explain everything you need to know about it !

What is a window manager

In Windows and MacOS for exemple, window managers are part of the OS: they cannot be changed. In Unix and Linux based OSes, the graphical interface and the OS are separate, which lets the user the possibility to choose each aspect of it. For example, when you install Ubuntu, you get GNOME as the default desktop environment. Note that you can use Ubuntu with another graphical interface (KDE, LXDE...) than GNOME, and it's perfectly fine !

A desktop environment (like KDE, GNOME, Budgie...) is mainly composed of three things:

A window manager, which we are going to talk about today
A desktop shell,
And additional tools to make the whole thing consistent (store, calculator, text editor...)

So what is a window manager ?

Well, window managers have a self-explanatory name, as their primary role is to manage windows. The window manager is the software that decides where a window appears (position X,Y), its size (X,Y), and its decoration (close, maximize, minimize button, title...) for example. It also manages virtual desktops: their number, their position (square, list...), etc...

Why tiling ?

Window managers first appeared as we know them on Windows and MacOS for example: we call this a floating window manager (fwm), because windows float on the screen, we can move them and put them anywhere we want.

Here is a screenshot of the desktop environment KDE (with the KWin FWM)

But there is another type of window manager, which is called tiling window manager (twm) and acts like a binary tree to organize windows. This means the screen is always split to display all windows simultaneously - no more overlapping!

Here is a screenshot of the TWM Hyprland

A binary-tree representation of the previous screenshot

With a tiling window manager, windows do not float. Instead, they have fixed positions and sizes that adjust whenever a new window appears on the screen. That's why it is very useful to use virtual desktops as it becomes very easy to access all the information on the screen without pressing alt+tab for half an hour.

Most TWM have shortcuts to make a window floating temporarily. We are talking about the default behavior here.

How does it improve my workflow as a developer ?

Tiling window managers are a game changer for developers. It can increase your productivity and make you more efficient. Here are the three main features that will help you:

Faster than light thanks to keyboard shortcuts

Even if floating window managers do have keyboard shortcuts, they are not as important as they are in tiling window managers. The main goal here is to completely forget about the mouse/touchpad: everything can be done using only the keyboard. This way, you will be faster to move a window, resize it, open it or close it for example.

Make this computer yours with customization

Most tiling windows manager can be run without any supporting desktop environment, meaning that they are very minimal by default. But this also mean you can customize them as you want it to be.

A default i3 configuration

As we talked about keyboard shortcuts earlier, know that very few TWM users keep the default keybindings: you can customize them as well in order to make it even faster !

A modified i3 TWM (you can find it here)

If you want to see more Unix and Linux setups like this, I recommend you r/unixporn on Reddit, where you will find a lot of screenshots made by the community !

Lighter than desktop environments

As we said earlier, windows managers are part of desktop environments, but most TWMs can run on their own, which makes your system much lighter, as you have no desktop shell, no additional tools, etc... This means you will have to replace them if you need them, but this lets you choose, and that's the beauty of TWMs: everything can be a user choice.

What TWM should I choose ?

The choice is hard, as a lot of TWMs exist, and everyone of them has their pros and cons. This will be your job to test them and find out which one fits your needs best. Here are some things that might differ from one TWM to another:

Default window placement (horizontal/vertical split, golden number...),
Configuration language (lua, lisp, shell, homemade language...)
Display server compatibility (X, wayland...)

Now that you are convinced you want to try a tiling window manager (well, I hope so), let me give you a few of the most popular TWM for Linux (most if not all of them are also unix-compatible):

Conclusion

Tiling window managers can revolutionize your workflow as a developer. They help you stay organized, eliminate clutter, and make your system truly yours. Are you ready to ditch floating windows and give tiling a shot?

Sources

React Native v.0.78.0 rolls out. Here are three new features you will love

Evan Koehler — Sun, 23 Feb 2025 22:00:51 +0000

Are you a React Native developer ? This framework, initially released by Facebook in 2015, just got upgraded to its last version, and those three new features will change the way you code !

The Chrome Devtools Protocol is upgraded

The Chrome Devtools Protocol (CDP) is an API that lets applications communicate with an open Chrome instance. React Native uses it in order to debug apps in Chrome browsers, and one of its domain, the FuseboxClient, which was used to identify and register metadata about the debugging client to the Chrome DevTools backend for example, was replaced by a more modern implementation: ReactNativeApplication.

This helps removing legacy code, and better aligns with Chrome DevTools standards.

For most React Native developers, this won't change anything. But if you are using - or even creating - a custom debugging integration for React Native, you may see significant changes and would need to update your implementation for it to work.

Change the Image load event size from logical to physical

Images, like every other component in React Native, have a lot of props, and some of them were made to manage events. It's the case of onLoad which is triggered when the image is loaded successfully. It takes a callback with a parameter (of type ImageLoadEvent) that provides information about the source image.

The react native community realized that this ImageLoadEvent.source, the object containing the source image, returned two values (width and height) that were calculated as a logical size (points) rather than in pixels, which is easier to calculate.

<Image
  // Source and style
  onLoad={(e: ImageLoadEvent) => console.log("size: ", e.nativeEvent.width)}
/>

// Before: output size in points
>> size: 100

// Now: output size in pixels
>> size: 250

This means now it is going to be easier to manage and calculate sizes for images, may it be for transitions or responsiveness.

Adds support for the second parameter of `console.table()`

Most javascript and typescript developers know about the famous console.log(). They use it to debug their code by printing variables or text in the console. A few of them know about its little brother console.table(), which aims to display an easy-to-read array.

Even fewer developers know that console.table() actually supports two parameters:

the first one is obviously the array to print
the second one is the list of columns to display

The problem was that, until React Native v0.78.0, this second parameter used to throw an FlowExpectedError[extra-arg]. Now you can do it ! Isn't that wonderful ?

Conclusion

Once again, the community worked hard to give us exciting new features for React Native v0.78.0. May it be for the devtools, the Image component, or even the console library, they have upgraded every part of this wonderful project. What do you think about those features ? Are they exciting or useless ? Do you often use console.table ? Tell us in the comments !

Google releases the second beta of Android 16: New camera features, Wallet shortcuts, and more !

Evan Koehler — Sat, 22 Feb 2025 12:23:48 +0000

On February the 13th of 2025, Google finally dropped the second beta of Android 16, bringing camera enhancements, a new shortcut for Google Wallet, and crucial bug fixes. While developers get the most out of this update, here is what users need to know.

What’s new for users ?

Since this beta is not focused on introducing significant user-facing features, you may not notice many changes. Codenamed Baklava, this version primarily enhances the API, providing developers with new tools to improve Android applications.

However, if you're not a developer, here are the main changes you might notice:

New camera features

Google has made several improvements to the camera app. Since the first beta of Android 16, the company has promised to enhance picture quality with UltraHDR images. In Android 16 Beta 2, they have confirmed this by adding support for UltraHDR in HEIC images.

For developers, this means these images will have an ImageFormat set to HEIC_ULTRAHDR.

According to the Android development team:
"We're working on AVIF support for UltraHDR as well, so stay tuned.".

This means richer colors and better contrast, while keeping an efficient compression, in order not to get too heavy pictures.

Google Wallet just got easier to access

For several Android versions, users have been able to open the camera by double pressing the power button. However, there has never been any option to assign this shortcut to another app - until now.

With Android 16 Beta 2, Google has introduced an option to open Google Wallet using the same double-press shortcut. Unlike the camera shortcut, opening the Wallet app does not trigger haptic feedback, making the feature feel slightly unfinished. Nonetheless, it's great to see Google adding more customization options to Android.

Bug fixes

Betas are also the perfect moment to get feedback from users, in order to know what bugs this new version brought. And indeed, the Android 16 beta 1 added a few bugs here and there, and some of them were fixed in the beta 2:

Some interactions in Webviews used to make the System UI crash. This issue is now resolved (issue #392011635).
Some devices used to freeze and reboot during phone calls: this has been fixed as well (issue #392364716).
Since Android 16, the Google Home app had random crashes that have been fixed too.

Conclusion

Although the Android 16 beta 2 did bring more features to developers than it did to users, we can still notice a few changes here and there, like camera enhancements, bringing UltraHDR support for HEIC images, but also a new shortcut to open Google Wallet, along with a few bug fixes.

Android 16 is supposed to reach its final stage shortly after May 2025 (you can see the timeline here. If you want to try it before this date, you can try Android 16 here. For those who already tried it, what do you think about Android 16 so far ? Is this update exciting for you ? Would you trade your camera shortcut for Google Wallet access ? Let us know in the comments !

DEV Community: Evan Koehler

Android 17 beta 1: what's new ?

Why I Prefer an Ultrawide Monitor Over Dual Standard Screens for Coding

Two competitors

Setup 1: A single wide 21:9 screen

Setup 2: Two standard 16:9 monitors

The big winner is...

1- Better vision

2- The tiling window manager

Conclusion

Sources

What is a tiling window manager and how can it change your life as a developer ?

What is a window manager

So what is a window manager ?

Why tiling ?

How does it improve my workflow as a developer ?

Faster than light thanks to keyboard shortcuts

Make this computer yours with customization

Lighter than desktop environments

What TWM should I choose ?

Conclusion

Sources

React Native v.0.78.0 rolls out. Here are three new features you will love

The Chrome Devtools Protocol is upgraded

Change the Image load event size from logical to physical

Adds support for the second parameter of console.table()

Conclusion

Google releases the second beta of Android 16: New camera features, Wallet shortcuts, and more !

What’s new for users ?

New camera features

Google Wallet just got easier to access

Bug fixes

Conclusion

Sources

Adds support for the second parameter of `console.table()`