Building and installing
There are multiple installation methods for your Razer Phone 2. They all rely on flashing one or more partitions on your device.
All installation methods can lead to data loss.
Flashing a partition will erase everything on the partition. Additionally,
the common backups methods, e.g. TWRP, will not backup the
This will produce a folder with a flashing script, and the partition images for your Razer Phone 2.
$ nix-build --argstr device razer-cheryl2 -A build.android-fastboot-images
Alternatively, you can build a specific partition image:
$ nix-build --argstr device razer-cheryl2 -A build.android-bootimg $ nix-build --argstr device razer-cheryl2 -A build.rootfs
The device will need to be booted in its bootloader, or
The boot images can be installed using the following command, assuming the
android-fastboot-images output was used.
If you have a system image (
system.img) built, you can use
flash it to the device. Note that it might be too big to fit over the
partition. In such case, it can be flashed on the
$ fastboot flash userdata system.img
Using a flashable zip
An alternative installation method is to use a flashable zip. The flashable zip can be built for your Razer Phone 2 using one of the following commands:
$ nix-build --argstr device razer-cheryl2-A build.android-flashable-bootimg $ nix-build --argstr device razer-cheryl2-A build.android-flashable-system $ nix-build --argstr device razer-cheryl2-A build.android-flashable-zip
The first two will flash only a specific partition. The last one contains the partitions of the two previous one.
The zip can either be copied to the device and selected in a compatible
Android recovery, or sent to the device through
$ adb sideload /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-flashable-razer-cheryl2-boot.zip
By default it will flash to the
system partition. Some configurations may
change this to flash to the
userdata partition. In that case, no warning is
given before flashing.
The video drivers from the vendor do not support being used with the classic framebuffer.
Only DRM (Direct Rendering Manager) is supported.
A workaround, for the time being, is to use
simplefb. Though when the device
boots in the default system, the
simplefb framebuffer stops working. It is
suspected that it is the video drivers switching the display to HDR that are
causing this issue.
A workaround to help with this workaround has been implemented. When booted in the default system, the early init will reboot to recovery. In recovery mode the kernel does not exhibit this issue.
The solution to this problem will be to properly support DRM-only workflows.
Another avenue for solving this is to fix the fbdev emulation driver for the Qualcomm vendor tree.
Yet another is to explore using mainline. Though it is unknown if the dual-DSI display, for which the vendor driver is unique, would work well with the generic code working with other SDM845 devices.
Playing with the RGB logo
$ cd /sys/class/leds $ for f in *channel*/brightness *channel*/led_current; do echo 25 > $f; done