MishaalRahman

That I'm not currently sure of.

>Why don’t you create an option to bypass this whole thing permanently on adb then? You can even add your 24h delay.

When you enable the advanced flow and choose the 'indefinite' option, that allows you to install unregistered apps 'permanently', which is effectively what you're asking for, no?

(I've gotten questions on whether this setting can be restored after a factory reset or when setting up a new device - I'll have to get back to you on that if you're wondering.)

If you enable the advanced flow as described in the linked Android Developers Blog, then you can install any unregistered app, which includes those distributed by app stores like F-Droid.

If you enable the advanced flow as described in the Android Developers Blog, then you can install unregistered apps regardless of source. That includes apps from sources like F-Droid.

That's an interesting idea wrt to enabling the advanced flow during initial device setup! I'll pass it along.

>The "only change" is that you, as a developer, will be completely excluded from publishing apps in the Play Store

Google Play already requires developer verification: https://support.google.com/googleplay/android-developer/answ...

Developers who distribute Android apps on other app stores are not strictly required to undergo verification and thus can remain anonymous, but if they choose not to, then later this year (when the enforcement of verification goes active) their apps can only be installed on certified Android devices via ADB and/or the new advanced flow.

Thus, you can still install unregistered apps if they're distributed via F-Droid or other sources, but to do so, you will need to use ADB and/or go through the new advanced flow. And remember, the new advanced flow is a one-time process - once you go through with it, you can allow your device to install unregistered apps indefinitely!

If it helps, the 24-hour wait is a one-time process. You do it once, click the toggle to allow installing unregistered apps indefinitely, and then install whatever you want. You can even turn off developer options afterwards, per my understanding, and it won't impact your ability to install unregistered apps.

1) The one-time, one-day waiting period only applies if you go through the advanced flow to allow installing unregistered apps. You can still install registered apps (ie. apps made by developers who have verified their identity) even if they're distributed outside the Play Store.

2) You can use ADB to immediately install unregistered apps. ADB installs are not subject to the waiting period.

Exactly - the idea is to make it harder for scammers to create a false sense of urgency.

Right, this friction makes it much harder for a scammer to get away with saying something like, "wire me $10,000 right now or you won't see your child ever again!" as the potential victim is forced to wait 24 hours before they can install the scammer's malicious app, thus giving them time to think about it and/or call their trusted contacts.

Correct.

>It says something about 'restart your phone and reauthenticate' that's why I'm asking. What do you autenticate?

You're authenticating that you're the device owner (via your device's saved biometrics or PIN/pattern/password).

>Um yeah but then do I have to install every update via adb? I want to just use F-Droid.

No, once you go through the advanced flow and choose the option to allow installing unregistered apps indefinitely, you can both install and update unregistered apps without going through the flow again (or using ADB).

>Developers, including non-US citizens, are forced to give Google their government ID to distribute apps.

Developers can choose to not undergo verification, thereby remaining anonymous. The only change is that their applications will need to be installed via ADB and/or this new advanced flow on certified Android devices.

Either way, you can still distribute your apps wherever you want. If you verify your identity, then there are no changes to the existing installation flow from a user perspective. If you choose not to verify your identity, then the installation will still be possible but only through high-friction methods (ADB, advanced flow). These methods are high-friction so anonymous scammers can't easily coerce their victims into installing malicious software.

Googler here (community engagement for Android) - I looked into the developer options question, and it's my understanding that you don't have to keep developer options enabled after you enable the advanced flow. Once you make the change on your device, it's enabled.

If you turn off developer options, then to turn off the advanced flow, you would first have to turn developer options back on.

>- Must enable developer mode -- some apps (e.g., banking apps) will refuse to operate and such when developer mode is on, and so if you depend on such apps, I guess you just can't sideload?

Hi, I'm the community engagement manager @ Android. It's my understanding that you don't have to keep developer options enabled after you enable the advanced flow. Once you make the change on your device, it's enabled.

If you turn off developer options, then to turn off the advanced flow, you would first have to turn developer options back on.

>- One-day (day!!!) waiting period to activate (one-time) -- the vast majority of people who need to sideload something will probably not be willing to wait a day, and will thus just not sideload unless they really have no choice for what they need.

ADB installs are not impacted by the waiting period, so that is an option if you need to install certain unregistered applications immediately.

A detailed breakdown of the settlement agreement between Google and Epic that was recently unveiled on Tuesday evening.

Seang is referring to Cuttlefish, which is indeed a virtual Android device that can be run on PCs.

This is not a dupe, this is a follow up to the original story.

Thanks for linking it.

If they did ever have such a plan, they've clearly long since abandoned it. I bet they entertained the idea at one point but it was never seriously put into action.

No

You rang? No, I never ran Windows on Arm via pKVM like kdrag0n did, but I did follow up with him on that.

He's just been really busy with university and creating OrbStack that he never got time to make a tutorial on how to replicate his work.

However, other people have figured it out: https://github.com/wasdwasd0105/limbo_tensor

A Google Pixel 8, 8a, or 8 Pro.

AOSP. I don't know if it's landed yet, though. Once the QPR3 source code drops it'll likely be there.

I am well aware of how Android works, but you seem to have a misunderstanding about how the R1 works. Your point is invalid because of that.

"Even if the system app doesn't utilize much of it's permissions, it still at least won't be killed or denied from using microphone just because it's in the background or because the phone display is turned off. And again - how do you achieve Google Assistant-like direct voice activation without system permissions? How do you get rid of Google Assistant without having a ROM that doesn't include it?"

Are you aware that the Rabbit R1 doesn't listen for voice input in the background? If it did you'd have a point and I would've brought that up, but it doesn't hence it CAN be replicated as a regular app.

All interactions on the R1 begin with a push of the PTT (push to talk button)

https://www.rabbit.tech/support/article/use-rabbit-r1

On Android, third-party apps can be set as the default assistant service, which allows them to be launched with a LPP gesture (long press power), diagonal swipe up from the sides when gesture navigation is enabled, or long press of the home button when 3-button navigation is enabled.

You are correct that enabling hotword wakeup support requires system-level access, but since that isn't a function offered by the R1 anyways, your point is moot.

Finally had a chance to test it, and you're right. It's not a property that can be set via "setprop", unfortunately.

Left a reply to the author on Twitter, but putting it here as well in case they didn't see it.

Hi! I'm the guy who wrote the blog post about updatable certs in Android 14 that your article linked. Not sure if you're aware, but there's actually a system property you can set to bypass reading from the APEX cert directory.

system.certs.enabled=true

From: https://android-review.googlesource.com/c/platform/framework...