The screenrecord shell utility has been built into Android since KitKat, and it captures screen video with no app install, no watermark, and no permission prompt beyond USB debugging itself. It is the tool QA testers and bug reporters reach for when a screenshot cannot show what actually happened — a dropped frame, a gesture that misfires, a crash that only appears mid-animation.
With the device connected and authorized, run:
adb shell screenrecord /sdcard/demo.mp4Recording starts immediately and continues until you press Ctrl+C in the terminal, the device reaches its 180-second default limit, or storage runs low. There is no on-screen indicator during recording on most Android versions, so it is easy to forget it is running — the terminal staying "stuck" with no output is normal, not a sign of failure.
Three flags control the output beyond the default settings:
--time-limit SECONDS — overrides the 180-second cap, up to a hard ceiling of 180 seconds on older Android versions or effectively unlimited on newer ones where the cap was relaxed. If you need longer footage on an older device, record in multiple segments and concatenate them afterward.--size WIDTHxHEIGHT — scales the output resolution down from native, which reduces file size significantly. A phone with a 1440p panel recorded at native resolution produces a much larger file than the same session recorded at 1080x1920.--bit-rate RATE — sets the encoding bitrate in bits per second. The default is 4Mbps (4000000), which is adequate for UI review but visibly compresses fast motion or fine text. Raising it to 8000000 or higher noticeably improves quality for demo videos at the cost of file size.A common combination for a clean demo recording:
adb shell screenrecord --size 1080x1920 --bit-rate 8000000 --time-limit 60 /sdcard/demo.mp4The recording is written to the device's internal storage, not your PC, so it needs to be pulled over afterward:
adb pull /sdcard/demo.mp4 .This copies the file to the current directory on your PC. Delete the on-device copy afterward with adb shell rm /sdcard/demo.mp4 if you are recording repeatedly and do not want old captures cluttering the device's storage.
Pressing Ctrl+C in the terminal sends a signal that screenrecord handles gracefully, finalizing the MP4 container so the file plays correctly. Killing the ADB connection outright (unplugging the cable, for example) instead of stopping the process cleanly often leaves a corrupted or unplayable file, because the MP4 header is only finalized on a clean exit.
screenrecord captures video only; it does not record system audio or microphone input. This is a deliberate platform limitation rather than a missing flag — Android does not expose a system-audio capture API to shell commands for privacy and DRM reasons. If audio matters for the recording, screen-record with screenrecord and separately capture audio through another channel, then merge the two afterward on the PC.
By default, screenrecord locks to the device's orientation at the moment recording starts and does not rotate the output if you turn the device mid-recording; the video will show sideways content rather than automatically re-orienting. Use the --rotate flag on Android versions that support it, or simply start the recording in the orientation you intend to demonstrate to avoid the issue entirely.
Screen recording apps installed from the Play Store add their own overlay, watermark, or in some cases ads, and require granting broad permissions. For a one-off bug capture to attach to an issue tracker, screenrecord avoids all of that: no install, no persistent background service, and the output is a standard H.264 MP4 that opens in any player.
Adding --verbose prints diagnostic information as the recording runs, including dropped frame counts if the encoder cannot keep up with the requested bitrate and resolution combination:
adb shell screenrecord --verbose /sdcard/demo.mp4A high dropped-frame count usually means the bitrate is set too high for the device's hardware encoder, or the CPU is under heavy load from whatever app is being recorded. Lowering the bitrate or resolution is the usual fix rather than assuming the recording itself failed, since a dropped-frame video is still playable, just less smooth than intended.
Since the output is essentially raw bitrate multiplied by duration, a rough size estimate is straightforward: an 8Mbps recording for 60 seconds produces roughly 60 megabytes, since bitrate is measured in bits, not bytes, and there is an 8-to-1 conversion between the two. This matters when a device is close to running out of storage, or when the recording needs to be emailed or uploaded afterward rather than kept only locally — a long recording at a high bitrate can easily produce a file too large for some upload limits without you realizing it until the transfer fails partway through.