In other news: A new version of Android TV and more apps for Android Automotive
Welcome back to Android Decoded, a newsletter devoted to explaining the significance of each week’s news on the Android ecosystem. This newsletter is written each week by Mishaal Rahman, a veteran tech reporter devoted to the Android beat.
Last week, Google held its annual I/O developer conference, which I had the opportunity to attend in person. The conference was, predictably, centered around the company’s latest advancements in AI, so much so that CEO Sundar Pichai even took the piss out of how often the term “AI” was said during the keynote. While Android didn’t get many explicit mentions in the day 1 keynote, the operating system had its moment during day 2 of the event, where Google unveiled big updates to Android for phones, watches, TVs, and cars.
There’s a lot to unpack, so I unfortunately can’t cover everything. Here are the stories I’ll be focusing on in this edition:
In the 8 days I was away from home for Google I/O, I only needed to charge my OnePlus Watch 2 a single time. The OnePlus Watch 2’s 3-4 day battery life has made it part of my everyday carry for the last few months. While it does have a big battery for a smartwatch, its software plays an important role in maximizing battery life. It’s the first to support the updated Wear OS hybrid interface which provides APIs for watch faces, health services, and notifications to be offloaded to a more efficient co-processor. The next version of Wear OS, Wear OS 5, includes changes designed to encourage the use of the Wear OS hybrid interface.
With the release of Wear OS 4, Google introduced the Watch Face Format (WFF), an XML format that uses declarative language to configure the behavior and appearance of watch faces. Because the WFF doesn't require executable code or code embedded in the watch face APK, the rendering of watch faces built on the WFF can be offloaded onto the co-processor via the Wear OS hybrid interface. Even though watch faces built on the WFF may have fewer features than watch faces built on legacy APIs, they have the potential to drain significantly less battery, which is why Google is pushing to require the WFF’s use.
Starting in early 2025, Google Play will require that all new watch faces be built on the WFF. Developers who have already built and shipped watch faces using legacy APIs can continue to support them, but developers building new watch faces will have to migrate. To facilitate this transition, the WFF in Wear OS 5 now supports more features, including “flavors” (preset configurations), new complication types (“goal progress” and “weighted elements”), and new data sources (“weather”, “forecast data”, and “heart rate”). Also, Wear OS 5 will apply restrictions to some data sources used by complications on watch faces built with legacy APIs.
Wear OS 5 has other power-saving optimizations, of course. Google says marathon runs on smartwatches running Wear OS 5 consume up to 20% less power, thanks to a reduction in how long it takes for the device’s main processor to go back to sleep after being woken up to write some health data.
Lastly, other improvements in Wear OS 5 include a grid-based app launcher, a privacy dashboard, Credential Manager support, new data types for running in Health Services, and more.
Android TV 14 prepares for a new smart home future
Image: Google
It’s rare to see major changes in Android TV platform updates, and Android 14 for TV is no exception. To comply with the EU’s standby energy consumption requirements, Android 14 for TV includes new, user-selectable energy modes. It also brings picture-and-picture mode support (but not for media apps) as well as new vision and navigation-related accessibility options. The biggest change, in my view, is better support for the Matter smart home standard and optionally a Thread network stack on upcoming TVs.
Matter, if you aren’t aware, is a smart home connectivity standard built with interoperability in mind. The goal is to unify the way that IoT devices from different brands communicate. Thread, on the other hand, is a low-power, IP-based wireless mesh networking protocol that’s designed for communicating with IoT devices. Thread is one of several communication protocols (alongside WiFi and Bluetooth) that Matter devices can communicate over.
Later this year, select TVs running Android 14 will be upgraded to become Google Home hubs. “With this update, all hubs for Google Home will be able to directly route commands from any app built with Home APIs (such as the Google Home app) to a customer’s Matter device locally, when the phone is on the same Wi-Fi network as the hub,” said Anish Kattukaran, head of product at Google Home and Nest, speaking to The Verge. The main benefit of this change is a reduction in latency; ideally, your commands to control devices will execute much more quickly.
In addition, select TV devices with Thread network support will be able to act as Thread border routers. Thread border routers assist other Thread-enabled devices in joining an existing home network. Essentially, your Android TV—which may likely already be the centerpiece of your living room—will be upgraded to become the centerpiece of your smart home.
Google tries to lure car makers in by expanding Android app access
Image: Google
Android for Cars will be getting a much-needed influx of apps in the near future, thanks to Google’s new “Car ready mobile apps” program. “Android for Cars”, if you aren’t aware, refers to both Android Auto (where your phone projects a car-optimized UI onto a car dashboard) and Android Automotive (where your car’s dashboard itself runs the Android operating system). When a car maker ships a build of Android Automotive OS (AAOS) with Google Automotive Services (GAS, Google’s suite of proprietary apps), this is called “Google built-in.” This terminology is confusing but important to understand, because Google’s announcements at I/O touch all three areas.
But first, what is the new “Car ready mobile apps” program and why is it important? There aren’t a lot of apps built for Android for Cars right now, which isn’t surprising since the market isn’t as large comparatively and it’s more difficult, costly, and risky to build and test apps for cars. Google places apps that work on Android for Cars into three tiers: Tier 1 (“Car differentiated”), Tier 2 (“Car optimized”), or Tier 3 (“Car ready”).
Tier 1 apps are built specifically for cars, can adapt across driving and parked modes, and ideally support all screens.
Tier 2 apps look great on cars, but typically are only optimized for the center stack display and don’t have any car-specific engineering.
Tier 3 apps are optimized for large screens and can only be used while the car is parked.
Tier 3 apps are basically just tablet apps, and while there aren’t a lot of them, there’s still a lot of them that aren’t available on Android for Cars. Google’s looking to change that with the “Car ready mobile apps program.” The company will proactively review large screen optimized mobile apps and automatically opt them in for distribution on Android for Cars, starting with Google built-in but later expanding to Android Auto. Google will start with reviewing apps that fall under categories like video, gaming, and browsers before expanding to other categories.
This program should greatly accelerate the rate of new apps launching on Android for Cars, since developers won’t have to make changes for their apps to be distributed. One of the biggest reasons for car makers to ship AAOS with GAS is to get access to Google Play. As I just said, though, there aren’t that many apps available for Android for Cars. But with the launch of this new program, that’s going to change. As the gap in app availability between AAOS with GAS and AAOS without GAS expands, we’ll likely see more and more automakers opt for bundling GAS.
Interestingly, Google also seems fine with letting automakers who don’t bundle GAS to still have access to their services. Rivian, who uses AAOS without GAS in its vehicles, partnered with Google to bring Google Cast and YouTube to the R1. Google usually doesn’t work with companies who fork AOSP but decline to bundle their apps in this way, but automotive is a bit of a special case. There are some (admittedly weak) rumors that Rivian and Apple are exploring a partnership, so this concession could be an effort to appease Rivian.
Google makes security and privacy its top priority for Android 15
Image: Mishaal Rahman
One of the things I love most about Android is how extensible it is. If I want to automate something, there’s a decent chance that I can put something together that utilizes Android’s powerful accessibility, overlay, notification listener, and other APIs to accomplish a task. Many innovative apps that make use of these powerful APIs have popped up over the years, such as the total volume panel replacement app that I recently covered for Android Authority, but sadly, a lot of malicious apps that abuse these APIs have as well. I feel like I hear about some new banking trojan every week that relies on tricking users into granting them access to these APIs. Google may have given app developers too much freedom with these APIs, which is why they’ve slowly been adding new restrictions or clawing back what they can do.
This post is for subscribers with the tier: Even More Android Faithful
Sign up now and upgrade your account to get access to the post.
