I don't care about any of these, I just want to be able to have whatever Google pay does without Google.
You could claim that's not an android problem but if you do I don't think you've ever had to explain to people your phone doesn't have a Google Play store.
We had that for many years. But banks stopped supporting their own payment solutions because despite not having to pay commission to Google, it was more expensive to support their own solutions.
That should also tell you that almost any open source / non-profit solution is doomed to fail due to costs. What could work is if, just like the UnifiedAttestation initiative has commercial backing, Wero is expanded to also have its own NFC payment stack. The EU already forced Apple to open up NFC, so it is possible to do it for both iOS and Android.
Would it be possible to build something that works at the os level? And is built in the system itself instead of depending on google services ? I mean I don’t think it requires internet access all the time
> They claim first tap to pay will happen later this year.
Big if true. I guess the main problem is, would the banks from all over the world join in?
Fidesmo (https://fidesmo.com/consumer/fidesmo-pay/) has managed to sidestep this by integrating with Curve (https://www.curve.com/), which issues their own card and then charges your bank’s card from their end when you pay with theirs (tokenized and emulated by Fidesmo).
(Fidesmo also integrates with a whole bunch of banks directly, though mainly EU.)
People use alternatives for many different reasons (or multiple at the same time):
- They might want privacy from Google. Using Google Pay probably doesn't make much sense.
- Security protection against Google. Google can remotely brick devices with unsandboxed Play Services. After blocking of ICC officials and all the Greenland threats, it's not odd that some European citizens would like to block this Google/US government attack vector.
- They want a clean phone without all kinds of crap like Gemini preinstalled.
- They want to reduce dependence on big tech/Google product in general.
In cases 2-4, using Google Pay with sandboxed Google Play services may be an acceptable compromise for convenience.
Without Google doesn't mean the same thing for everyone. I got a Motorola g moto stylus 2025 and have been running an experiment for almost a year now in which I use this device without ever logging into the device with a Google account. Fdroid and obtainium work flawlessly. Aurora Store works for the most part but some apps won't even let me open them without a play store signed in account which is sad.
Tap to pay apps, if the developer is trustworthy or if it’s from your bank, are significantly more secure than even carrying a physical card around as your payment is now locked behind biometrics/a pin.
You are free to reverse engineer the whole system and find a way to make it work. The world will love you. I suspect there will be a Google hardware attestation at the core of it, but understanding how it works is still huge progress.
There’s been some progress over at microG, however not fully reverse engineered obviously, and I wouldn’t hold my hopes up for now: https://github.com/microg/GmsCore/issues/361
That is essentially it as far as my understanding goes.
Google Wallet currently will not run on a fully updated grapheneOS.
Specifically it complains:
"Your device doesn't meet tap to pay security standards. It may be rooted or running uncertified software."
Which is fair. But something that actually works would be nice. I can keep extremely tight control on the NFC stack by toggling NFC with a quick access icon.
Not something I use very often, but not getting locked out of specific, not all, financial rails is one of those things that feels like it rubs up against the perpetual friction that the US founders, framers, whatever; didn't enshrine economic freedom in the same way as speech.
And maybe that's a libertarian fantasy. Idk. Seems worth thinking about for five seconds tho.
Bringing it back to reality. There are an incredible number of issues with trying to set up some kind of a competing service to Google Wallet to the extent that you might as well just go start a bank. And companies like simple have tried that and ended up bought by other banks at the end of it. And they weren't even trying to do anything other than offer people a banking app that wasn't total crap back in the day.
So realistically Google wallet or anything like that is not something I expect to use on a graphene OS phone until the graphene OS Motorola device comes out in the next few years. And that is entirely speculation that services like Google Wallet might be able to work on that device. But honestly it's the only real hope I personally hold for getting access to Modern payment systems on a secure device.
My bank had NFC payments for years. None of the remote attestation bullshit. I think it used Google's library for doing QR code scans so it wouldn't work without Google Play, but that's beside the point.
Android already supports this, and has supported this for over a decade. The restriction here is on the side of the finance ecosystem. Everyone has congregated on doing Apple/Google Pay because it's cheap and easy to maintain compared to the alternative. Cards companies and banks make deals with Google, just like they do with companies like Apple, Samsung, and Garmin.
Any fintech startup with serious backing can create an Android app that works on any ROM you can imagine. I don't think you'd have an easy time finding investors for this with how much money you need to partake in the ecosystem, but the API is ready for you to implement.
The whole GrapheneOS thing is a bit of a joke. So you either have to buy google hardware or you run google software.
Anyway, looking forward to the widespread introduction of Wero. Maybe there will be some options for third party roms in the name of digital soveranity. Seems like they want to make the EUDI wallet for digital documents no-google capable for that reason at least.
The monopoly/gatekeeping effect of an OS developer making apps that compete with independent apps has such an easy solution. The OS must not give private api's or special permissions to its in-house apps. Don't try to fight the gatekeeping feature by feature, that is whack-a-mole.
Bonus points if you require the primary UI (window manager in the language of the ancients) to be an installable app.
This is a fabulous ruling and the EU continues (for the moment at least) to be the biggest champion of holding corporations to account and pushing back on entrenched tech power.
I know there are bunch of concerning things like chat control getting pushed through but at least there is a counterbalance in other areas as well.
> AI services will be able to easily interact with other apps installed on the device and perform tasks on behalf of the user within those apps, for tasks that the apps and the user have chosen to make available to AI services. These tasks include “send a message”, “create a note”, “schedule a meeting”. This includes access to certain Google apps (i.e.Gmail, Calendar, Drive, Docs, Maps, YouTube, Messages and Phone) that Alphabet will make available through operating system-level integration channels.
> [...]
> For instance, Android implements structured on-device integration through App Functions, which developers can enable for their apps, and which can be accessed by AI services without being reserved anymore for Google services, such as Google Assistant or Gemini.
> 7. Screen automation
> AI services will be able to automate multi-step tasks within apps, on behalf of the user upon their consent. They will do so by imitating user behaviour in a separate virtual window, which makes it possible for the assistant to complete the task in the background, while the user can do something else. [...]
> Android implements screen automation via Computer Control, which can automatically access apps, and which is currently reserved for Google’s services, such as Gemini.
> 9. System-level on-device models
> AI services will be able to call on existing on-device models (“ODMs”), including the Gemini Nano ODMs, that are part of the DMA designated operating system, already preinstalled on Android devices and already made accessible to third parties. As a result of the measures, third-party AI services will have guarantees of equal access (for example, in terms of performance) to ODMs, as Google’s services. [...]
> 10. On-device model implementation
> Third parties will be able to install, run and use on-device models (ODMs) under the same hardware‑resource and background‑execution conditions that Google’s own models enjoy, and will allow their ODMs to be shared centrally with other apps. [...]
Strange page, it keeps repeating that there are 11 features and then lists four or five, thrice over, and all can be summarised as "device access for competitors' AI voice assistants and dependencies thereof". Then there's some FAQ about the timeline and such. At the very bottom is a link to what seems to be the legal details but ends you up on a search page. Unfolding the only result, there is a link to the 'decision text', which of course you can't just read as text but need to get as a PDF download so the lines can't be broken up and the text is super hard to read using, say, an android phone or screen reader. This format ought to die already.
Edit: reading that document, I understand now why that press release, as well as the submission above, doesn't get further than a handful noteworthy properties and that even those partially seem like dependencies of each other: that's all it is. It's all about running code on a device activated by a hotword and the access such that it can actually be used (access to the NPU, ability to run in the background, ability to start phone calls, access to sensors, ability to display things on the screen...)
The core issue is not "Google not allowing a feature", it's that small businesses cannot buy phones, install a patched version of Android without a restriction and sell them to make money.
Until this problem is solved, everything else is palliative.
The thing is: Google is one of the few Android phone vendors that makes doing so possible at all. Samsung, Nokia, Xiaomi, Oppo, and all the others lock their bootloaders and provide no way to relock them with your own key once you've managed to break them. Google is one of the few (if not only) vendor that actually designs their hardware to permit this. That's how GrapheneOS has blossomed.
When it comes to running patched operating systems, Google's phones are pretty much the only ones that provide a decent option for running secure and user-controlled firmware. It's every other vendor, from Apple to Xiaomi, that's preventing people from doing so.
That said, there are a few companies out there that will happily put your brand and your firmware on their hardware. That's how the Trump Phone was made, the biggest example of this practice in the west. Other utility brands have been releasing cheap crap branded phones for years (like the Gigaset smartphone). You'll need money upfront and a decent minimum order quantity, but getting phones with firmware you control straight from the factory is still an option.
Obviously the Google Play features being available only to Google are a problem, and it's good that the EU is forcing Google to cut the crap, but Google's restrictions aren't the reason companies aren't running custom ROMs. It's pretty much everyone but Google that's at fault for that, from vendors restricting user freedom to app developers restricting their apps to Google Play certified devices only.
It is one of many projects that make alternative, AOSP-based operating systems (e.g. GrapheneOS, LineageOS, /e/OS), and some of them sell devices for an additional source of income (e.g. Murena who develop /e/OS also does this).
Ah, yes, the Google/Apple narrative of "if we open the ecosystem, all users' data is at risk". Meanwhile, they are the companies that continuously harvest behavioral data from phones, put backdoors for law enforcement through weak defaults (iCloud backups are not E2E encrypted, unless you enable ADP), etc. All this while, GrapheneOS, LineageOS, etc. provide real, provable privacy.
Funnily enough, I think it is in Google's best interest to comply and do the best work they can.
Besides security that they might want to guarantee up to a limit, that would boost Android usage, also including their own hardware.
The future lies in a large, local-friendly ecosystem and the hardware to support it.
Gate keeping software makes even less sense nowadays.
The competition is on compute offering. Cheaper, faster, at scale. They can have a competitive advantage over incumbents if they stay smart.
Funnily enough, I think it is in Google's best interest to comply and do the best work they can. Besides security that they might want to guarantee up to a limit, that would boost Android usage, also including their own hardware.
It is not necessarily a competitive advantage, because Apple needs to do the same (which is why they aren't releasing the new iOS 27 Siri, etc. in the EU).
Apple and Google just took different approaches: Google just released their stuff in violation of the DMA and had the EU come at them. Apple chose to be in compliance before before releasing their assistant updates, though they tried to lobby the EC in favor of releasing now with the promise of adding interoperability in N months.
I am completely in favor of this. But for Google/Apple the best outcome giving their own assistance preferential treatment. More subscription income.
Will be interesting to see how Google implements a more open DSP wake-word detection. The requirement for it to work without the app holding a default role suggests needing to recognize multiple wake-words for each of the non-default apps that uses one.
From an openness perspective this is excellent. Technically it seems challenging with a DSP designed to detect a single thing using as little power as possible. Currently this balances doing as little work as possible to detect plausible utterances of the wake-word on the DSP while minimizing the costs of spurious wake-ups on the CPU. At the very least multiple wake-words seems to need the DSP to do more work and wake up the CPU more often.
What a shame. How much time and €M spent just to deign allow you to do some very specific stuff on their devices (in 5 years at least once the trials and shenanigans settle) ? Obviously it doesn't include the "answering call screening" for example, which requires very privileged APIs accessible only by "system" apps, i.e. the ones preinstalled in the ROM. How about RCS ? Remember RCS the "open" standard replacing SMS ?
RCS is partially open. The protocol is public, as are one or two authentication features. The biggest restriction for custom RCS implementations is that carriers often require access to SIM card functionality to authenticate a phone to their IMS. Only system software (your OS vendor, Google, maybe additional libraries like Facebook in some products) can access those. Unlike SMS, there is no simple "send this string to the modem and you've sent a message" communication method. The entire thing is SIP+RTP+a few other protocols, wrapped up in a brandable package. RCS is as open as SMS has been for a while, perhaps even more open as the SMS stack can only be reliably implemented in IP-only software stacks in LTE+ networks; 3G and below require integrations not even the Android system supports natively.
If you run a custom ROM, you can sign your own RCS app and have no such restrictions, of course. The same is true for devices with root access. There's nothing preventing anyone from writing a fully featured RCS client or library for custom ROMs, except maybe carriers filtering out unofficial ROMs, but those are a SIM card swap away. Nobody seems to have started working on an RCS app for those platforms yet. There are a few open source libraries out there, but they don't see much activity, and none of them implement the full RCS suite (which includes video calling and even exchanging money).
When people complain about RCS being closed off, most of them don't care about the RCS protocol. They want Google's libraries to handle all the hard work for them and provide an API to interact with without having to implement the carrier protocol side. RCS is already open, but they want Google Messages to be open, not RCS.
However, the EU's laws regarding gatekeepers require that a significant amount of people actually use the supposedly gatekept platform. Very few people within the EU use RCS. I don't think RCS is even close to being relevant for the EU's gatekeeper regulations. The only people talking about RCS on the European market are companies trying to peddle their RCS marketing spam delivery mechanism to other companies.
If the USA would adopt similar laws, the situation would probably be different. Don't expect the EU to care about gatekeepers in a market consumers aren't interested in.
Why should I need root or build my own ROM to use an alternative app implementing the whole RCS low level stack ? I sure don't have to do this to change my SMS app (yet). It may be the modem or the OS doing the low level stuff for SMS I don't care, a proper "mobile os" would provide APIs to do it.
Why doesn't the AOSP Messaging app implement it if it's so standard and open ?
https://android.googlesource.com/platform/packages/apps/Mess...
RCS is a nothingburger in Europe, virtually everybody uses WhatsApp (and a smaller group also Signal, etc.). RCS is especially relevant to the US where many people use iMessage and the downgrade path is SMS/MMS.
Whoops my bad then, disregard previous post. Creating a facebook account at once with my national id in addition to my carrier subscription. Gotta love US dependency.
No, the procedure was specifically against Google Android and the decision document (https://ec.europa.eu/competition/digital_markets_act/cases/2...) is titled "CASE DMA.100220| Alphabet - OS - Google Android - Art. 6(7) - SP - AI". It doesn't mention the existence of other market parties than Alphabet/Google/Android, from what I saw in a quick read-through
It sounds reasonable to apply the same logic to all vendors with similar market power, though. Perhaps this opens the door for an accelerated procedure against Apple as well
Indeed. This ruling seems to be targeted at AI specifically. It is a great ruling, because it allows proper competition of other assistants with Google's (and Bixby). However, IMO the bigger evil is all the anti-competitive stuff that make it impossible for competitors to Android/iOS to enter the market, including European products like SailfishOS, such as remote attestation and the things that flow from it (e.g. no tap-to-pay support with most banks). The EC seems very pre-occupied with competition inside Android/iOS, while completely forgetting about competition between mobile OSes.
It is also pretty jarring to see the EU talk a lot about sovereignty, but then further entrenching the Android/iOS duopoly by baking remote attestation into the EUDI reference wallet (and copied into the national wallets), effectively shutting out alternative systems yet again.
Yes, I know that the EU consists of a lot of bodies and sometimes the right hand doesn't know what the left hand does. But man, sometimes I wish there was a stronger single, long-term vision. Somehow they seem to have forgotten about January this year (Greenland threats) and that as long as we fully depend on Android/iOS, etc. the US could shut down pretty much all modern communication infra. But instead of solving these vulnerabilities now and pouring money into alternatives, we (as the EU) drag ourselves down into battles of just how much we can do on the terrain of some feudal overlords.
It seems like there is a short window where we still have AOSP systems that could be workable for the large population (outside remote attestation, pretty much all apps run on GrapheneOS, microG, etc.) and Google's strong arming through developer verification and remote attestation could still be put back in the box. But the EC does nada, nothing (presumably).
I agree that attestation is the biggest deal. My current hope is that the upcoming GrapheneOS phones will be able to achieve that. It's really up to a manufacturer being able to strong-arm third-parties - banks and such - into accepting their chain of trust, and Motorola may be able to do that.
Phone-tap-to-pay is not a real blocker. In fact I think it should be illegal for all vendors. Just use your physical plastic card. Stick it on the back of your phone if you like.
It's up to third party app developers to choose what library to use, of course. A court case between the EU and Google isn't going to chance anything about the verification steps apps like Netflix or your bank might use, that will have to be a separate case.
I personally have found great use from the little notifications that graphene OS pops up when the integrity API is accessed and it tells me the application. I saw Instagram accessing the integrity API probably entirely by coincidence while doing something in another app and so Instagram got immediately removed even though I never use it anyway.
feel free to keep your why did you have Instagram on your graphene OS phone to yourself. I know. I know. I know. I know. XD
and a little message when you tap on those notifications is exactly what the parent commenter stated encouraging users to contact app developers so that they can use basic integrity attestation and allow their apps to work on graphene OS.
and some apps do work and use the integrity API. maybe a little too much in my opinion. chatgpt I'm looking at you. my local credit Union's banking app doesn't even bother with the integrity API and they updated their tech stack recently which included app redevelopment.
Stallman was right : without the four freedoms your software owns you rather than vis-a-versa.
Interoperability is the key to breaking out of walled gardens and owning your own data and digital self.
This is a big win but google will fight back it seems instead of embracing interoperability.
It may seem trivial but using a small DSP running a tiny model to provide a battery efficient always on wake up call for home AI is huge.
As a carer for elders who rely on AI to use modern devices in the face of their difficulty keeping up with interface changes this bodes well.
Gatekeeping AI and the future with hidden features is straight out of the bad old days of M$’s embrace, extend and extinguish.
I embraced AI to let my elders control their home and they love being in control but are constantly frustrated with UI changes and often find themselves stuck unable to call me with ‘Alexa call Daniel’ which provides them with hope if they wake stuck in a nightmare.
Come on google, please don’t be evil embrace interoperability and the open source community.
Well done Eff, Cory Doctorow and the Pirate parties of Europe for this small win
I don't care about any of these, I just want to be able to have whatever Google pay does without Google.
You could claim that's not an android problem but if you do I don't think you've ever had to explain to people your phone doesn't have a Google Play store.
We had that for many years. But banks stopped supporting their own payment solutions because despite not having to pay commission to Google, it was more expensive to support their own solutions.
That should also tell you that almost any open source / non-profit solution is doomed to fail due to costs. What could work is if, just like the UnifiedAttestation initiative has commercial backing, Wero is expanded to also have its own NFC payment stack. The EU already forced Apple to open up NFC, so it is possible to do it for both iOS and Android.
Would it be possible to build something that works at the os level? And is built in the system itself instead of depending on google services ? I mean I don’t think it requires internet access all the time
1 reply →
Walt https://walt.is/ is building exactly that in Europe. They claim first tap to pay will happen later this year.
Some European banks including mine offer NFC payments via their app as well. You don't need Google services.
> They claim first tap to pay will happen later this year.
Big if true. I guess the main problem is, would the banks from all over the world join in?
Fidesmo (https://fidesmo.com/consumer/fidesmo-pay/) has managed to sidestep this by integrating with Curve (https://www.curve.com/), which issues their own card and then charges your bank’s card from their end when you pay with theirs (tokenized and emulated by Fidesmo).
(Fidesmo also integrates with a whole bunch of banks directly, though mainly EU.)
> offer NFC payments via their app
NAB here in Australia did previously as well, but then they stopped doing that in 2022.
https://www.zdnet.com/finance/banking/nab-waves-goodbye-to-n...
Why would anyone who cares enough about security/privacy to run a de-googled phone want to use a tap to pay app?
People use alternatives for many different reasons (or multiple at the same time):
- They might want privacy from Google. Using Google Pay probably doesn't make much sense.
- Security protection against Google. Google can remotely brick devices with unsandboxed Play Services. After blocking of ICC officials and all the Greenland threats, it's not odd that some European citizens would like to block this Google/US government attack vector.
- They want a clean phone without all kinds of crap like Gemini preinstalled.
- They want to reduce dependence on big tech/Google product in general.
In cases 2-4, using Google Pay with sandboxed Google Play services may be an acceptable compromise for convenience.
11 replies →
Without Google doesn't mean the same thing for everyone. I got a Motorola g moto stylus 2025 and have been running an experiment for almost a year now in which I use this device without ever logging into the device with a Google account. Fdroid and obtainium work flawlessly. Aurora Store works for the most part but some apps won't even let me open them without a play store signed in account which is sad.
How about a way to use contactless payments on, say, a Pebble watch?
1 reply →
Because people have different priorities than you do, and just because you can't imagine something, it doesn't mean it's not real or reasonable.
Some people like to have choices other than "all" and "nothing"
Tap to pay apps, if the developer is trustworthy or if it’s from your bank, are significantly more secure than even carrying a physical card around as your payment is now locked behind biometrics/a pin.
Also de-googling isn’t the point of GrapheneOS.
Well it's going to be a matter of time anyway, I'm already forced to use an app when I'd rather not.
But more than that I want to have a choice.
Because it’s convenient?
14 replies →
Because tap to pay has nothing to do with Google?
Some people just want a phone without the duopoly and nothing else.
Why can't I use my bank's app, which I presumably already trust, to tap-to-pay? Why should there be a third party involved at all?
You are free to reverse engineer the whole system and find a way to make it work. The world will love you. I suspect there will be a Google hardware attestation at the core of it, but understanding how it works is still huge progress.
There’s been some progress over at microG, however not fully reverse engineered obviously, and I wouldn’t hold my hopes up for now: https://github.com/microg/GmsCore/issues/361
That is essentially it as far as my understanding goes.
Google Wallet currently will not run on a fully updated grapheneOS.
Specifically it complains:
"Your device doesn't meet tap to pay security standards. It may be rooted or running uncertified software."
Which is fair. But something that actually works would be nice. I can keep extremely tight control on the NFC stack by toggling NFC with a quick access icon.
Not something I use very often, but not getting locked out of specific, not all, financial rails is one of those things that feels like it rubs up against the perpetual friction that the US founders, framers, whatever; didn't enshrine economic freedom in the same way as speech.
And maybe that's a libertarian fantasy. Idk. Seems worth thinking about for five seconds tho.
Bringing it back to reality. There are an incredible number of issues with trying to set up some kind of a competing service to Google Wallet to the extent that you might as well just go start a bank. And companies like simple have tried that and ended up bought by other banks at the end of it. And they weren't even trying to do anything other than offer people a banking app that wasn't total crap back in the day.
So realistically Google wallet or anything like that is not something I expect to use on a graphene OS phone until the graphene OS Motorola device comes out in the next few years. And that is entirely speculation that services like Google Wallet might be able to work on that device. But honestly it's the only real hope I personally hold for getting access to Modern payment systems on a secure device.
blows my mind that there’s not a single open solution for mobile wallets and nobody is saying anything.
You have to negotiate directly with Visa to convince them why they should accept your system. How will you convince them?
14 replies →
Because a normal card is superior in most practical cases?
17 replies →
"open solution for mobile wallets"
define open wallet then
My bank had NFC payments for years. None of the remote attestation bullshit. I think it used Google's library for doing QR code scans so it wouldn't work without Google Play, but that's beside the point.
Android already supports this, and has supported this for over a decade. The restriction here is on the side of the finance ecosystem. Everyone has congregated on doing Apple/Google Pay because it's cheap and easy to maintain compared to the alternative. Cards companies and banks make deals with Google, just like they do with companies like Apple, Samsung, and Garmin.
Any fintech startup with serious backing can create an Android app that works on any ROM you can imagine. I don't think you'd have an easy time finding investors for this with how much money you need to partake in the ecosystem, but the API is ready for you to implement.
There's Curve Pay which works on GrapheneOS
What cards & banks does it work with these days? Last time I checked, it wasn't really a serious alternative.
The whole GrapheneOS thing is a bit of a joke. So you either have to buy google hardware or you run google software.
Anyway, looking forward to the widespread introduction of Wero. Maybe there will be some options for third party roms in the name of digital soveranity. Seems like they want to make the EUDI wallet for digital documents no-google capable for that reason at least.
1 reply →
A phone case with your NFC credit card in a pocket on the back. Boom, problem solved.
This is a great solution if you have the physical card. One very nice use case of Google/Apple Pay is being able to pay with a virtual card in-person.
Google should've been broken up eons ago.
[dead]
The monopoly/gatekeeping effect of an OS developer making apps that compete with independent apps has such an easy solution. The OS must not give private api's or special permissions to its in-house apps. Don't try to fight the gatekeeping feature by feature, that is whack-a-mole.
Bonus points if you require the primary UI (window manager in the language of the ancients) to be an installable app.
Then the OS developer will simply make these "apps" part of the OS.
This is a fabulous ruling and the EU continues (for the moment at least) to be the biggest champion of holding corporations to account and pushing back on entrenched tech power. I know there are bunch of concerning things like chat control getting pushed through but at least there is a counterbalance in other areas as well.
[flagged]
Show us recent rulings in the federal level in the US in favor of people/consumers and ill bail.
Very nice, here are the 11 Android features that must be made accessible to third party's: https://digital-markets-act.ec.europa.eu/developer-portal/in...
My favorites:
> 6. Structured on-device integration
> AI services will be able to easily interact with other apps installed on the device and perform tasks on behalf of the user within those apps, for tasks that the apps and the user have chosen to make available to AI services. These tasks include “send a message”, “create a note”, “schedule a meeting”. This includes access to certain Google apps (i.e.Gmail, Calendar, Drive, Docs, Maps, YouTube, Messages and Phone) that Alphabet will make available through operating system-level integration channels.
> [...]
> For instance, Android implements structured on-device integration through App Functions, which developers can enable for their apps, and which can be accessed by AI services without being reserved anymore for Google services, such as Google Assistant or Gemini.
> 7. Screen automation
> AI services will be able to automate multi-step tasks within apps, on behalf of the user upon their consent. They will do so by imitating user behaviour in a separate virtual window, which makes it possible for the assistant to complete the task in the background, while the user can do something else. [...]
> Android implements screen automation via Computer Control, which can automatically access apps, and which is currently reserved for Google’s services, such as Gemini.
> 9. System-level on-device models
> AI services will be able to call on existing on-device models (“ODMs”), including the Gemini Nano ODMs, that are part of the DMA designated operating system, already preinstalled on Android devices and already made accessible to third parties. As a result of the measures, third-party AI services will have guarantees of equal access (for example, in terms of performance) to ODMs, as Google’s services. [...]
> 10. On-device model implementation
> Third parties will be able to install, run and use on-device models (ODMs) under the same hardware‑resource and background‑execution conditions that Google’s own models enjoy, and will allow their ODMs to be shared centrally with other apps. [...]
Strange page, it keeps repeating that there are 11 features and then lists four or five, thrice over, and all can be summarised as "device access for competitors' AI voice assistants and dependencies thereof". Then there's some FAQ about the timeline and such. At the very bottom is a link to what seems to be the legal details but ends you up on a search page. Unfolding the only result, there is a link to the 'decision text', which of course you can't just read as text but need to get as a PDF download so the lines can't be broken up and the text is super hard to read using, say, an android phone or screen reader. This format ought to die already.
Anyway, the actual decision text: https://ec.europa.eu/competition/digital_markets_act/cases/2...
Edit: reading that document, I understand now why that press release, as well as the submission above, doesn't get further than a handful noteworthy properties and that even those partially seem like dependencies of each other: that's all it is. It's all about running code on a device activated by a hotword and the access such that it can actually be used (access to the NPU, ability to run in the background, ability to start phone calls, access to sensors, ability to display things on the screen...)
This is all smoke and mirrors.
The core issue is not "Google not allowing a feature", it's that small businesses cannot buy phones, install a patched version of Android without a restriction and sell them to make money.
Until this problem is solved, everything else is palliative.
The thing is: Google is one of the few Android phone vendors that makes doing so possible at all. Samsung, Nokia, Xiaomi, Oppo, and all the others lock their bootloaders and provide no way to relock them with your own key once you've managed to break them. Google is one of the few (if not only) vendor that actually designs their hardware to permit this. That's how GrapheneOS has blossomed.
When it comes to running patched operating systems, Google's phones are pretty much the only ones that provide a decent option for running secure and user-controlled firmware. It's every other vendor, from Apple to Xiaomi, that's preventing people from doing so.
That said, there are a few companies out there that will happily put your brand and your firmware on their hardware. That's how the Trump Phone was made, the biggest example of this practice in the west. Other utility brands have been releasing cheap crap branded phones for years (like the Gigaset smartphone). You'll need money upfront and a decent minimum order quantity, but getting phones with firmware you control straight from the factory is still an option.
Obviously the Google Play features being available only to Google are a problem, and it's good that the EU is forcing Google to cut the crap, but Google's restrictions aren't the reason companies aren't running custom ROMs. It's pretty much everyone but Google that's at fault for that, from vendors restricting user freedom to app developers restricting their apps to Google Play certified devices only.
I recently learned that there is a business doing exactly that:
https://iode.tech/
I don't think it's high volume, I think this is done by some of the microg folks.
But OEMs probably do everything in their power to make this business model unviable or at least not scale.
It is one of many projects that make alternative, AOSP-based operating systems (e.g. GrapheneOS, LineageOS, /e/OS), and some of them sell devices for an additional source of income (e.g. Murena who develop /e/OS also does this).
> it's that small businesses cannot buy phones, install a patched version of Android without a restriction
Pardon my ignorance; but why would Android need to be patched? Is it because it wouldn't run on the phone hardware otherwise?
>Is it because it wouldn't run on the phone hardware otherwise?
Because those 11 features mentioned in the OP post need to be unlocked.
What prevents this? I always assumed they could.
Bootloaders are locked and most of them are unlockable.
2 replies →
https://www.theguardian.com/commentisfree/2026/jan/10/trump-...
DMCA and other anti-circumvention regulations.
2 replies →
Who wants a bootleg Android that sends all your call logs who knows where? xD
Ah, yes, the Google/Apple narrative of "if we open the ecosystem, all users' data is at risk". Meanwhile, they are the companies that continuously harvest behavioral data from phones, put backdoors for law enforcement through weak defaults (iCloud backups are not E2E encrypted, unless you enable ADP), etc. All this while, GrapheneOS, LineageOS, etc. provide real, provable privacy.
Please stop parroting surveillance tech company's narratives.
1 reply →
Everyone who buys an Android phone. This is about the opposite, an option to buy a phone that does not do that.
7 replies →
Emm.. as if Samsung doesn't..?
Funnily enough, I think it is in Google's best interest to comply and do the best work they can. Besides security that they might want to guarantee up to a limit, that would boost Android usage, also including their own hardware.
The future lies in a large, local-friendly ecosystem and the hardware to support it.
Gate keeping software makes even less sense nowadays.
The competition is on compute offering. Cheaper, faster, at scale. They can have a competitive advantage over incumbents if they stay smart.
Funnily enough, I think it is in Google's best interest to comply and do the best work they can. Besides security that they might want to guarantee up to a limit, that would boost Android usage, also including their own hardware.
It is not necessarily a competitive advantage, because Apple needs to do the same (which is why they aren't releasing the new iOS 27 Siri, etc. in the EU).
Apple and Google just took different approaches: Google just released their stuff in violation of the DMA and had the EU come at them. Apple chose to be in compliance before before releasing their assistant updates, though they tried to lobby the EC in favor of releasing now with the promise of adding interoperability in N months.
I am completely in favor of this. But for Google/Apple the best outcome giving their own assistance preferential treatment. More subscription income.
Exactly, this ruling makes Android stronger.
Is this ruling related to https://keepandroidopen.org/ at all? It's not clear to me..
Unrelated
Will be interesting to see how Google implements a more open DSP wake-word detection. The requirement for it to work without the app holding a default role suggests needing to recognize multiple wake-words for each of the non-default apps that uses one.
From an openness perspective this is excellent. Technically it seems challenging with a DSP designed to detect a single thing using as little power as possible. Currently this balances doing as little work as possible to detect plausible utterances of the wake-word on the DSP while minimizing the costs of spurious wake-ups on the CPU. At the very least multiple wake-words seems to need the DSP to do more work and wake up the CPU more often.
What a shame. How much time and €M spent just to deign allow you to do some very specific stuff on their devices (in 5 years at least once the trials and shenanigans settle) ? Obviously it doesn't include the "answering call screening" for example, which requires very privileged APIs accessible only by "system" apps, i.e. the ones preinstalled in the ROM. How about RCS ? Remember RCS the "open" standard replacing SMS ?
RCS is partially open. The protocol is public, as are one or two authentication features. The biggest restriction for custom RCS implementations is that carriers often require access to SIM card functionality to authenticate a phone to their IMS. Only system software (your OS vendor, Google, maybe additional libraries like Facebook in some products) can access those. Unlike SMS, there is no simple "send this string to the modem and you've sent a message" communication method. The entire thing is SIP+RTP+a few other protocols, wrapped up in a brandable package. RCS is as open as SMS has been for a while, perhaps even more open as the SMS stack can only be reliably implemented in IP-only software stacks in LTE+ networks; 3G and below require integrations not even the Android system supports natively.
If you run a custom ROM, you can sign your own RCS app and have no such restrictions, of course. The same is true for devices with root access. There's nothing preventing anyone from writing a fully featured RCS client or library for custom ROMs, except maybe carriers filtering out unofficial ROMs, but those are a SIM card swap away. Nobody seems to have started working on an RCS app for those platforms yet. There are a few open source libraries out there, but they don't see much activity, and none of them implement the full RCS suite (which includes video calling and even exchanging money).
When people complain about RCS being closed off, most of them don't care about the RCS protocol. They want Google's libraries to handle all the hard work for them and provide an API to interact with without having to implement the carrier protocol side. RCS is already open, but they want Google Messages to be open, not RCS.
However, the EU's laws regarding gatekeepers require that a significant amount of people actually use the supposedly gatekept platform. Very few people within the EU use RCS. I don't think RCS is even close to being relevant for the EU's gatekeeper regulations. The only people talking about RCS on the European market are companies trying to peddle their RCS marketing spam delivery mechanism to other companies.
If the USA would adopt similar laws, the situation would probably be different. Don't expect the EU to care about gatekeepers in a market consumers aren't interested in.
Why should I need root or build my own ROM to use an alternative app implementing the whole RCS low level stack ? I sure don't have to do this to change my SMS app (yet). It may be the modem or the OS doing the low level stuff for SMS I don't care, a proper "mobile os" would provide APIs to do it. Why doesn't the AOSP Messaging app implement it if it's so standard and open ? https://android.googlesource.com/platform/packages/apps/Mess...
1 reply →
RCS is a nothingburger in Europe, virtually everybody uses WhatsApp (and a smaller group also Signal, etc.). RCS is especially relevant to the US where many people use iMessage and the downgrade path is SMS/MMS.
Whoops my bad then, disregard previous post. Creating a facebook account at once with my national id in addition to my carrier subscription. Gotta love US dependency.
1 reply →
Does this apply to Apple to have something separate to Siri in iOS?
No, the procedure was specifically against Google Android and the decision document (https://ec.europa.eu/competition/digital_markets_act/cases/2...) is titled "CASE DMA.100220| Alphabet - OS - Google Android - Art. 6(7) - SP - AI". It doesn't mention the existence of other market parties than Alphabet/Google/Android, from what I saw in a quick read-through
It sounds reasonable to apply the same logic to all vendors with similar market power, though. Perhaps this opens the door for an accelerated procedure against Apple as well
So they are gonna add these to AOSP?
Obviously no, it will be another API in Google Mobile Services and you'll have to register to them to be allowed to use it.
I wonder what happened to the laws the limited market monopoly and trust
Now if only these rulings also covered attestation.
Indeed. This ruling seems to be targeted at AI specifically. It is a great ruling, because it allows proper competition of other assistants with Google's (and Bixby). However, IMO the bigger evil is all the anti-competitive stuff that make it impossible for competitors to Android/iOS to enter the market, including European products like SailfishOS, such as remote attestation and the things that flow from it (e.g. no tap-to-pay support with most banks). The EC seems very pre-occupied with competition inside Android/iOS, while completely forgetting about competition between mobile OSes.
It is also pretty jarring to see the EU talk a lot about sovereignty, but then further entrenching the Android/iOS duopoly by baking remote attestation into the EUDI reference wallet (and copied into the national wallets), effectively shutting out alternative systems yet again.
Yes, I know that the EU consists of a lot of bodies and sometimes the right hand doesn't know what the left hand does. But man, sometimes I wish there was a stronger single, long-term vision. Somehow they seem to have forgotten about January this year (Greenland threats) and that as long as we fully depend on Android/iOS, etc. the US could shut down pretty much all modern communication infra. But instead of solving these vulnerabilities now and pouring money into alternatives, we (as the EU) drag ourselves down into battles of just how much we can do on the terrain of some feudal overlords.
It seems like there is a short window where we still have AOSP systems that could be workable for the large population (outside remote attestation, pretty much all apps run on GrapheneOS, microG, etc.) and Google's strong arming through developer verification and remote attestation could still be put back in the box. But the EC does nada, nothing (presumably).
I agree that attestation is the biggest deal. My current hope is that the upcoming GrapheneOS phones will be able to achieve that. It's really up to a manufacturer being able to strong-arm third-parties - banks and such - into accepting their chain of trust, and Motorola may be able to do that.
6 replies →
Phone-tap-to-pay is not a real blocker. In fact I think it should be illegal for all vendors. Just use your physical plastic card. Stick it on the back of your phone if you like.
3 replies →
I mean EU have 20 years to make android/ios competition and they aren't able to replicate it so its them to blame
also they should not abandon Nokia back then
6 replies →
Android has an accessible hardware attestation API already (https://developer.android.com/privacy-and-security/security-...). It's what powers the attestation API that GrapheneOS made as an alternative to Play Integrity and friends (demo app: https://github.com/GrapheneOS/Auditor)
It's up to third party app developers to choose what library to use, of course. A court case between the EU and Google isn't going to chance anything about the verification steps apps like Netflix or your bank might use, that will have to be a separate case.
I personally have found great use from the little notifications that graphene OS pops up when the integrity API is accessed and it tells me the application. I saw Instagram accessing the integrity API probably entirely by coincidence while doing something in another app and so Instagram got immediately removed even though I never use it anyway.
feel free to keep your why did you have Instagram on your graphene OS phone to yourself. I know. I know. I know. I know. XD
and a little message when you tap on those notifications is exactly what the parent commenter stated encouraging users to contact app developers so that they can use basic integrity attestation and allow their apps to work on graphene OS.
and some apps do work and use the integrity API. maybe a little too much in my opinion. chatgpt I'm looking at you. my local credit Union's banking app doesn't even bother with the integrity API and they updated their tech stack recently which included app redevelopment.
Stallman was right : without the four freedoms your software owns you rather than vis-a-versa.
Interoperability is the key to breaking out of walled gardens and owning your own data and digital self.
This is a big win but google will fight back it seems instead of embracing interoperability.
It may seem trivial but using a small DSP running a tiny model to provide a battery efficient always on wake up call for home AI is huge.
As a carer for elders who rely on AI to use modern devices in the face of their difficulty keeping up with interface changes this bodes well.
Gatekeeping AI and the future with hidden features is straight out of the bad old days of M$’s embrace, extend and extinguish.
I embraced AI to let my elders control their home and they love being in control but are constantly frustrated with UI changes and often find themselves stuck unable to call me with ‘Alexa call Daniel’ which provides them with hope if they wake stuck in a nightmare.
Come on google, please don’t be evil embrace interoperability and the open source community.
Well done Eff, Cory Doctorow and the Pirate parties of Europe for this small win
Excellent, now please force them to open up app installation again!
[dead]
[dead]
Now let's bite the apple.
Is "in the EU" the new "in mice"?
Considering it has the same population as the US, are you also mice?
The EU has approximately 110 million more people than the USA.
1 reply →
Only if you consider Europeans mice, I guess?