4 ms·

> But you can still install whatever you want over ADB... ...if you wait 24 hours. And also thanks to the new Google Play attestation API a lot of apps won't

> But you can still install whatever you want over ADB... ...if you wait 24 hours. And also thanks to the new Google Play attestation API a lot of apps won't even work on alternative Android OS'es. But that's all needed in the name of security. Never mind if your Samsung Galaxy phone is EOL and hasn't been receiving updates for 4 years anymore. It still works with the attestation API. But the fully updated GrapheneOS phone is a real security hazard apparently, so it won't work with it. So no, you can't just run everything you want via side-loading. It's pretty obvious Google is making a power play to curb down on everything that isn't going via Google Play.

ChocolateGod 3mo ago
> ...if you wait 24 hours. False. ADB is not restricted at all, the moment you enable developer options and enable ADB you can install an APK. The Google "wait 24 hour" flow only triggers if you install an APK off the web. https://www.reddit.com/r/Android/comments/1rzd0is/mishaal_rahman_important_clarifications_on_the/#:~:text=The%20waiting%20period%20does%20not,device%2C%20it's%20enabled... https://www.reddit.com/r/Android/comments/1rzd0is/mishaal_ra...
- jsiepkes 3mo ago
  Ok, that's some good news. Still leaves the attestation API though. Which makes using a non-Google sanctioned device a non-viable option. Also don't forget that the source code for Android is now, since 2026, only released twice a year (i.e. every 6 months). So overall it's quite clear which direction Google is moving in. They are clamping down on the ecosystem.
  - ChocolateGod 3mo ago
    > Still leaves the attestation API though. Which makes using a non-Google sanctioned device a non-viable option The attestation API isn't Google 'being evil', it exists as part of legal requirements that exists, namely for financial and banking applications. Any alternative platform that wanted similar kind of apps would almost certainly have to implement a similar system. > Ok, that's some good news The fact you thought wrong shows the confusion being caused by these factually incorrect articles.
    - ulrikrasmussen 3mo ago
      What legal requirements are you referring to?
    - angoragoats 3mo ago
      > as part of legal requirements that exists, namely for financial and banking applications. Please cite the laws or regulations you’re referring to, because I don’t think there are any.
      - ChocolateGod 3mo ago
        PCI-DSS (enforced by banks/payment processors) means the EMV token store on your Android phone must be in an isolated uncompromised location (usually the TEE). If your phone is rooted or has an unlocked bootloader then it's possible that trusted store is no longer secure or can be snooped on by a third party. Given Google Wallet/Pay handles EMV tokens and stores them on the phone, it has to pass PCI-DSS before banks will allow it. This is the biggest reason why Google tries as much as possible to block Google Pay on rooted/unlocked devices. If a device fails compliance (a rooted phone certainly does), as far as banks are concerned it's not safe. But people just find it easier to say "Google is Evil". You also have the EUs Payment Services Directive (so a law) which require strong customer authentication, rooted devices can also fail up here. If anyone else than the user is able to unlock the screen (and thus authenticate a payment), you've failed the Payment Services Directive.
        jsiepkes 3mo ago
        > You also have the EUs Payment Services Directive (so a law) which require strong customer authentication, rooted devices can also fail up here. Plain wrong. PSD3 does not apply to "digital wallets" [1] ("This Directive also does *not* cover, in its scope, the provision of technical services including processing or the operation of digital wallets."). > If your phone is rooted or has an unlocked bootloader then it's possible that trusted store is no longer secure or can be snooped on by a third party. That's also wrong. Even with a rooted phone you can't mess or snoop on data in the trusted execution environment. The isolation is enforced in hardware. > If a device fails compliance (a rooted phone certainly does), as far as banks are concerned it's not safe. If this were about security, then why allow phones which have known security vulnerabilities (and no longer receive updates) to pass the Google Play Integrity API tests? > But people just find it easier to say "Google is Evil". Apparently you also find it easy to forgo about the history of Android. Like how Google introduced the Google Play API about a decade ago and did a "Embrace, extend, extinguish" thing. You also conveniently stay silent on things like the fact that Google now only releases the Android sources only twice a year. [1] https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:52023PC0366 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:52...
preisschild 3mo ago
> And also thanks to the new Google Play attestation API a lot of apps won't even work on alternative Android OS'es. Tbf to Google, AFAIK they aren't forcing third party app developers to enforce Safetynet/Google attestation.

ChocolateGod 3mo ago

> ...if you wait 24 hours. False. ADB is not restricted at all, the moment you enable developer options and enable ADB you can install an APK. The Google "wait 24 hour" flow only triggers if you install an APK off the web. https://www.reddit.com/r/Android/comments/1rzd0is/mishaal_rahman_important_clarifications_on_the/#:~:text=The%20waiting%20period%20does%20not,device%2C%20it's%20enabled... https://www.reddit.com/r/Android/comments/1rzd0is/mishaal_ra...

jsiepkes 3mo ago
Ok, that's some good news. Still leaves the attestation API though. Which makes using a non-Google sanctioned device a non-viable option. Also don't forget that the source code for Android is now, since 2026, only released twice a year (i.e. every 6 months). So overall it's quite clear which direction Google is moving in. They are clamping down on the ecosystem.
- ChocolateGod 3mo ago
  > Still leaves the attestation API though. Which makes using a non-Google sanctioned device a non-viable option The attestation API isn't Google 'being evil', it exists as part of legal requirements that exists, namely for financial and banking applications. Any alternative platform that wanted similar kind of apps would almost certainly have to implement a similar system. > Ok, that's some good news The fact you thought wrong shows the confusion being caused by these factually incorrect articles.
  - ulrikrasmussen 3mo ago
    What legal requirements are you referring to?
  - angoragoats 3mo ago
    > as part of legal requirements that exists, namely for financial and banking applications. Please cite the laws or regulations you’re referring to, because I don’t think there are any.
    - ChocolateGod 3mo ago
      PCI-DSS (enforced by banks/payment processors) means the EMV token store on your Android phone must be in an isolated uncompromised location (usually the TEE). If your phone is rooted or has an unlocked bootloader then it's possible that trusted store is no longer secure or can be snooped on by a third party. Given Google Wallet/Pay handles EMV tokens and stores them on the phone, it has to pass PCI-DSS before banks will allow it. This is the biggest reason why Google tries as much as possible to block Google Pay on rooted/unlocked devices. If a device fails compliance (a rooted phone certainly does), as far as banks are concerned it's not safe. But people just find it easier to say "Google is Evil". You also have the EUs Payment Services Directive (so a law) which require strong customer authentication, rooted devices can also fail up here. If anyone else than the user is able to unlock the screen (and thus authenticate a payment), you've failed the Payment Services Directive.
      - jsiepkes 3mo ago
        > You also have the EUs Payment Services Directive (so a law) which require strong customer authentication, rooted devices can also fail up here. Plain wrong. PSD3 does not apply to "digital wallets" [1] ("This Directive also does *not* cover, in its scope, the provision of technical services including processing or the operation of digital wallets."). > If your phone is rooted or has an unlocked bootloader then it's possible that trusted store is no longer secure or can be snooped on by a third party. That's also wrong. Even with a rooted phone you can't mess or snoop on data in the trusted execution environment. The isolation is enforced in hardware. > If a device fails compliance (a rooted phone certainly does), as far as banks are concerned it's not safe. If this were about security, then why allow phones which have known security vulnerabilities (and no longer receive updates) to pass the Google Play Integrity API tests? > But people just find it easier to say "Google is Evil". Apparently you also find it easy to forgo about the history of Android. Like how Google introduced the Google Play API about a decade ago and did a "Embrace, extend, extinguish" thing. You also conveniently stay silent on things like the fact that Google now only releases the Android sources only twice a year. [1] https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:52023PC0366 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:52...

preisschild 3mo ago

> And also thanks to the new Google Play attestation API a lot of apps won't even work on alternative Android OS'es. Tbf to Google, AFAIK they aren't forcing third party app developers to enforce Safetynet/Google attestation.