Android Archive
Google has been on a bit of a marketing blitz to try and counteract some of the negative feedback following its new developer verification requirement for Android applications, and while they’re using a lot of words, none of them seem to address the core concerns. It basically comes down to that they just don’t care about the consequences this new requirement has for projects like F-Droid, nor are they really bothered by any of the legitimate privacy concerns this whole thing raises. If this new requirement is implemented in its current form, F-Droid will simply not be able to continue to exist in its current form. F-Droid builds the applications in its repository themselves and signs them, and developer verification does not fit into that picture at all. F-Droid works this way to ensure its applications are built from the publicly available sources, so developers can’t sneak anything nefarious into any binaries they would otherwise be submitting themselves. The privacy angle doesn’t seem to bother Google much, either, which shouldn’t be a surprise to anyone. With this new requirement, Android application developers can simply no longer be anonymous, which has a variety of side-effects, not least of which is that anyone developing applications for, say, dissidents, can now no longer be anonymous. Google claims they won’t be sharing developer information with governments, but we all know that’s a load of bullshit, made all the more relevant after whatever the fuck this was. If you want to oppose the genocide in Gaza or warn people of ICE raids, and want to create an Android application to coordinate such efforts, you probably should not, and stick to more anonymous organising tools. Students and hobbyists are getting the short end of the stick, too, as Google’s promised program specifically for these two groups is incredibly limited. Yes, it waves the $25 fee, but that’s about the only positive here: Developers who register with Google as a student or hobbyist will face severe app distribution restrictions, namely a limit on the number of devices that can install their apps. To enforce this, any user wanting to install software from these developers must first retrieve a unique identifier from their device. The developer then has to input this identifier into the Android Developer Console to authorize that specific device for installation. ↫ Mishaal Rahman at Android Authority Google does waive the requirement for developer certification for one particular type of user, and in doing so, highlights the only group of users Google truly cares about: enterprise users. Any application installed by an enterprise on managed devices will not need to have its developer certified. Google states that in this particular use case, the enterprise’s IT department is responsible for any security issues that may arise. Isn’t it funny how the only group of users who won’t have to deal with this nonsense are companies who pay Google tons of money for their enterprise tools? The only way we’re going to get out of this is if any governments step up and put a stop to this. We can safely assume the United States’ government won’t be on our side – they’re too busy with their recurring idiotic song-and-dance anyway – so our only hope is the European Commission stepping in, but I’m not holding my breath. After all, Apple’s rules and regulations regarding installing applications outside of the App Store in the EU are not that different from what Google is going to do. While the EU is not happy with the details of Apple’s rules, their general gist seems to be okay with them. I’m afraid governments won’t be stepping in to stop this one.
The consequences of Google requiring developer certification to install Android applications, even outside of Google’s own Play Store, are starting to reverberate. F-Droid, probably the single most popular non-Google application repository for Android, has made it very clear that Google’s upcoming requirement is most likely going to mean the end of F-Droid. If it were to be put into effect, the developer registration decree will end the F-Droid project and other free/open-source app distribution sources as we know them today, and the world will be deprived of the safety and security of the catalog of thousands of apps that can be trusted and verified by any and all. F-Droid’s myriad users will be left adrift, with no means to install — or even update their existing installed — applications. ↫ F-Droid’s blog post A potential loss of F-Droid would be a huge blow to anyone trying to run Android without Google’s applications and frameworks installed on their device. It’s pretty clear that Google is doing whatever it can to utterly destroy the Android Open Source Project, something I’ve been arguing is what the rumours about Google killing AOSP really mean. Why kill AOSP, when you can just make it utterly unusable and completely barren? Sadly, there isn’t much F-Droid can do. They’re proposing regulators the world over look at Google’s plans, and hopefully come to the conclusion that they’re anti-competitive. Specifically the European Union and the tools provided by the Digital Markets Act could prove useful here, but in the end, only if the will exists to use them can these tools be used in the first place. It’s dark times for the smartphone world right now, especially if you care about consumer rights and open source. iOS has always been deeply anti-consumer, and while the European Union has managed to soften some of the rough edges, nothing much has changed there. Android, on the other hand, had a thriving open source, Google-free community, but decision by decision, Google is beating it into submission and killing it off. The Android of yesteryear doesn’t exist anymore, and it’s making people who used to work on Android back during the good old times extremely sad. Jean-Baptiste Quéru, husband of OSNews’ amazing and legendary previous managing editor Eugenia Loli-Queru, worded it like this a few days ago: All the tidbits of news about Android make me sad. I used to be part of the Android team. When I worked there, making the application ecosystem as open as the web was a goal. Releasing the Android source code as soon as something hit end-user devices was a goal. Being able to run your own build on actual consumer hardware was a goal. For a while after I left, there continued to be some momentum behind what I had pushed for. But, now, 12 years later, this seems to have all died. I am sad… ↫ Jean-Baptiste Quéru And so am I. Like any operating system, Android is far from perfect, but it was remarkable just how open it used to be. I guess good things just don’t survive once unbridled capitalism hits.
It’s no secret that Google wants to bring Android to laptops and desktops, and is even sacrificing Chrome OS to get there. It seems this effort is gaining some serious traction lately, as evidenced by a conversation between Rick Osterloh, Google’s SVP of platforms and devices, and Qualcomm’s CEO, Christiano Amon, during Qualcomm’s Snapdragon Summit. Google may have just dropped its clearest hint yet that Android will soon power more than phones and tablets. At today’s Snapdragon Summit kickoff, Qualcomm CEO Cristiano Amon and Google’s SVP of Devices and Services Rick Osterloh discussed a new joint project that will directly impact personal computing. “In the past, we’ve always had very different systems between what we are building on PCs and what we are building on smartphones,” Osterloh said on stage. “We’ve embarked on a project to combine that. We are building together a common technical foundation for our products on PCs and desktop computing systems.” ↫ Adamya Sharma at Android Authority Amon eventually exclaimed that’s he’s seen the prototype devices, and that “it is incredible”. He added that “it delivers on the vision of convergence of mobile and PC. I cannot wait to have one.” Now, marketing nonsense aside, this further confirms that soon, you’ll be able to buy laptops running Android, and possibly even desktop systems running Android. The real question, though, is – would you want to? What’s the gain of buying an Android laptop over a traditional Windows or macOS laptop? Then there’s Google’s infamous fickle nature, launching and killing products seemingly randomly, without any clear long-term plans and commitments. Would you buy an expensive laptop running Android, knowing full well Google might discontinue or lose interest in its attempt to bring Android to laptops, leaving you with an unsupported device? I’m sire schools that bought into Chromebooks will gradually move over to the new Android laptops as Chrome OS features are merged into Android, but what about everyone else? I always welcome more players in the desktop space, and anything that can challenge Microsoft and Apple is welcome, but I’m just not sure if I have faith in Google sticking with it in the long run.
GrapheneOS is a security and privacy-focused mobile operating system based on a modified version of Android (AOSP). To enhance its protection, it integrates advanced security features, including its own memory allocator for libc: hardened malloc. Designed to be as robust as the operating system itself, this allocator specifically seeks to protect against memory corruption. This technical article details the internal workings of hardened malloc and the protection mechanisms it implements to prevent common memory corruption vulnerabilities. It is intended for a technical audience, particularly security researchers or exploit developers, who wish to gain an in-depth understanding of this allocator’s internals. ↫ Nicolas Stefanski at Synacktiv GrapheneOS is quite possibly the best way to keep your smartphone secure, and even law enforcement is not particularly amused that people are using it. If the choice is between security and convenience, GrapheneOS chooses security every time, and that’s the reason it’s favoured by many people who deeply care about (smartphone) security. The project’s social media accounts can be a bit… Much at times, but their dedication to security is without question, and if you want a secure smartphone, there’s really nowhere else to turn – unless you opt to trust the black box security approach from Apple. Sadly, GrapheneOS is effectively under attack not from criminals, but from Google itself. As Google tightens its grip on Android more and more, as we’ve been reporting on for years now, it will become ever harder for GrapheneOS to deliver the kind of security and fast update they’ve been able to deliver. I don’t know just how consequential Google’s increasing pressure is for GrapheneOS, but I doubt it’s making the lives of its developers any easier. It’s self-defeating, too; GrapheneOS has a long history of basically serving as a test best for highly advanced security features Google later implements for Android in general. A great example is the Memory Tagging Extension, a feature implemented by ARM in hardware, which GrapheneOS implements much more widely and extensively than Google does. This way, GrapheneOS users have basically been serving as testers to see if applications and other components experience any issues when using the feature, paving the way for Google to eventually, hopefully, follow in GrapheneOS’ footsteps. Google benefits from GrapheneOS, and trying to restrict its ability to properly support devices and its access to updates is shortsighted.
Google continues putting nails in the coffin that is the Android Open Source Project. This time, they’re changing the way they handle security updates to appease slow, irresponsible Android OEMs, while screwing over everyone else. The basic gist is that instead of providing monthly security updates for OEMs to implement on their Android devices, Google will now move to a quarterly model, publishing only extremely severe issues on a monthly basis. The benefit for OEMs is that for most vulnerabilities, they get three months to distribute (most) fixes instead of just one month, but the downsides are also legion. Vulnerabilities will now be out in the wild for three months instead of just one, and while they’re shared with OEMs “privately”, we’re talking tends of thousands of pairs of eyes here, so “privately” is a bit of a misnomer. The dangers are obvious; these vulnerabilities will be leaked, and they will be abused by malicious parties. Another massive downside related to this change is that Google will now no longer be providing the monthly patches as open source within AOSP, instead only releasing the quarterly patch drops as open source. This means exactly what you think it does: no more monthly security updates from third-party ROMs, unless those third-party ROMs choose to violate the embargo themselves and thus invite all sorts of problems. Extending the patch access window from one month to three is absolutely insane. Google should be striving to shorten this window as much as possible, but instead, they’re tripling it in length to create a false sense of security. OEMs can now point at their quarterly security updates and claim to be patching vulnerabilities as soon as Google publishes them, while in fact, the unpatched vulnerabilities will have been out in the wild for months by that point. This change is irresponsible, misguided, and done only to please lazy, shitty OEMs to create a false sense of security for marketing purposes.
Three years ago, the incredibly popular Android launcher Nova Launcher was acquired by Branch, a mobile links and analytics company. Understandably, people were worried this would spell the end of the launcher, as it would certainly become a vessel for tracking and mobile advertising. Weirdly enough, this never actually happened – instead, Nova just kind of fizzled out. First, virtually the entire Nova team was laid off two years after the acquisition, save for Nova’s original founder, Kevin Barry, who was not let go. Development had come to a halt already at that point, and ever since, it’s been quiet. Until this weekend. Barry posted on his blog that he left Branch, and thus is no longer working on Nova Launcher. You’d think this would be the final nail in the coffin for this once rather ubiquitous launcher, but that’s actually not the case, as Barry explains. For the past several months I have been preparing the Open Source release of Nova Launcher. This work included cleaning up the codebase, reviewing licenses, removing or replacing proprietary code, and coordinating with legal to ensure a proper release. When Branch acquired Nova in 2022, Branch then-CEO and founder Alex Austin made several public commitments to the community about Nova’s future, including statements about open sourcing: However I was ultimately asked to stop working on Nova Launcher and the open sourcing effort. ↫ Kevin Barry Basically, one of the reasons Barry felt comfortable selling Nova to Branch was a contractual agreement – backed up by public statements from then-CEO of Branch, Alex Austin – that if Barry were to leave Branch, he would be allowed to release Nova as open source. It seems that this promise is not being honoured by the new CEO, for unclear reasons, leaving what was arguably one of the best launchers for Android in limbo. Nobody’s working on it anymore, and a contractual agreement is not being honoured, for whatever reason. One of the people who used to work on Nova but was part of that first round of layoffs, Cliff Wade, is now trying to raise awareness of this stalemate. He’s trying to talk to former colleagues at Branch, and trying to put some pressure on Branch to honour their contractual obligations and public promises. I’m fully behind this effort, because up until the institutional neglect set in, Nova was one of the very best Android applications, clearly made by people who truly understood what Android enthusiasts wanted out of a highly configurable launcher. Branch needs to honour its word, and allow Barry to continue preparing the release of Nova as open source. Head on over to Branch’s contact page, and let them know they need to release Nova as open source – in a polite, constructive manner, of course. The people working at Branch are just ordinary folk like you and I, and I will not stand for anyone being aggressive, insulting, or otherwise committing harassment towards Branch and its employees.
Google’s grip on Android keeps tightening. In what will certainly be another step that we will look back upon as just another nail in the coffin, Google is going to require every Android developer to register with Google, even if they don’t publish anything in the Play Store. In other words, even if you develop Android applications ad only make them available through F-Droid or GitHub, you’ll still have to register with Google and hand over a bunch of personal information and a small fee of $25. Google is effectively recreating Apple’s Gatekeeper for macOS, but on Android. It won’t come as a surprise to you that Google is doing this in the name of security and protecting users. The company claims that its own analysis found “over 50 times more malware from internet-sideloaded sources than on apps available through Google Play”, and the main reason is that malware developers can hide behind anonymity. As such, Google’s solution is to simply deanonymise every single Android developer. Starting next year, Android will require all apps to be registered by verified developers in order to be installed by users on certified Android devices. This creates crucial accountability, making it much harder for malicious actors to quickly distribute another harmful app after we take the first one down. Think of it like an ID check at the airport, which confirms a traveler’s identity but is separate from the security screening of their bags; we will be confirming who the developer is, not reviewing the content of their app or where it came from. This change will start in a few select countries specifically impacted by these forms of fraudulent app scams, often from repeat perpetrators. ↫ Suzanne Frey at the Android Developer Blog This new policy will only apply to “certified Android devices”, which means Android devices that ship with Google Play Services and all related Google stuff preinstalled. How this policy will affect devices running de-Googled Android ROMs like GrapheneOS where the user has opted to install the Play Store and Google Play Services is unclear. Google does claim the personal information you hand over as part of your registration will remain entirely private and not be shown to anyone, but that’s not going to reassure anyone. To its small credit, Google intends to create an Android Developer Console explicitly for developers who only operate outside of the Play Store, and a special workflow for students and hobbyists that waives the $25 fee. First tests will start in October of this year, with an official rollout in a number of countries later in 2026, which will then expand to cover the whole world. The first countries seeing the official rollout will be countries hit especially hard by scams (according to Google’s research, at least): Brazil, Indonesia, Singapore, and Thailand. Google has been trying to claw back control over Android for years now, and it seems the pace is accelerating lately. None of these steps should surprise you, but they should highlight just how crucially important it is that we somehow managed to come to a viable third way, something not controlled by either Apple or Google.
Have a Samsung phone (outside of the United States), and want to unlock the bootloader? Well, soon you won’t be able to do so anymore, as Samsung seems to be removing this option from their phones – including already sold models being upgraded to One UI 8. Bootloader unlocking is a popular way to breathe new life into older devices, by loading unofficial software onto a device, like custom ROMs, gaining root access, custom kernels, etc. This option will be taken away from users with One UI 8. This means not only is the OEM Unlock not visible in Settings anymore, but the bootloader doesn’t even contain any of the code required to unlock itself. This means a workaround to brute force it open is not possible at all, unless Samsung updates the bootloader to add this logic back in. ↫ Josh Skinner at SammyGuru And so, the ongoing process of locking down Android to a point where it becomes nigh-on indistinguishable from iOS’ locked-down, anti-user nature continues unabated. Samsung is the default choice for Android users in a lot of places around the world, and seeing them, too move ever closer to fully locking down their phones is terrible news for consumers. We should be striving for less restrictive computing, not more. Combined with persistent rumours that Google is looking into effectively taking Android closed source, leaving only a stub AOSP behind, the future of Android as an least somewhat “open” platform looks quite grim indeed.
The Linux Terminal app that Google introduced earlier this year is one of the most exciting new features in Android, not for what it currently does but for what it can potentially do. The Terminal app lets you boot up an instance of Debian in a virtual machine, allowing you to run full-fledged Linux apps that aren’t available on Android. Unfortunately, the current version of the Terminal app is limited to running command line programs, but that’s set to change in the near future. In the new Android Canary build that Google released today, the Terminal app now lets you run graphical Linux apps. ↫ Mishaal Rahman at Android Authority It comes with Weston, the reference implementation of a Wayland compositor, allowing you to run a basic graphical environment and accompanying applications. It won’t be long before you can take your Pixel, connect a display, and run KDE. Neat, but so many devils are in so many details here, and there’s so many places where this can fall apart entirely if the wrong decisions are made.
Late last year, Mishaal Rahman reported that Google was going to merge ChromeOS and Android, and it seems Google itself has now confirmed that’s exactly what’s happening. “I asked because we’re going to be combining ChromeOS and Android into a single platform, and I am very interested in how people are using their laptops these days and what they’re getting done,” Samat explained. ↫ Lance Ulanoff at TechRadar I’m definitely interested to see what using Android across desktops, laptops, tablets, martphones, and smartwatches is going to be like. The same applications on all those form factors? So many have tried, and as many have failed. I just don’t think Google has what it takes.
To better support you and provide earlier, more consistent access to in-development features, we are announcing a significant evolution in our pre-release program. Moving forward, the Android platform will have a Canary release channel, which will replace the previous developer preview program. This Canary release channel will function alongside the existing beta program. This change is designed to provide a more streamlined and continuous opportunity for you to try out new platform capabilities and provide feedback throughout the entire year, not just in the early months of a new release cycle. ↫ Dan Galpin on the Android Developers Blog This new Canary channel is intended for developers, and you can expect a ton of bugs and breaking changes. Updates are basically streamed continuously over the air, but not all changes will make it to a final release of Android (as in, they can be pulled definitively). You can join the new channel with any supported Pixel device, but going back to a beta or final release will require a full wipe.
With the release of Android 16, Google changed how it developed Android. Development is now taking place behind closed doors, with the code dropped after the corresponding version has been released to Pixel devices. Well, it turns out this wasn’t the only thing Google has changed about Android development. As the developers of CalyxOS, a popular de-Googled Android ROM, dove into the Android 16 AOSP source code, they realised something very important was missing: the device-specific source code for modern Pixel devices. Android 16 was released to AOSP yesterday but with a one big difference than typical releases: Google did not publish any device-specific source code for supported, modern Pixel devices. In previous years, Google released full device trees alongside new Android versions. This allowed developers to build and boot AOSP on Pixel hardware relatively easily. With Android 16, only the platform/framework code has been released. The device trees are missing, at least for now. This means AOSP 16 cannot currently be built or run on any recent Pixel device easily just using official source. It’s unclear whether this is a delay or a policy change. Either way, it seriously disrupts custom ROM development and our porting efforts. ↫ CalyxOS on Reddit If this is truly a policy change, it’s a big one that affects custom ROM developers considerably. Pixel devices were “special” among custom ROM developers because support for them was part of AOSP releases, so they were well-supported by projects like CalyxOS, GrapheneOS, and LineageOS, including all the hardware components, and with quick updates. Without access to the Pixel-specific source code for the Pixel 6 to Pixel 9a, these devices will now have to be treated like any other Android phone as far as ROM developers go, meaning it’ll take a lot more work and time to get them to work properly with new major Android releases. Google did not announce this potential policy change, and this has some in the custom Android ROM community on edge. I’ve been talking to people in the custom ROM community, and the story goes that a few months ago, at least one of these communities was approached by a journalist who wanted to talk to them. This journalist claimed that Google intends to discontinue the Android Open Source Project, with the first step Google would take being no longer releasing the device-specific Pixel source code (something nobody knew would happen until yesterday). The fact that this first step has now become a reality lends some credence to the journalist’s claim that Google is discontinuing AOSP. However, since such tips are not uncommon, and since there was no way to verify, the custom ROM developers in question didn’t really know what to do with it. During the writing of this article over the past 12 hours, Google itself has also responded to what is apparently a growing, now public concern in the wider Android community. Seang Chau, Google VP and GM of Android Platform, published a Tweet, disclaiming Google has any intentions to close up shop for AOSP. We’re seeing some speculation that AOSP is being discontinued. To be clear, AOSP is NOT going away. AOSP was built on the foundation of being an open platform for device implementations, SoC vendors, and instruction set architectures. AOSP needs a reference target that is flexible, configurable, and affordable – independent of any particular hardware, including those from Google. For years, developers have been building Cuttlefish (available on GitHub as the reference device for AOSP) and GSI targets from source. We continue to make those available for testing and development purposes. ↫ Seang Chau This seems like a solid denial from Google, but it leaves a lot of room for Google to make a wide variety of changes to Android’s development and open source status without actually killing off AOSP entirely. Since Android is licensed under the Apache 2.0 license, Google is free to make “Pixel Android” – its own Android variant – closed source, leaving AOSP up until that point available under the Apache 2.0 license. This is reminiscent of what Oracle did with Solaris. Of course, any modifications to the Linux kernel upon which Android is built will remain open source, since the Linux kernel is licensed under the GPLv2. If Google were indeed intending to do this, what could happen is that Google takes Android closed source from here on out, spinning off whatever remains of AOSP up until that point into a separate company or project, as potentially ordered during the antitrust case against Google in the United States. This would leave Google free to continue developing its own “Pixel Android” entirely as proprietary software – save for the Linux kernel – while leaving AOSP in the state it’s in right now outside of Google. This technically means “AOSP is not going away”, as Chau claims. Of course, other parties would then be free to continue working on and contributing to AOSP, but AOSP itself would no longer benefit from the work done by Google. Again, this feels very similar to how illumos and OpenIndiana are built atop the last open source release of Solaris from 2010, without any of the additional work Oracle has done on Solaris since then. As you can tell, there’s a lot of speculation here, because even if all of this is true, it seems the ongoing court case and any rulings that come of it will play a major role in Google’s decision-making process. The Android Open Source Project has been gutted over the years, with Google leaving more and more parts of it to languish, while moving a lot of code and functionality into proprietary components like Google Mobile Services and Google Play Services. Taking “Pixel Android” closed source almost feels like the natural next step in the process of gutting AOSP that’s been ongoing for well over a decade. As it stands today, a default AOSP installation requires a lot of additional components and applications before it can be considered a complete mobile
Today, we’re bringing you Android 16, rolling out first to supported Pixel devices with more phone brands to come later this year. This is the earliest Android has launched a major release in the last few years, which ensures you get the latest updates as soon as possible on your devices. Android 16 lays the foundation for our new Material 3 Expressive design, with features that make Android more accessible and easy to use. ↫ Seang Chau at the Google blog Android 16 doesn’t seem like a very big release, and that’s because for most users, it really isn’t. There’s some neat features in here, like improved notification grouping, live notifications, a slew of protection features for people who run increased risk (think journalists or victims of abuse), and proper desktop-style windowing on tablets, which seems like the tentpole feature for now. The Material 3 Expressive design is not really here yet, though as that will come in subsequent Android 16 updates. The release for devices coincides with the release of the source code, which is no longer released as part of the development process, but dumped across the fence at release time. This means that those of us using a de-Googled Android ROM – I use GrapheneOS – will have to wait a bit longer than we’re used to before getting the new version.
About a year ago, we talked about the fact that Android 15 became page size-agnostic, supporting both 4 KB and 16 KB page sizes. Google was already pushing developers to get their applications ready for 16 KB page sizes, which means recompiling for 16 KB alignment and testing on a 16 KB version of an Android device or simulator. Google is taking the next step now, requiring that every application targeting Android 15 or higher submitted to Google Play after 1 November 2025 must support a page size of 16 KB. This is a key technical requirement to ensure your users can benefit from the performance enhancements on newer devices and prepares your apps for the platform’s future direction of improved performance on newer hardware. Without recompiling to support 16 KB pages, your app might not function correctly on these devices when they become more widely available in future Android releases. ↫ Dan Brown on the Android Developers Blog This is mostly only relevant for developers instead of users, but in the extremely unlikely scenario that one of your favourite applications cannot be made to work with 16 KB page sizes for some weird reason, or the developer refuses to support it or some even weirder reason, you might have to say goodbye to that applications if you use Android 15 or higher. This is absurdly unlikely, but I wouldn’t be surprised if it happens to at least one application. If that happens, I want to know which application that is, and ask the developer for their story.
Google’s accelerated Android release cycle will soon deliver a new version of the software, and it might look quite different from what you’d expect. Amid rumors of a major UI overhaul, Google seems to have accidentally published a blog post detailing “Material 3 Expressive,” which we expect to see revealed at I/O later this month. Google quickly removed the post from its design site, but not before the Internet Archive saved it. ↫ Ryan Whitwam at Ars Technica Google seems to be very keen on letting us know this new redesign is based on a lot of user research and metrics, which always sets off alarm bells in my mind when it comes to user interfaces. Every single person uses their smartphone and its applications a little differently, and using tons of metrics and data to average all of this out can make it so that anyone who strays to far from that average is going to have a bad time. This is compounded by the fact that each and every one of us is going to stray form the average in at least a few places. Google also seems to be throwing consistency entirely out of the window with this redesign, which chills me to the bone. One of the reasons I like the current iteration of Material Design so much is that it does a great job of visually (and to a less extent, behaviourally) unifying the operating system and the applications you use, which I personally find incredibly valuable. I very much prefer consistency over disparate branding, and the screenshots and wording I’m seeing here seem to indicate Google considers that a problem that needs fixing. As with everything UI, screenshots don’t tell the whole story, so maybe it won’t be so bad. I mean, it’s not like I’ve got anywhere else to go in case Google messes this up. Monopolies (or duopolies) are fun.
When Google released the fourth beta of Android 16 this month, many users were disappointed by the lack of major UI changes. As Beta 4 is the final beta, it’s likely the stable Android 16 release won’t look much different than last year’s release. However, that might not hold true for subsequent updates. Google recently confirmed it will unveil a new version of its Material Design theme at its upcoming developer conference, and we’ve already caught glimpses of these design changes in Android—including a notable increase in background blur effects. Ahead of I/O next month, here’s an early look at Google’s upcoming Android redesign. ↫ Mishaal Rahman at Android Authority With Android, it’s hard to really care about changes like these because it will take forever and a day for the Android ecosystem to catch up, and in general in mobile computing, most people use applications that have zero respect for platform integration anyway, preferring their own shit branding and UI “design” over that of the platform they’re running on. In other words, most people will never really encounter many of these changes, unless they’re Pixel users. That being said, these changes seem to basically replace a lot of “window” backgrounds with a blur, which makes everything feel more airy and brighter – so much so that in screenshots purporting to show dark mode, it looks like light mode. This doesn’t really seem like the “big UI overhaul” the linked article claims it to be, but there might be more changes on the way we haven’t seen yet. Instead of UI changes, I’m much more concerned about how much worse Google will be making Android by shoving Clippy into every corner of the operating system.
Up until now, Google developed several components of Android out in the open, as part of AOSP, while developing everything else behind closed doors, only releasing the source code once the final new Android version was released. This meant that Google had to merge the two branches, which lead to problems and issues, so Google decided it’s now moving all development of Android behind closed doors. What will change is the frequency of public source code releases for specific Android components. Some components like the build system, update engine, Bluetooth stack, Virtualization framework, and SELinux configuration are currently AOSP-first, meaning they’re developed fully in public. Most Android components like the core OS framework are primarily developed internally, although some features, such as the unlocked-only storage area API, are still developed within AOSP. Beginning next week, all Android development will occur within Google’s internal branches, and the source code for changes will only be released when Google publishes a new branch containing those changes. As this is already the practice for most Android component changes, Google is simply consolidating its development efforts into a single branch. ↫ Mishaal Rahman at Android Authority This brings up a very old debate: if development happens entirely behind closed doors, with only the occasional code drop, is the software in question really open source? Technically, the answer is obviously ‘yes’ – there’s no requirement that development take place in public. However, I’m fairly sure that when most people think of open source, they think not only of occasionally throwing chunks of code over the proverbial corporate walls, but also of open development, where everybody is free to contribute, pipe in, and follow along. Clearly, this move makes Android more closed, not less so, and it follows in a long string of changes Google has made to Android that make it ever harder to consider AOSP, the Android Open Source Project, a capable, modern mobile operating system. The Android fork of the Linux kernel will always be properly open, of course, but I have my doubts Android in and of itself will remain open source in the narrow definition for much longer, and even if it does, you have to wonder how much value it will have. I mean, Darwin, the open source base underneath macOS and iOS, is technically open source, but nobody cares because Apple made it pretty much worthless in and of itself. Anything of value is stripped out and not only developed behind closed doors, but also not released as open source, ensuring Darwin is nothing but a curiosity we sometimes remember exists. Android could be heading in the same direction. My biggest worry are Android ROMs, most notably for me personally GrapheneOS. I honestly have no idea how this will impact such projects.
Google’s biggest announcement today, at least as it pertains to Android, is that the Vulkan graphics API is now the official graphics API for Android. Vulkan is a modern, low-overhead, cross-platform 3D graphics and compute API that provides developers with more direct control over the GPU than older APIs like OpenGL. This increased control allows for significantly improved performance, especially in multi-threaded applications, by reducing CPU overhead. In contrast, OpenGL is an older, higher-level API that abstracts away many of the low-level details of the GPU, making it easier to use but potentially less efficient. Essentially, Vulkan prioritizes performance and explicit hardware control, while OpenGL emphasizes ease of use and cross-platform compatibility. ↫ Mishaal Rahman at Android Authority Android has supported Vulkan since Android 7.0, released in 2016, so it’s not like we’re looking at something earth-shattering here. The issue has been, as always with Android, fragmentation: it’s taken this long for about 85% of Android devices currently in use to support Vulkan in the first place. In other words, Google might’ve wanted to standardise on Vulkan much sooner, but if only a relatively small number of Android devices support it, that’s going to be a hard sell. In any event, from here on out, every application or game that wants to use the GPU on Android will have to do so through Vulkan, including everything inside Android. It’s still going to be a long process, though, as the requirement to use Vulkan will not fully come into effect until Android 17, and even then there will be exceptions for certain applications. Android tends to implement changes like this in phases, and the move to Vulkan is no different. All of this does mean that older devices with GPUs that do not support Vulkan, or at least not properly, will not be able to be updated to the Vulkan-only releases of Android, but let’s be real here – those kinds of devices were never going to be updated anyway.
Starting with Android smartphones running on the Snapdragon 8 Elite Mobile Platform, Qualcomm Technologies now offers device manufacturers the ability to provide support for up to eight consecutive years of Android software and security updates. Smartphones launching on new Snapdragon 8 and 7-series mobile platforms will also be eligible to receive this extended support. ↫ Mike Genewich I mean, good news of course, but Qualcomm has a history of making empty promises, so I’ll see it when I believe it. Also note that this news doesn’t mean every Snapdragon 8 Elite Android device will get eight years of updates – it just means OEMs are able to offer such support now, not that they’ll actually do it. Considering it’s usually the OEMs refusing to offer updates, I wonder just how big the actual impact of this news will be. In any event, this includes both regular Android updates as well as two Android Common Kernel upgrades, which are required to meet this eight year window. If you want to get into the nitty-gritty about Android and the Android Common Kernels, the official Android documentation has more details.
Introduction to FRP and Common Scenarios Factory Reset Protection (FRP) is a security feature introduced by Google in Android 5.1 that later prevents unauthorized access following a factory reset. Unlocking the smartphone requires the original Google account credentials and a reliable Android phone unlocker tool. Many users experience FRP lock difficulties owing to forgotten credentials, purchasing used devices, or accidental resets. While bypassing FRP can restore access, using incorrect methods may result in data loss or security problems. This article covers the best methods to bypass FRP, such as utilizing Dr.Fone – Screen Unlock, Odin Tool, FRP bypass APKs, and ADB commands. Follow our step-by-step guide on how to bypass FRP on Android safely. Why Use Dr.Fone for FRP Bypass? Factory Reset Protection (FRP) by Google blocks unauthorized access to Android devices. Moreeover, the unlock requires a factory reset. This security feature is helpful, but if you forget your Google account credentials or buy a used device with FRP, it can be a problem. Dr.Fone – Screen Unlock (Android) provides a simple, reliable way to overcome FRP without technical skills. Key Features of Dr.Fone – Screen Unlock (Android) The efficient FRP bypass tool Dr.Fone – Screen Unlock supports several Android brands. What makes it unique: Step-by-Step Guide to Bypassing FRP using Dr.Fone. Follow these steps to bypass FRP with Dr.Fone: Step 1. Launch Dr.Fone and choose “Screen Unlock” from the main menu. Step 2. To begin the process, click “Remove Google FRP Lock.” Step 3. Connect your Android device via a USB cable and pick the brand and model (e.g., Samsung, Xiaomi). Step 4. Follow the onscreen instructions: Advanced FRP Bypass Methods More complex approaches may be required if Dr.Fone or other standard procedures fail. These methods involve technical knowledge and carry dangers such as data loss or device bricking. Before using any of these options, use caution and make sure you have a backup. 1. Odin Tool for Samsung. Odin can update Samsung firmware and remove FRP locks. Carefully follow these steps: Step 1. Install the newest Odin and combo FRP reset firmware on your PC. Launch Odin as admin. Step 2. Start Download Mode on your Samsung: Step 3. USB-connect your phone to the PC. Step 4. Check “AP/CP/CSC” when Odin recognizes the device. Flash the firmware by importing the combination file and clicking Start. After rebooting, the FRP lock will be gone. 2. FRP bypass APKs FRP Bypass APK removes Google account verification on Android devices without a computer for free. It may not function on the latest Android versions. Use these steps: Step 1. Download the FRP Bypass APK from a reliable source. Copy the file to USB. Step 2. Start your FRP-locked Android device and go to the FRP interface. Step 2. Use an OTG cable to connect the USB drive. Install and launch FRP Bypass APK. Step 3. Select “Settings > Backup & Reset > Factory Data Reset.” Restart your phone to eliminate Google account verification. 3. Manual ADB Commands. For tech-savvy users, ADB (Android Debug Bridge) can overcome FRP; however, USB debugging must be turned on. Steps include: Step 1. Install the newest ADB Installer on your PC. Step 2. Launch adb-setup.exe, type ‘Y,’ and follow the steps to install ADB and Fastboot drivers. Step 3. Turn on your FRP-locked device and attach it to your PC via USB. Step 3. The ADB installation folder is normally on the “C:\” drive. Step 5. Hold Shift, right-click the folder, and choose “Open command window here.” Step 6. Type these commands and hit Enter after each: This should remove the FRP lock. Troubleshooting Common Issues Even with the proper tools, FRP bypass efforts might cause technical issues. Here’s how to address some of the most prevalent difficulties. 1. Device Not Recognized If your device is not identified by Odin, ADB, or other bypass tools, try the following solutions: 2. Stuck at Firmware Download If Odin or any other flashing tool freezes during the firmware download process: 3. Compatibility Errors If you encounter an error like “Device not supported”: Conclusion Android FRP bypass is difficult, but you may restore access safely with the appropriate approaches. Dr.Fone – Screen Unlock is reliable and easy to use for non-technical users. Those seeking advanced methods can use Odin, FRP bypass APKs, and ADB commands. Always utilize reputable tools to avoid security issues. Troubleshooting can fix problems. Follow the recommended procedures to protect your device after the FRP bypass.
