I have been waiting... so many years for this. Like, I figured it would never come. So happy to be wrong. Wonder if it will work well on Raspberry Pi and also if it will come with Hardware Video Acceleration out of the box.
I would have more faith in Raspberry Pi's own patched build of Chromium to do hardware acceleration properly on the Pi than I would have in Google's generic Chrome build.
Sure, and when I worked at Google on Chromecast there was also that build of Chromium.
All of that is very different from The G actually provided a packaged official Chrome build, though. Which for some reason they couldn't be bothered to do before (Firefox exists though)
Spotify requires Widevine CDM to run, and Firefox doesn't come with Widevine on Debian-based distros. The .so hasn't been available on arm64 except for ChromeOS. You can rip the .so out of ChromeOS (that's what RaspberryPi OS did). But ChromeOS uses its own flavor of libc so a couple of patches to glibc are required.
Same thing with YouTube. A few months ago, YouTube started to require Widevine CDM if one uses the m.youtube.com site. I can't use the non-mobile site on my phone for performance issues, so I'm essentially locked into Widevine for watching YouTube, too.
Chrome had no official arm64 build. There are distro specific builds from debian, fedora etc for arm64 chromium, but google had no official arm64 build.
There were actually some paid services that provided a distro-agnostic chromium arm64 builds mostly targeting people running puppeteer on AWS ARM lambda. You can see some discussion here https://github.com/alixaxel/chrome-aws-lambda/issues/241
This is "just" about providing the official Chrome binary to ARM64 "desktop" Linux.
You've been able to build and run Chromium on ARM Linux for a long time (I'm running it right now), it's just that they haven't provided an officially branded Chrome.
This is a good thing. While Chromium works well, there are a few things (like syncing) that is a bit of a pain to set up.
they probably meant desktop. i do browser test automation (selenium, vibium), and the lack of google chrome on arm64 trips up new users frequently. the workaround is to just use chromium, but that's a confusing extra step for some if it's not automated and hidden for you.
on that note, it would have been nice if they also clarified if this means they'll be shipping an official "chrome for testing" for arm64 linux, too.
What is necessary to run Linux ARM64 binaries on Android ARM64?
To run conda-forge arm64 Linux binaries on Android in termux requires proot-distro because the ABIs are slightly different FWIU.
What is necessary to run Android ARM64 binaries on Linux ARM64?
Android Studio, LineageOS or BlissOS's outdated Android containers, a runtime like vinegarhq/sober that emulates just enough of Android.
An Android binary that makes Linux compatible syscalls only (that doesn't require Android libraries that aren't compiled for Linux) won't work will it?
A fully statically compiled Linux ARM64 binary which only interacts with the kernel through syscalls should run no problem on ARM64 Android. From the kernel's perspective, there is no difference between a "Linux binary" and an "Android binary" because the kernel in Android is Linux.
Most programs want to interact with various system libraries and system services though. Android and your typical desktop Linux system share pretty much nothing aside from the kernel.
I don't know what you mean by an "Android ARM64 binary". If you make an ELF file containing ARM64 machine code, it doesn't matter to Linux whether you meant for it to run on Linux in an Android system, on Linux in a desktop GNU system, or on Linux in some environment with without much of a userspace at all (such as a stripped down initramfs environment).
If you mean something like an Android app, the answer is that there's a ton of system stuff that the app depends on, it interacts with more than just the kernel.
I recently switched to using an NVIDIA Spark as my primary workstation and lack of Chrome binaries for it are what finally pushed me to completely sever my relationship with Chrome and switch to Firefox.
All of that is very different from The G actually provided a packaged official Chrome build, though. Which for some reason they couldn't be bothered to do before (Firefox exists though)
Same thing with YouTube. A few months ago, YouTube started to require Widevine CDM if one uses the m.youtube.com site. I can't use the non-mobile site on my phone for performance issues, so I'm essentially locked into Widevine for watching YouTube, too.
I guess it must be a snap, not a deb package, but... wouldn't that work?
There were actually some paid services that provided a distro-agnostic chromium arm64 builds mostly targeting people running puppeteer on AWS ARM lambda. You can see some discussion here https://github.com/alixaxel/chrome-aws-lambda/issues/241
edit: I think I replied to the wrong comment.
https://www.da.vidbuchanan.co.uk/blog/netflix-on-asahi.html
You've been able to build and run Chromium on ARM Linux for a long time (I'm running it right now), it's just that they haven't provided an officially branded Chrome.
This is a good thing. While Chromium works well, there are a few things (like syncing) that is a bit of a pain to set up.
on that note, it would have been nice if they also clarified if this means they'll be shipping an official "chrome for testing" for arm64 linux, too.
Also curious about this.
Bionic (software) https://en.wikipedia.org/wiki/Bionic_(software)
To run conda-forge arm64 Linux binaries on Android in termux requires proot-distro because the ABIs are slightly different FWIU.
What is necessary to run Android ARM64 binaries on Linux ARM64?
Android Studio, LineageOS or BlissOS's outdated Android containers, a runtime like vinegarhq/sober that emulates just enough of Android.
An Android binary that makes Linux compatible syscalls only (that doesn't require Android libraries that aren't compiled for Linux) won't work will it?
Most programs want to interact with various system libraries and system services though. Android and your typical desktop Linux system share pretty much nothing aside from the kernel.
My guess is that the reason is the same reason that there aren't official updated Android containers
If you mean something like an Android app, the answer is that there's a ton of system stuff that the app depends on, it interacts with more than just the kernel.
Sorry, Google. Too late!
(Bonus: ad blocking properly works).