https://grapheneos.org/faq#future-devices
Devices are carefully chosen based on their merits rather than the project aiming to have broad device support. Broad device support is counter to the aims of the project, and the project will eventually be engaging in hardware and firmware level improvements rather than only offering suggestions and bug reports upstream for those areas. Much of the work on the project involves changes that are specific to different devices, and officially supported devices are the ones targeted by most of this ongoing work.
Hardware, firmware and software specific to devices like drivers play a huge role in the overall security of a device. The goal of the project is not to slightly improve some aspects of insecure devices and supporting a broad set of devices would be directly counter to the values of the project. A lot of the low-level work also ends up being fairly tied to the hardware.
Non-exhaustive list of requirements for future devices, which are standards met or exceeded by current Pixel devices:
- Support for using alternate operating systems including full hardware security functionality
- Complete monthly Android Security Bulletin patches without any regular delays longer than a week
- At least 4 years of updates from launch (Pixels now have 7)
- Vendor code updated to new monthly, quarterly and yearly releases of AOSP within several months to provide new security improvements (Pixels receive these in the month they're released)
- Linux 5.15 or Linux 6.1 Generic Kernel Image (GKI) support
- Hardware accelerated virtualization usable by GrapheneOS (ideally pKVM but another usable implementation may be acceptable)
- Hardware memory tagging (ARM MTE or equivalent)
- BTI/PAC, CET or equivalent
- PXN, SMEP or equivalent
- PAN, SMAP or equivalent
- Isolated radios (cellular, Wi-Fi, Bluetooth, NFC, etc.), GPU, SSD, media encode / decode, image processor and other components
- Support for A/B updates of both the firmware and OS images with automatic rollback if the initial boot fails one or more times
- Verified boot with rollback protection for firmware
- Verified boot with rollback protection for the OS (Android Verified Boot)
- Verified boot key fingerprint for yellow boot state displayed with a secure hash (non-truncated SHA-256 or better)
- StrongBox keystore provided by secure element
- Hardware key attestation support for the StrongBox keystore
- Attest key support for hardware key attestation to provide pinning support
- Weaver disk encryption key derivation throttling provided by secure element
- Insider attack resistance for updates to the secure element (Owner user authentication required before updates are accepted)
- Inline disk encryption acceleration with wrapped key support
- 64-bit-only device support code
- Wi-Fi anonymity support including MAC address randomization, probe sequence number randomization and no other leaked identifiers
In order to support a device, the appropriate resources also need to be available and dedicated towards it. Releases for each supported device need to be robust and stable, with all standard functionality working properly and testing for each of the releases.