AOSP: printk.devkmsg=on
What BOARD_KERNEL_CMDLINE += printk.devkmsg=on does in AOSP and how it works.
July 3, 2026
AOSP: printk.devkmsg=on
BOARD_KERNEL_CMDLINE is a variable in the AOSP build system used to append parameters to the kernel command line.Adding
printk.devkmsg=on passes that parameter to the kernel at boot time of the built image.BoardConfig.mksh
/dev/kmsg
/dev/kmsg is the interface for directly accessing the kernel log ring buffer (
In Linux 3.5, the ability for userspace processes to
dmesg).In Linux 3.5, the ability for userspace processes to
write to this file and insert messages directly into the kernel log was first introduced.Linux 3.5 Relate patch: kmsg: export printk records to the /dev/kmsg interfacesh
Userspace processes can write messages directly to this file, or read from it to collect a real-time kernel log stream.
How It Works
To prevent kernel log buffer dumps/overruns caused by indiscriminate userspace writes, rate limiting for
/dev/kmsg writes and the printk.devkmsg parameter were added starting from Linux 4.7.Linux 4.7 Relate patch: printk: add kernel parameter to control writes to /dev/kmsgsh
When the same message is repeatedly written from userspace within a short period, it is suppressed and not recorded in the kernel buffer. The printk.devkmsg parameter allows dynamic control over this behavior and permissions.
| Value | Behavior |
|---|---|
on | Allows all userspace writes without rate limiting |
off | Disables userspace writes to /dev/kmsg |
ratelimit | Applies the default rate limit (kernel default) |
Setting it to
on allows Android system processes such as logd, init, and healthd to write messages to the kernel log buffer without rate limiting.Result
- Kernel logs and userspace logs can be viewed on a single timeline in
dmesg. - Userspace messages captured just before a crash or panic remain in the kernel buffer, enabling post-mortem debugging.
- When used with pstore / ramoops, crash logs from just before a reboot can be preserved across reboots.
- Early boot
initlogs (beforelogdstarts) are visible indmesgwithout loss.
For debug builds,
on is the typical choice. For production (user) builds, ratelimit or removing the flag altogether is generally recommended for security and performance reasons.