We've retracted our recommendation to use fastboot from the android-tools package on Arch Linux. It's broken for flashing the Pixel 7 and Pixel 7 Pro.

We currently only recommend using the official platform-tools package or building fastboot from GrapheneOS or AOSP from source.

We've updated https://grapheneos.org/install/cli to remove that recommendation. Most users are installing GrapheneOS via our easy to use web installer at https://grapheneos.org/install/web instead where we provide the fastboot implementation via fastboot.js library created based on GrapheneOS funding.

It's unfortunate that seemingly every Linux distribution has broken Android SDK packages because they insist on checking out the sources their own way and using a custom build system instead of the official one. It's easy to build these tools properly if you do it normally.

GrapheneOS CLI install guide

Command-line installation instructions for GrapheneOS, a security and privacy focused mobile OS with Android app compatibility.

GrapheneOS
@grapheneos Is there an issue tracker or a more explanatory post on what is going on with android-tools?

@grapheneos I don't see any packaging changes to the Arch package?

Is that a recent regression?

@Foxboron @grapheneos Pixel 7 and Pixel 7 Pro were only released fairly late in October and we added support for them within a few days. Most of our users have been using our web installer.

Only users who used CLI install on GrapheneOS would have had issues. We started seeing more and more people having that issue until we realized the Arch package has something wrong with it. We don't know what's wrong with it.

It could be that it's using the wrong revision of a repository or something similar. It works fine for older devices without the new partitions, but we dropped the recommendation as a whole for now since we don't know what else is wrong.

@grapheneos Fedora and openSUSE android-tools packages also don't work.

Distros break the SDK packages since android-tools are usually built as part of the IDE itself (or something like that), and they have to make the tools build individually.

@neel platform-tools is a standalone package usable by itself. The reason they break it is because they don't check out the sources with repo and don't build it with the Android Open Source Project build system. They try to check out only a smaller set of repositories, build it with the distribution toolchain and link against system libraries potentially with missing features and bug fixes. They use their own build system, not the AOSP soong build system using ninja as a backend.

Some distributions also don't understand the AOSP release system and wrongly use OS stable release tags to build platform-tools. It's meant to be built from the platform-tools tags for the standalone stable release. It can be built from the OS tags but is only meant to be used for working with the specific OS version you built and you're better off using the latest platform-tools instead even when doing development work on a specific OS version.

You can build the individual tools if you want instead of platform-tools as a whole. They don't want to use the AOSP toolchain but they could replace that with their own without using their own build system. It would still be best to use the same toolchain revisions instead of a different one and to use the same libraries, etc. instead of trying to use different system ones. It's a typical Linux distribution problem.

It's also highly problematic that it gets frozen at an ancient version in Debian, etc. They have a development snapshot based on an Android 10 stable release which was not meant to be used for building standalone platform-tools. It's ancient and is half a year older than it seems since Android 10 didn't have the latest platform-tools code during the life of Android 10.