Pixel's ties to Google is its biggest strength-but also a weakness
Google launched its first Pixel phones way back in 2016, and we’re coming up on the launch of the company’s eighth generation of devices, the Pixel 8 series, later this year. Although overall sales of the Pixel lineup are a fraction of what Samsung manages in a single year, I’m not really worried that Google will kill off its Pixel smartphone business, a practice they have a tendency to do .
That’s because Pixel phones serve as a reference platform for Android, which is one of Google’s core businesses because of how much money it generates through the Play ecosystem. Thanks to its ties to Google, Pixel enjoys a level of security and first-class support that other Android hardware vendors dream of, but these ties also restrain what Pixel can do.
Since Google is both the maker of Pixel and Android, the two teams work hand in hand to ensure that every new feature that Pixel introduces doesn’t break compatibility with other parts of the OS or with apps. Google’s stance when it comes to Pixel software is the right one to take because they have an obligation to both developers and OEMs, but the outcome may not always be to the liking of end users.
No “dirty hacks” allowed
When Google’s new Pixel Tablet and Pixel Fold ended up in the hands of consumers last month, many were surprised to learn that a lot of the best Android apps weren’t optimized for their large screens. Instead of displaying apps in full screen, the Pixel Tablet and Pixel Fold use letterboxing to place apps in a window surrounded by black bars on both sides. Google’s decision drew criticism online, with some users on Reddit even thinking of returning their new Fold because of its software.
The Twitter app running on the Pixel Tablet. Android places the app in a letterbox to preserve its aspect ratio. (Image credit: Kartheek Alladi)
These users brought up how other devices are able to display their favorite apps in full screen, or at least offer them the option to do so, in contrast to Google’s devices. For example, the Twitter app on Samsung tablets takes up the entire screen.
The Twitter app running on the Samsung Galaxy Tab S8 Ultra. Because media content, ads, and the explore header are designed to take up available horizontal space while maintaining their aspect ratios, the Twitter app when stretched can look quite distorted, to the point where not even a single tweet can be displayed in its entirety. (Image credit: Mishaal Rahman)
Google’s decision to letterbox apps, in my view, is the correct one: It compromises between the desire of developers to not have their apps’ aspect ratios distorted and the desire of users to use their apps in their preferred orientation. If Google had done nothing, then many apps would simply be locked to portrait orientation like on the OnePlus Pad or OPPO Find N2 .
That would obviously provide a terrible experience for users, as they’d have to flip their devices over to even use certain apps (imagine using the 16:10 Pixel Tablet in portrait mode!) Instead, Google created a platform-level configuration that lets the OEM decide whether or not to respect an app’s orientation preference. The Pixel Tablet and Pixel Fold both use this configuration to force normally portrait-locked apps into landscape mode, but without stretching them by placing them in a letterbox.
But stretching the app is exactly what some users want. Sure, it’s technically Twitter’s fault that it isn’t optimized for large-screen Android devices, but if one tablet provides the “better” Twitter experience, you can see why some people are criticizing Google here.
Ideally, developers would see that their apps don’t look quite right on large-screen Android devices and then get to work on optimizing them, but it’s not always so simple. Depending on the app, it could take a lot of time and resources to optimize things. Not every company is willing to allocate developers to the task or even see the need to, considering how few users (relatively) access their apps from these types of devices.
OneUI’s “Landscape view for portrait apps” feature under Settings > Advanced features > Labs. (Image credit: Mishaal Rahman)
OEMs, recognizing that they can’t possibly get every developer to optimize their apps for their devices, instead deploy their own software features or “hacks” to compensate. Samsung, for example, offers a feature in OneUI called “landscape view for portrait apps” that lets users “force apps that normally only support portrait view to display in landscape view when [their] tablet is being held horizontally.” Crucially, this feature also lets users “choose to keep the app’s original aspect ratio or stretch it to fill the whole screen.” So while apps like FedEx, Venmo, Authy, Nothing X, Amplifi, AMEX, and more are shown in a letterbox on the Pixel Tablet, they can be forced to fill up the screen in landscape mode on a Galaxy tablet.
Let's not just shame Twitter FedEx, Venmo, Authy, Nothing X, Amplifi, AMEX, and more. Optimize your apps https://t.co/DsgmGlc9MC pic.twitter.com/M5n2l56LzQJune 22, 2023 See more
Google, however, can’t get away with this. When they tell developers that their apps will behave a certain way , they have to abide by that on their own devices. All Google can really do is encourage, but not force, developers to optimize their apps for large screens. Google has to maintain a delicate balance between pleasing users, developers, and OEMs, unlike OEMs who really only have to please their users.
I’m obviously oversimplifying things here, as it’s not like OEMs can get away with anything. Android compatibility requirements and testing still restrain what OEMs can change to a certain extent. Though as many developers will tell you, the compatibility requirements often don’t go far enough, as OEMs have been breaking how background services work for years now. OEMs mess with background services to yield better battery life, which is yet another thing that Google can’t get away with, resulting in “worse” battery life on Pixels when excluding other factors .
Google’s also not completely against “dirty hacks” — they just don’t implement any that would mess with developers’ expectations for how the OS will behave. For example, with the Pixel Tablet, Google set its “natural orientation” to portrait so that camera apps don’t break when letterboxed. They also implemented a compatibility fix that disables auto rotation only for full-screen, portrait-locked apps like games.
As you can see, when Google wants to make some changes to Android, they have a lot to consider. Sometimes, that results in highly requested features taking years to release because they have to be implemented “the right way.”
Making changes “the right way”
Google is often mocked for “copying” features from OEMs like Samsung, but there’s a good reason why they’re often “late” to adopt certain features. They first need to ensure there’s actually enough interest in the feature for it to be worth it to work on it, otherwise, they may end up implementing a feature that few people use but that they still have to maintain for several releases. They also need to ensure there are no regressions or conflicts with other parts of the OS or with apps, as well as address any limitations in existing implementations, because their version of the feature may not only show up on their own Pixel phones but also in AOSP for any OEM to adapt.
For example, Google finally added scrolling screenshot support in Android 12, years after other OEMs implemented such a feature. The way that many OEMs implemented scrolling screenshots was to simulate a scroll, take multiple screenshots, and then stitch them all together once the end of the page has been reached. Google refused to take this approach because there are many apps it doesn’t work with. Android 12’s scrolling screenshot implementation works with all apps that use a standard View -based UI, and for the apps it doesn’t work with, there’s an API that they can use to make it work.
Android scrolling screenshot feature (Image credit: Android Central)
That’s usually how these things go. OEMs develop a feature that gains popularity but that has several limitations, Google sees the feature and decides to iron out any kinks, and then Google releases the feature as well as an accompanying API and documentation when necessary.
Again, though, whether a feature is implemented the “correct” way is of little consequence to some users, those who only care that the feature is available in some form. And to some extent, I agree with them: It certainly would’ve been convenient to have a scrolling screenshot feature that worked well enough rather than not having one at all until Android 12. But Google can’t get away with providing a half-baked feature, which is partly why they’ve taken so long to adopt other features like one-handed mode , bubbles , app cloning , and desktop mode into stock Android.
Always ahead of the pack
While other device makers have more flexibility when it comes to creating new features, they don’t have the privileged position that Pixel has when it comes to getting new features into Android. Google is already hard at work developing Android 15 “Vanilla Ice Cream” , but OEMs won’t really get the full breakdown on what’s new in the OS until they’re briefed on it ostensibly later this year. Yes, OEMs do get early access to the source code for each new Android version, but that doesn’t happen until Google’s already basically planned out what features and APIs they want to implement in the next release. And a lot of those changes are typically made with a future Pixel device in mind. Most, of course, are not, but many of them are.
Take, for example, a lot of the changes Google made in Android 13 with Pixel devices in mind. They added a hub mode and USB audio dock support for the Pixel Tablet, a “media tap to transfer” feature to power new cross-device experiences between Pixel phones and the Pixel Tablet, and an “Ambient Context” API to power the privacy-preserving backend for the Pixel’s cough and snore detection feature, just to name a few. When Google has a new Pixel feature in mind that requires changes to the Android platform, they don’t have to necessarily fight to get it approved —they just need to ensure that it’s done “the right way”.
A Pixel Tablet that’s about to be docked. Though the tablet attaches to the dock via pogo pins on the back, Android treats the dock as a USB audio dock. Android’s USB HAL added support for audio docks in Android 13. (Image credit: Google)
Again, I’m oversimplifying here: There are many people within Android that help oversee new feature implementations to ensure they don’t introduce potential security issues or break any APIs, so it’s not like any feature request from Pixel is immediately implemented without internal scrutiny. But the fact that Pixel and Android are both under the same umbrella makes it easier for them to align on what changes should be implemented in future versions of the OS. OEMs do get a lot of say in the future direction of the platform, though, especially when it comes to decisions that directly impact them. And it’s not like OEMs have to wait for Google to adopt necessary changes into AOSP before they can start to work on a new feature.
Source: Android Central
