Android Archive
Your T95 is infected with malware pre-installed, ready to do whatever the C2 servers decide. Yes, malware from Amazon straight to your door! If they insist on selling these devices they really should add an “Includes Malware” category in the Android TV section. I find it absolutely baffling that Amazon is full of sketchy garbage like this, and nobody really seems to care. Amazon itself, lawmakers, consumers – everybody just takes it for granted?
Google’s keynote at the RISC-V Summit was all about bold proclamations, though. Lars Bergstrom, Android’s director of engineering, wants RISC-V to be seen as a “tier-1 platform” in Android, which would put it on par with Arm. That’s a big change from just six months ago. Bergstrom says getting optimized Android builds on RISC-V will take “a lot of work” and outlined a roadmap that will take “a few years” to come to fruition, but AOSP started to land official RISC-V patches back in September. Another vote of confidence for RISC-V.
Ars Technica: Guess what has happened! Lukasz Siewierski, a member of Google’s Android Security Team, has a post on the Android Partner Vulnerability Initiative (AVPI) issue tracker detailing leaked platform certificate keys that are actively being used to sign malware. The post is just a list of the keys, but running each one through APKMirror or Google’s VirusTotal site will put names to some of the compromised keys: Samsung, LG, and Mediatek are the heavy hitters on the list of leaked keys, along with some smaller OEMs like Revoview and Szroco, which makes Walmart’s Onn tablets. These companies somehow had their signing keys leaked to outsiders, and now you can’t trust that apps that claim to be from these companies are really from them. To make matters worse, the “platform certificate keys” that they lost have some serious permissions. I tend to not really focus on security issues, because more often than not they amount to baseless scaremongering for clicks (or worse, to scare people into buying antivirus software), but this one seems possibly serious enough to warrant attention. I’m just not entirely sure how bad this can actually turn out to be, and the vague statements from Samsung, Google, and other sure aren’t helping in cleaning up the confusion.
In Android 13, about 21% of all new native code (C/C++/Rust) is in Rust. There are approximately 1.5 million total lines of Rust code in AOSP across new functionality and components such as Keystore2, the new Ultra-wideband (UWB) stack, DNS-over-HTTP3, Android’s Virtualization framework (AVF), and various other components and their open source dependencies. These are low-level components that require a systems language which otherwise would have been implemented in C++. To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code. We don’t expect that number to stay zero forever, but given the volume of new Rust code across two Android releases, and the security-sensitive components where it’s being used, it’s a significant result. It demonstrates that Rust is fulfilling its intended purpose of preventing Android’s most common source of vulnerabilities. Historical vulnerability density is greater than 1/kLOC (1 vulnerability per thousand lines of code) in many of Android’s C/C++ components (e.g. media, Bluetooth, NFC, etc). Based on this historical vulnerability density, it’s likely that using Rust has already prevented hundreds of vulnerabilities from reaching production. These numbers don’t lie.
Change is many things: scary, exciting, inevitable. Android is changing all the time, and for a while now we’ve been anticipating a major shift in terms of software support, one that would see the platform abandon its oldest software — Android will go 64-bit-only, dropping compatibility for old 32-bit apps. The biggest question has been “when?” Would the Pixel Tablet demand 64-bit apps? Could we be sitting around until Android 14 to make the switch? Apparently Google just got tired of waiting, and quietly launched the Pixel 7 and Pixel 7 Pro without support for 32-bit apps. The inevitable march of progress. The move to 64bit killed quite a few old games on iOS, and I’m sure the same will happen to Android. However, if an application hasn’t been updated that long, it might be a good idea to search for an alternative, of which there will be many, since application stores are nothing if not filled to the brim with shameless ripoffs.
The Android update treadmill continues with the release of Android 13. It’s one of the smallest Android releases in recent memory, with barely any user-facing features to point to. Keep in mind, though, that this update follows the monster Android 12 release from last year. This is also the second Android OS release this year, the previous one being the tablet-focused Android 12L update that was rushed out the door in March. We would have a bit more meat to work with if Android 12L was part of this release, but as it is, we’re left with a grab bag of features for Android 13. It includes many foundational features for Android tablets and smart displays, but there’s not much here for phones. Even so, there are things to discuss, so let’s dive in. Ars Technica’s usual deep dive into every new Android release, and despite Android 13 being a relatively minor release, there’s still more than enough to cover.
With the rollout of Android 13 to the Pixel 6 and 6a, Google posted an interesting warning on the system image website: Once you flash Android 13, you can never go back to the old version. That’s still the case for anyone wanting a fully functional phone, but now, Google has posted an Android 12 “developer support image” that will let developers roll back their phones even after upgrading. The “developer” branding on the image means it’s not fully functional, but it will be good enough for app testing. Not being able to roll back would be terrible if Android 13 came with some sort of gamebreaking bug, so this is a welcome release.
Today we’re launching our Developer Preview of the new Cross device SDK for Android. First announced during the Google I/O ‘22 Multi-device development session, our Cross device SDK allows developers to build rich multi-device experiences with a simple and intuitive set of APIs. This SDK abstracts away the intricacies involved with working with device discovery, authentication, and connection protocols, allowing you to focus on what matters most—building delightful user experiences and connecting these experiences across a variety of form factors and platforms. Google intends to expand this tool to non-Android operating systems soon.
Today, Google is releasing Android 13 for Google Pixel smartphones, following months of developer previews and beta releases. It’s an update that polishes a lot of the changes that Android 12 brought to the table, while also introducing a ton of small, helpful features across the board that aims to improve privacy, security, and usability. Alongside the update, the company has also announced that Android 13’s source code is now available in AOSP. It’ll be a while before Android 13 lands in most of our hands.
The /e/ OS operating system provides a user-friendly alternative to Android for people who want the Android experience without the reliance on Google and associated manufacturer-related applications and telemetry. Compared to LineageOS, /e/ provides a more unified experience out of the box, with a suitable suite of default open source applications and a system-based application store. Despite the fact that /e/ borrowed from various pre-existing open source projects to create its default applications, none looks out of place. It’s a good choice for people looking to de-Google, but the rather lacklustre device support is a big problem, forcing you to buy a new device if you want to give this a go. That’s not really /e/’s fault, of course, but it’s an issue nonetheless.
With the addition of the developer-generated Data safety section this year, Google Play removed the old list of app permissions. The Play Store is now reversing this decision in response to user feedback and will have both coexist. This was a baffling decision to begin with – the Data safety section relied on developers being honest and truthful about their privacy practices and permissions usage, which was never going to work out with the amount of downright scams and sleaziness targeting children that are in the Play Store (and App Store).
Hello Nova Community, I’m Kevin Barry, the creator of Nova Launcher. I’ve made, make and will continue to make Nova Launcher. Today I’m announcing that Branch has acquired Nova Launcher, and hired myself and Cliff Wade (Nova Community Manager). Branch has also acquired Sesame Search and hired the Sesame Crew (Steve Blackwell and Phil Wall). I’ll continue to control the direction and development of Nova Launcher, and that direction is unchanged. Nova focuses on power users and customization. I will be adding some features powered by Branch, they’ll be optional like most features in Nova. This is a tough pill to swallow. I’ve been a dedicated Nova user since… I honestly can’t even remember, and to me, Nova equals Android, and it’s always been clear Nova thoroughly and truly understood what demanding Android users were looking for. I have really never used any other launcher, and it’s the first application I install on all my Android devices. Seeing this vital application bought up by a mobile analytics form of all things is gut-wrenching. Several decades covering this industry have taught me that acquisitions like this pretty much exclusively mean doom, and usually signal a slow but steady decline in quality and corresponding increase in user-hostile features. I’m always open to being proven wrong, but I don’t have a lot of hope. In any event, I guess it’s time to find another launcher.
And another great application falls victim to Google’s absolute disdain for Android developers. Marcel Bokhorst has announced that after yet another brick wall interaction with Google, he is ending development of his popular (in the right circles) open source email client FairEmail. All my projects have been terminated after Google falsely flagged FairEmail as spyware without a reasonable opportunity to appeal. There will be no further development and no more support. On XDA, he gives more background. According to Google FairEmail is spyware because it uploads the contact list. My guess is this is because of the usage of favicons, which will use the domain name of email addresses to fetch info. This feature has been removed from the Play store version now. Google has been violating EU regulation 2019/1150 on multiple occasions now by not being transparent about what exactly the problem is, but what can I do? Complain via the EU, wait five years for action while the app is being removed from the Play store? FairEmail obviously isn’t as popular as the Gmail application or Outlook, but it does have more than 500.000 installs on Google Play (it’s als available on F-Droid), and if you care about open source and privacy, there’s very few other places to go for email on Android (whether Google-less or not). It’s incredibly full-featured and was regularly updated. It’s sad to see rare applications like this fall victim to Google’s inscrutable bureaucracy, but I fully understand Bokhorst throwing in the towel.
At its Google I/O event on Wednesday, Google released the second beta of Android 13. The search giant highlighted several new aspects to Android 13 including better privacy controls that help users to limit what data apps have access to, an improved Material You theme system that works across more apps, a new Settings & Privacy page that can help you boost your security, swanky music controls that adjust their look based on the music you’re listening to, and the ability to change the language of each app – something that music be quite handy if you are bilingual and prefer certain apps in a particular language. You can really tell we’ve hit a fairly stable feature ceiling for mobile operating systems. New releases don’t really rock the boat anymore, and there’s rarely any major, tent pole features that you’ll miss out on. Still, updates are updates, and they come with more than just new features – security fixes are reason enough phone makers should be forced to support phones with full Android version updates for at least five years, preferably longer.
Android’s Accessibility API is an incredibly powerful tool intended for developers to build apps for users with disabilities. The API lets apps read the contents of the screen and perform inputs on behalf of the user, which are essential functions for screen readers and alternative input systems. Unfortunately, these functions are also incredibly useful for malicious apps that want to steal data from users, which is why Google has been cracking down on which apps are allowed to use the Accessibility API. Google has already limited which apps on Google Play can use the Accessibility API, and in Android 13, they’re taking things one step further by heavily restricting API access for apps that the user has sideloaded from outside of an app store. And so, step by step, Google locks down more and more of Android. Some of the most fascinating and unique applications use the Accessiblity APIs, and making it harder for them to do their thing will have a chilling effect on the wild innovation we see in the Android world. For now, this restriction only applies to applications sideloaded outside of application stores (e.g, applications installed through F-Droid are not affected), but I have my doubt slippery slope is suddenly going to even out at this specific point. After all, we must be protected against ourselves at all costs.
It’s already April and we’ve been making steady progress refining the features and stability of Android 13, building around our core themes of privacy and security, developer productivity, as well as tablet and large screen support. Today we’re moving into the next phase of our cycle and releasing the first Beta of Android 13. Android 13 development seems to be ahead of the regular schedule.
Today, we’re releasing the first developer preview for the Privacy Sandbox on Android, which provides an early look at the SDK Runtime and Topics API. You’ll be able to do preliminary testing of these new technologies and evaluate how you might adopt them for your solutions. This is a preview, so some features may not be implemented just yet, and functionality is subject to change. See the release notes for more details on what’s included in the release. We’ll see if this initiative will have a material impact on user privacy on Android, but I have my sincerest doubt. Even if does make more applications respect your privacy, I have a feeling this is going to be a classic situation of “rules for thee but not for me” (a phrase far newer and more recent than I realised).
Building on the foundation laid by Android 12, described by many as the biggest Android OS update since 2014, this year’s upcoming Android 13 release refines the feature set and tweaks the user interface in subtle ways. However, it also includes many significant behavioral and platform changes under the hood, as well as several new platform APIs that developers should be aware of. For large screen devices in particular, Android 13 also builds upon the enhancements and features introduced in Android 12L, the feature drop for large screen devices. Android 13 is set for release later this year, but ahead of its public release, Google has shared preview builds so developers can test their applications. The preview builds provide an early look at Android 13 and introduces many — but not all — of the new features, API updates, user interface tweaks, platform changes, and behavioral changes to the Android platform. In this article, we’ll document all of the changes that we find so you can prepare your application or device for Android 13. This is a long and detailed article, and both users and developers alike should be able to find some interesting information in here. You might want to set aside a decent amount of time for this one.
Starting on November 1, 2022, existing apps that don’t target an API level within two years of the latest major Android release version will not be available for discovery or installation for new users with devices running Android OS versions higher than apps’ target API level. As new Android OS versions launch in the future, the requirement window will adjust accordingly. This is a very welcome move, since finding incredibly old and abandoned applications is not an uncommon occurrence in the Play Store. Clean-ups like this almost make up for Google removing the “last updated on” field in Play Store listings. Almost.
Back in 2020, Google announced that it would require all apps in the Play Store to use its billing system but later delayed that to this month. Google will soon allow Android apps to use their own payment system as long as Play Store billing is an option alongside it, with Spotify notably the first “User Choice Billing” partner. Regulatory pressure is mounting, and it’s clear it’s been working. This is a major concession by Google, and a very welcome one. We’ve still got a long, long way to go, but things are, at least, changing for the better. Slowly.
