TL;DR: To check Android kernel kexec support, inspect the configuration of the kernel currently running on the device. CONFIG_KEXEC=y enables the legacy kexec loading interface, while CONFIG_KEXEC_FILE=y enables the file-based interface. Android version, root access, CPU architecture and an installed kexec executable are not proof of support.
By the PrivacyPortal team
Last updated July 2026
The most reliable answer comes from /proc/config.gz or a configuration extracted from the exact kernel image installed on your device. Check both kexec options independently, because a kernel may enable one interface but not the other. Even an enabled option is only the first requirement: Android security policy, kernel signature enforcement, device-tree handling and the replacement kernel itself can still prevent a successful kexec boot.
A running kernel configuration showing the two kexec options is stronger evidence than an app, Android version or device specification.
Back up before investigating or changing a kernel
Reading a kernel configuration is normally low risk and does not require an unlocked bootloader when /proc/config.gz is available. Extracting a configuration from an official firmware package is also read-only. Back up important files before progressing beyond those checks.
Do not unlock the bootloader merely to perform this test. Bootloader unlocking normally wipes the device. It may also affect warranty support, over-the-air updates, device security and app compatibility. Rooting or installing another kernel can cause banking, workplace and media apps to reject the device through Play Integrity or their own checks. No kernel or root method can be promised to pass a particular app’s detection.
Loading or executing a replacement kernel is substantially more dangerous than checking configuration. A bad kernel, incorrect device tree or incompatible command line can leave the phone unable to boot. Never run kexec -e simply as a test.
What counts as evidence of kexec support?
Kexec lets a running Linux kernel load another kernel into memory and transfer control to it without returning through the device’s normal firmware boot sequence. Android inherits the mechanism from Linux, but phone manufacturers frequently disable it.
| Check | What it establishes | Reliability |
|---|---|---|
| CONFIG_KEXEC=y | The running build includes the legacy kexec_load() interface | Authoritative for build-time support |
| CONFIG_KEXEC_FILE=y | The running build includes kexec_file_load() | Authoritative for build-time support |
| Successful load of a compatible test kernel | The interface is usable under the current runtime policy | Strong, but risky and unnecessary for an initial check |
| A kexec executable exists | Only that userspace software is installed | Not proof |
| ARM64, GKI, root or a recent Android release | Describes the environment, not its kexec configuration | Not proof |
The Linux kernel’s CONFIG_KEXEC option enables the kexec system call; installing kexec-tools cannot add that system call to a kernel built without it.
The upstream Linux kexec Kconfig definitions are the primary reference for these build options. The two interfaces should be reported separately rather than reduced to a vague “kexec supported” answer.
How to check Android kernel kexec support
This procedure uses ADB from Android SDK Platform-Tools 36.0.0 and standard Android shell utilities. A newer Platform-Tools release should produce the same result. Termux can perform the on-device checks, but it does not automatically gain permission to read protected files.
-
Back up the device and keep the test read-only. Save photographs, authenticator recovery information and any files that exist only on the phone. Do not flash, unlock or patch anything for this procedure.
-
Install ADB and authorise the computer. Enable Developer options, turn on USB debugging, connect the phone and accept its RSA authorisation prompt. Run adb devices. The serial number should appear with the state device, not unauthorised.
-
Record the exact running build. Run adb shell uname -a, followed by adb shell getprop ro.build.fingerprint. These values do not prove kexec support; they prevent you from accidentally checking configuration from a different firmware or kernel build.
-
Check whether the running configuration is exposed. Run adb shell ls -l /proc/config.gz. If the file exists, the kernel was built with configuration export support. Its existence says nothing by itself about kexec.
-
Query both kexec options. Run adb shell zcat /proc/config.gz | grep -E "^(CONFIG_KEXEC|CONFIG_KEXEC_FILE)=|^# (CONFIG_KEXEC|CONFIG_KEXEC_FILE) is not set". Enter it in a shell that supports the pipe and quoting shown. You can instead open an ADB shell first and run the zcat and grep portion there.
-
Retry through existing root only if access is denied. On a device that is already rooted, run adb shell, obtain a root shell with su, and repeat the query. Do not root the phone solely for this check. Root cannot make /proc/config.gz appear if the kernel was not built to expose it.
-
Use an alternative configuration source when necessary. Look for /boot/config-$(uname -r), although this layout is uncommon on Android. A custom-kernel maintainer may also publish the exact generated configuration for a named build. Match the kernel release, build identifier and device; a generic defconfig is only a build recipe, not proof of what is running.
-
Extract the configuration offline if no live copy exists. Download the official factory image or full firmware package matching the recorded build. Extract its boot.img, then unpack the kernel payload with AOSP’s official boot-image tools. Run the Linux kernel extract-ikconfig script against the extracted kernel and search the resulting text for both options. This reads the image; it does not require flashing it.
-
Verify the conclusion against the exact build. Save the relevant configuration lines alongside uname -a and the Android build fingerprint. If the kernel changes after an OTA update, custom-kernel installation or ROM update, repeat the check because the answer may change.
The relevant utilities and companion files, where supplied with this guide, are collected in the “Modules, apps & files to try” section. You need ADB or Termux for inspection; kexec-tools is not required merely to read the configuration.
How to interpret the result
| Configuration result | Conclusion |
|---|---|
| CONFIG_KEXEC=y | The legacy kexec loading system call was compiled into this kernel. |
| CONFIG_KEXEC_FILE=y | The file-based kexec loading system call was compiled into this kernel. |
| Both options are y | Both build-time interfaces are present, subject to runtime restrictions. |
| # CONFIG_KEXEC is not set | The legacy interface is absent from this build. |
| # CONFIG_KEXEC_FILE is not set | The file-based interface is absent from this build. |
| Neither option appears | Do not assume support. Confirm that the configuration is complete and belongs to the running kernel. |
CONFIG_KEXEC_CORE=y alone is not sufficient evidence that a userspace loading interface is available. Likewise, options concerning crash dumps, signatures or image verification modify related behaviour but do not replace the two primary checks.
The decisive lines are CONFIG_KEXEC and CONFIG_KEXEC_FILE, not similarly named helper options.
Why Android GKI does not guarantee kexec
GKI, or Generic Kernel Image, standardises parts of Android’s kernel interface and makes more vendor functionality modular. It does not require manufacturers to enable kexec.
In the Android 16 android16-6.12 ARM64 GKI defconfig checked on 23 July 2026, /proc/config.gz access is enabled while CONFIG_KEXEC and CONFIG_KEXEC_FILE remain disabled.
The current Android 16 ARM64 GKI defconfig is therefore a useful counterexample: a modern ARM64 GKI kernel can expose its configuration while providing neither kexec loading interface. An OEM kernel or custom kernel derived from the same Android branch may change those settings.
A defconfig is also not necessarily the final configuration. Build fragments, vendor settings and dependency resolution can alter the result. Inspecting the generated configuration from the installed image remains the stronger method.
Root managers do not prove kexec support
Magisk, APatch, KernelSU, KernelSU Next and SukiSU Ultra use different approaches to privilege and kernel modification. None of their manager apps proves that either kexec system call exists.
- Magisk generally patches a boot or init_boot image and provides userspace-oriented root facilities. Its presence does not enable a missing kernel option.
- APatch uses kernel patching and supports Kernel Patch Modules, but an APatch-compatible kernel is not automatically kexec-capable.
- KernelSU and its forks integrate at kernel level. A kernel built for KernelSU may still leave both kexec options disabled.
- Loadable kernel modules cannot be assumed to create an omitted architecture system call safely. Enabling kexec normally requires building and booting an appropriately configured kernel.
Switching root managers purely to obtain kexec is unnecessary and can introduce boot failures, lost root, module conflicts and app-detection changes. If you are considering kernel modification more broadly, read PrivacyPortal’s practical Android rooting guide before changing the installed boot image.
Build-time support does not guarantee a working kexec boot
An enabled configuration establishes that code was compiled, not that every replacement kernel can be loaded and started. In practice, failures often come from:
- SELinux, seccomp or another Android security policy blocking the caller;
- kernel lockdown or signature requirements rejecting an unsigned image;
- a kexec-tools build using the wrong interface or architecture;
- missing or incorrect device-tree data for the phone’s hardware;
- an incompatible kernel command line, ramdisk or memory layout;
- vendor drivers leaving hardware in a state the next kernel cannot recover from;
- using an image intended for another device, firmware revision or partition layout.
The kexec_load() and kexec_file_load() system calls are separate interfaces, so success or failure with one does not establish the state of the other.
The kexec_load system-call documentation explains their different inputs and error conditions. An “operation not permitted” result can mean missing privilege or a security-policy restriction; it is not automatically evidence that the kernel option is disabled.
Common mistakes that produce the wrong answer
- Checking uname only: the kernel release string does not encode all configuration options.
- Trusting a compatibility app: an app may infer support from architecture or known device data rather than inspecting the installed build.
- Finding a kexec binary: userspace tools can be copied onto a kernel that lacks the required system calls.
- Using another owner’s config: two phones with the same model name can run different regional, OTA or custom-kernel builds.
- Reading only CONFIG_KEXEC: the file-based interface must be checked separately.
- Treating permission denied as disabled: Android may restrict access to configuration files even when they exist.
- Flashing to test: configuration inspection can answer the initial question without risking the installed system.
Record the build fingerprint with every saved configuration so an OTA cannot silently invalidate the result.
Should you install a custom kernel to enable kexec?
Only consider a custom kernel if it explicitly supports your exact device, Android build and intended kexec use. Enabling the configuration option is the easy part; preserving verified boot behaviour, vendor-driver compatibility, device-tree accuracy and safe recovery is harder.
Before flashing, confirm that stock images and the correct recovery procedure are available. Unlocking the bootloader wipes data, and relocking with modified or mismatched partitions can brick a device. Custom kernels can interrupt OTA installation and alter Play Integrity results. PrivacyPortal’s Android bootloader guide explains the trust and recovery implications before you make that decision.
For readers who want a privacy-first phone without maintaining custom boot components, PrivacyPortal’s privacy-focused Android phones provide a supported alternative. Kexec is a specialist requirement rather than a prerequisite for a private Android setup.
Frequently asked questions
Can I check Android kernel kexec support without root?
Yes, when /proc/config.gz is readable or when you can obtain the exact installed kernel image from an official firmware package. Root may help access a protected configuration, but it does not change which kexec options were compiled into the kernel.
Does CONFIG_KEXEC=y mean kexec will definitely work?
No. It confirms build-time support for the legacy interface. Privileges, SELinux, lockdown, signatures, device-tree data and replacement-kernel compatibility can still prevent loading or booting.
What is the difference between CONFIG_KEXEC and CONFIG_KEXEC_FILE?
CONFIG_KEXEC enables the traditional interface in which userspace supplies kernel segments. CONFIG_KEXEC_FILE enables a newer file-descriptor-based interface that allows more loading and verification work inside the kernel. Check both because a tool may use one specific interface.
Does an installed kexec-tools binary prove support?
No. Kexec-tools is userspace software. It can exist even when the running kernel was compiled without either loading interface. The kernel configuration is the authoritative initial check.
Will rooting or installing KernelSU enable kexec?
Not by itself. Root grants privilege, while KernelSU integrates root functionality with the kernel. Neither proves that CONFIG_KEXEC or CONFIG_KEXEC_FILE was enabled. Installing a separately built kernel may change those options, with the associated flashing and compatibility risks.
Do I need to run kexec to verify support?
No. Read the configuration first. Attempting to load or execute another kernel adds risk and tests more than build-time support. If you later perform a runtime test, use device-specific documentation, maintain a recovery route and never experiment on a phone containing the only copy of important data.
PrivacyPortal sells ready-to-use, de-Googled GrapheneOS Pixels — hardened, kept updated, and shipped with our encrypted Graphite messenger. Browse privacy phones →
