Fuck them.

No, the actual AI runs locally, on the phone. What MLKit does is two things:

1. Downloads the actual AI models from Google’s servers — not sure, but maybe they can be bundled or downloaded from other sources.

2. Send the usage analytics about those models — again, don’t remember exactly what’s being sent but the actual prompts/source images/model responses shouldn’t be sent in normal operation.

Why I highlighted the normal operation thing is because Google is kinda famous for collecting data it shouldn’t be collecting, e.g. read this README for example: https://github.com/PlqnK/magisk-supl-replacer

Not to bash them or something, but just FYI: I got interested in how they’ve implemented AI client-side, and they use Android MLKit in their Android app for that.

The problem with MLKit is that it phones back to… ta-dam!.. Google, even if it’s not actually used by the app, and that telemetry can’t be legally (and neither in any convenient and reliable way te technically) disabled, even by the app developer.

It doesn’t seem to be sending any sensitive information in that telemetry, but I don’t know Rick: changing Google for… Google?

But the one they’ve banned is uBlock Origin. Clowns.

Also it might be specific to that particular course you’re doing, try learning it a bit from other resources and see if it helps.

For me also AI has been very helpful. At times I’ve been doing some really sketchy code because I couldn’t find any good guidance for those areas, so asking AI something like “how do I implement this piece of code in a better way and why it would be better that way?” was really helpful, since it was pointing out my mistakes and unveiling some concepts that I could search specifically (and again: some of them were not properly described in the official documentation).

I’ve used both for some side-projects. Both are hell when it comes to Android because Android itself is one hell of a spaghetti.

To me, the hardest part was not the language itself but the fact that many things you find (including in the most official Android docs!) are quite outdated — both for Java and Kotlin.

And then you do circles and circles searching the web. Then you end up upgrading some of the dependencies or the SDK itself, and here another bunch of your dependencies stops working…

So no clear winner or loser for me. In the end they both seem to be almost identical, especially when it comes to Android APIs (apart from tons of generic boilerplate code that Kotlin wraps in cool concepts of flows, coroutines and so on).

There’s indeed more decent documentation for Java, but most of the new code (starting from Google itself) seems to be coming out mostly in Kotlin, so I wouldn’t advise against learning it, you probably will need it anyway at some point.

I’d like to know more about it too.

So far, from what I know, the main problem is the drivers for everything but CPU. Linux runs perfectly on ARM, be it Apple or not, but when it comes to something like a video adapter… with HW-accelerated video decoding and stuff… here’s where you start getting problems.

Regarding software, I run an ARM-based distro inside a VM on Apple for work and everything from what I need there exists and works.

Yes, with something like OpenRouter (or Mistral’s own API) you should be able to integrate it everywhere. Also, OpenRouter, while being a US company AFAIK, seems to be pretty transparent and lets you evaluate a lot of models from different developers and running on different platforms.

I’ve used their devstral (latest one) + goose for a side project. It worked pretty decently, on par with Claude 3.7-ish Sonnet, maybe even better. And it’s not the largest: 123B. If you can have access to their larger models, that should be even better.

No. Sorry, Microslop.

Thankfully, this particular kind of tracking can be reduced practically to 0 with good informational hygiene: don’t give location permissions to crappy apps. Basically, don’t give it to any app (yes, google apps included), unless you’re absolutely sure this app doesn’t spy on you — or even better — doesn’t have internet access at all. Make it a rule: an app should either access internet or access your location, but never both.

Thank you for providing the list.

No, that might hurt someone’s feelings, so if you do that you’ll be banned from the platform, your data will perish and your whole online personality will be canceled eventually. Welcome to the modern internet :)

Fuckers.

Removed by mod

It’s also useful to have a look at this great resource: https://eylenburg.github.io/android_comparison.htm

GrapheneOS pretty much solved the closed device trees issue you’re referring to. They don’t need them anymore and use their own toolchain to workaround the issues.

The problem with Pixel 10 was different: it was released with Android 16 QPR1 out-of-the-box, but this very QPR1 hasn’t been pushed to AOSP until a couple of weeks ago. This is why the GrapheneOS build for Pixel 10 was not possible: they could not/didn’t want to port the older Android 16 OS to Pixel 10’s hardware, and they didn’t have the source code of the QPR1 to build GrapheneOS on top of it.

Now the QPR1 (and currently even the QPR2) has been pushed to AOSP, so GrapheneOS has released Android 16 QPR1-based GrapheneOS both for older phones and for Pixel 10.

A fair question to be asked: does sandboxing really matter if you view all sites on the one-origin-at-a-time and incognito-only basis? This way there’s no way for one site to escape its sandbox and get into another site’s cookies (because there are no another site’s cookies) and there’s also no way (theoretically) to escape the app sandbox imposed by Android itself and mingle with another app’s data, right?

But it’s kinda useless because it doesn’t support the most important extension: uBlock Origin.

Removed by mod