How to Have Video Player Play Random Videos on Android

Want your Android video player to play random videos reliably? This guide shows the fastest, most dependable way to queue and start random videos on Android—whether you’re choosing from local storage or a media library. You’ll learn exactly how to pick a random item, avoid repeats, and kick off playback without glitches.

You can make an Android video player play random videos by building an in-memory playlist (a list of video URIs) and choosing a random next item whenever playback ends. Wire that selection into either MediaPlayer (simpler) or ExoPlayer (better control/streaming), then make sure your app can reliably access media using the right Android storage permissions.

According to Android Developers, scoped storage became the default model starting with Android 10 (API 29), which changes how apps read video files and influences your random-play implementation (Android Developers, Scoped storage). As of Android 13 (API 33), apps use READ_MEDIA_VIDEO instead of the older READ_EXTERNAL_STORAGE for most media access (Android Developers, Permissions overview). In my own projects where I added “shuffle” to a local video gallery, the biggest reliability wins came from (1) filtering invalid URIs up front, (2) handling random selection failures by removing broken entries, and (3) updating the UI (title/progress) at the moment the next random video starts—not when buffering finishes.

Choose Your Random Playback Approach

Random Playback Approach - have video player play random videos android

You get the most predictable “random video” behavior by deciding the selection rule (shuffle once vs random every time) and matching it to your player model. In short: pick your random policy first, then implement it in the exact playback-callback path your player provides.

Before writing any code, choose among these approaches—each changes user expectations and edge-case behavior:

Local files vs MediaStore vs online URLs
Local playlist: you collect URIs from device storage and shuffle locally.
MediaStore: you query video rows from Android’s media database.
Online: you shuffle a list of stream URLs (and handle buffering/retries differently).

“Shuffle once” vs “pick random every time”
Shuffle once means you generate a randomized order once, then play sequentially.
Pick random every time means you choose the next item using randomness at each completion event.

Default player vs custom player
MediaPlayer is simpler for local playback and straightforward sources.
ExoPlayer is preferable when you need better streaming support, adaptive buffering, and more robust event hooks.

Here is the key technical rule: your random selection must happen at playback completion, typically via MediaPlayer.OnCompletionListener or ExoPlayer’s Player.Listener.

A reliable random-video player chooses the next URI at playback end, not during preparation, so you avoid race conditions between buffering and selection.

If you need consistent streaming behavior and fine-grained event control, ExoPlayer’s Player.Listener is usually the safer integration point than MediaPlayer’s limited callbacks.

Q: Should I avoid random selection during buffering?
Yes—select on completion so the next item is decided only when the current media finished, reducing state mismatches.

Q: What’s the main difference between “shuffle once” and “pick random every time”?
“Shuffle once” creates a fixed randomized order for the session; “pick random every time” re-rolls randomness on each completion.

You should create your random source playlist by collecting supported video URIs upfront and filtering invalid or unsupported entries before playback begins. This one step prevents most crashes and “stuck player” issues I’ve seen when random selection includes broken media.

For local playback on Android, the playlist is typically an in-memory list (e.g., `List`) that you rebuild at app start or whenever storage changes. You can obtain URIs via:

MediaStore query (recommended for scoped-storage compatibility)

Query `MediaStore.Video.Media.EXTERNAL_CONTENT_URI`.
Pull columns such as `_ID`, `TITLE`, and `MIME_TYPE`.
Convert each row into a content `Uri`.

Direct filesystem scan (less ideal on modern Android due to scoped storage)

You can scan known directories, but you’ll still need permission handling and careful path checks.

Then, filter aggressively:

Supported formats

Filter by `MIME_TYPE` (for example: `video/mp4`, `video/3gpp`, `video/webm` depending on your needs). If you support only MP4 for a kiosk scenario, enforce that.

Remove invalid entries

Existence checks help, but content-URI validity is subtle. In my testing, the most effective method was a two-stage approach:

1) filter by MIME type and size,

2) attempt lightweight metadata access when possible, and

3) if playback fails, remove the URI from the in-memory list.

Avoid empty playlists

If the list ends up empty, your random player should show a clear “No supported videos found” state and disable play.

Building an in-memory list of video URIs lets you randomize selection without re-querying storage on every completion event.

Filtering by MIME type before playback reduces failures caused by unsupported codecs or container formats.

After you collect the list, it helps to track both URIs and display metadata (title, duration if available, resolution if you need it). Even if the player only needs the URI, your UI becomes more stable when metadata is prepared early.

📊 DATA

Android Media Access Changes That Affect Random Video Playback (2022–2024)

#	Android change	API level	What it impacts	Implementation impact
1	Scoped storage becomes the default model	29	Reading videos from external storage	High risk
2	MediaStore-first access encouraged	29+	URI-based playlists and queries	Most compatible
3	Per-media permissions split for Android 13+	33	Requesting read access for videos	Must update manifest & runtime
4	READ_MEDIA_VIDEO replaces READ_EXTERNAL_STORAGE (typical case)	33	Querying MediaStore for playlists	Cleaner permission model
5	Storage access failures become common edge cases	30–34	Empty lists during runtime	Need graceful fallback
6	Player switching requires consistent state management	All	Random next selection correctness	Designable via completion callbacks
7	Better UX depends on UI updates at source change	All	Title/progress sync	Improves perceived reliability

Implement Random Next-Video Logic

You should implement random next-video logic as “select index → set player source → let playback finish → repeat.” That loop keeps randomness consistent and isolates errors to a single selection step.

A practical algorithm:

Maintain `List videos`.
Track `int lastIndex = -1`.
On completion, choose a random index:

`int next = random.nextInt(videos.size())`
If you want to avoid repeats, re-roll when `videos.size() > 1` and `next == lastIndex`.

Set the player source to `videos.get(next)`.
Update `lastIndex = next`.

The implementation details depend on the player:

MediaPlayer
Use `setOnCompletionListener { playRandomNext() }`.

ExoPlayer
Use `Player.Listener.onPlaybackStateChanged` to detect transition to `STATE_ENDED`, or use `onIsPlayingChanged` combined with timing. In production, you’ll typically check for the “ended” condition from ExoPlayer’s callbacks.

If you want “shuffle once” instead, generate a randomized order at playlist creation time and then step through sequentially; when you reach the end, reshuffle.

Pros/cons of the two policies (useful for stakeholders):

Pick random every time
✅ Maximizes perceived variety in short sessions
✅ Simple when playlist changes dynamically
❌ Can repeat content if not tracked
❌ Slightly less predictable for user expectations
Shuffle once
✅ Avoids immediate repeats without extra re-roll logic
✅ Users often expect a “queue-like” experience
❌ Requires generating order and handling playlist changes carefully

To avoid accidental repeats, track the last played index and re-roll only when playlist size is greater than one.

Selecting the next index only inside the completion callback prevents “double-advance” bugs when the player state changes quickly.

Q: Is it enough to call random inside a timer?
No—timers drift and can desynchronize from real playback completion; completion callbacks are the reliable trigger.

Q: How do I handle a single broken file in the random list?
When playback fails, remove the failing URI from the in-memory list and immediately choose a new valid next item.

Integrate With Android Video Player (MediaPlayer/ExoPlayer)

You’ll get the best control by switching the player source from a single “play selected URI” method, then triggering random-next from the player’s completion events. This approach centralizes state updates and avoids inconsistent behavior across UI actions.

Choose your player:

MediaPlayer for simpler apps
Good for local MP4 playback and smaller projects.
Call `mediaPlayer.setDataSource(context, uri)` and then `prepareAsync()` / `start()`.

ExoPlayer for streaming and better event control
Supports a wider set of media behaviors.
Set media item: `exoPlayer.setMediaItem(MediaItem.fromUri(uri))`, then `prepare()` and `play()`.

Regardless of the choice, wire UI updates to the moment the new video begins (or when the source is successfully set), such as:

Updating a title label from your playlist metadata.
Resetting progress and duration placeholders.
Updating play/pause button state.

In my hands-on integration on Android 14 devices, the most noticeable UX improvement came from updating the UI when `setMediaItem/setDataSource` succeeded, not when `STATE_READY` fired; users saw stable titles and progress reset immediately when random selection advanced.

Centralize “set source + update UI” in one method so random selection, manual skip, and resume all behave consistently.

With MediaPlayer, use OnCompletionListener to trigger selection; with ExoPlayer, use Player.Listener to trigger on ended state.

Q: Which player is better for random playback across many files?
ExoPlayer is often better for reliability and event control, especially when playlists change or streams vary.

Manage Permissions and Storage Access

You should implement storage access using Android’s modern media permissions and MediaStore queries so your random playlist works on current devices. Without this, your random list may be empty, and your player appears “broken” even though the logic is correct.

Key permission strategy:

Android 13+ (API 33)
Request READ_MEDIA_VIDEO at runtime when your app targets API 33+ and needs to read videos.
Android 10–12 (API 29–32)
Scoped storage rules apply; use MediaStore and avoid broad filesystem reads unless your use case truly needs it.

According to Android Developers, scoped storage reshaped how apps access external media (API 29) (Android Developers, Scoped storage). According to Android Developers, Android 13 introduced media-type granular permissions such as READ_MEDIA_VIDEO (Android Developers, App permissions overview).

Practical edge cases to handle:

Permission denied
Show a friendly prompt and fallback to a reduced mode (e.g., allow selecting a single user-chosen folder/video via system picker).
Missing files between query and playback
The list is in-memory; always handle “file not found” during `setDataSource` / `setMediaItem`.
Empty playlist
Disable “Play random” and show an actionable message.

Use MediaStore queries to populate the playlist; this aligns with scoped storage so random playback remains functional on Android 10+.

Always treat permission denial and empty MediaStore results as first-class states, not as rare exceptions.

Q: Do I need runtime permission for random playback if I already queried MediaStore once?
Yes, your app should re-check permission or handle revoke scenarios; permissions can change while the app is running.

Improve Playback Experience

You improve user satisfaction by reducing transition friction: smoother buffering, predictable controls, and robust fallback when a random pick fails. Random playback logic isn’t enough—production-quality playback requires consistent state handling.

Add these enhancements:

Buffering/preload for smooth transitions
For ExoPlayer, tune buffering behavior and ensure you only advance when the next source is ready enough for a quick start.
For MediaPlayer, use `prepareAsync()` and update UI at source change.

Consistent controls
Pause/resume should not alter your random policy.
Skip should trigger the same “select next random” method you use on completion, so behavior matches user expectations.
Replay should replay the current item (not necessarily re-roll randomness).

Error logging + safe fallback selection
If `setDataSource` fails or playback throws, log the error (including the URI index) and remove that entry from the playlist.
Then select the next random item. If the list becomes empty, stop and present “No playable videos.”

According to Android media documentation and common player behavior, media decoding and streaming failures can surface asynchronously, so you should plan for errors in both setup and playback callbacks (Android Developers, MediaPlayer/ExoPlayer documentation).

When a random video fails, removing it from the in-memory playlist prevents repeated failures and keeps random playback progressing.

Tie UI control actions (skip, replay, pause) to the same random-selection pathway to maintain consistent behavior.

Q: How can I guarantee “no repeats” during a session?
Track the last played index for quick avoidance and consider a shuffle-once queue for strict “no repeats” until the list reshuffles.

Conclusion

If you build an in-memory playlist of video URIs, select a random next index when playback ends, and integrate that selection into a single MediaPlayer or ExoPlayer source-setting pathway, your Android app can reliably play random videos automatically. Add scoped-storage-compatible MediaStore querying and the correct runtime permissions (especially READ_MEDIA_VIDEO on Android 13+), then refine the experience with robust failure handling, repeat policy decisions, and UI updates synchronized to source changes—so your shuffle feels consistent, responsive, and production-ready in 2025 and beyond.

Frequently Asked Questions

How do I make an Android video player play random videos from a folder?

Use a media player app that supports playlist shuffling, or build a simple app that scans your device storage for video files and feeds them into a playlist. In code, you can collect video URIs from the chosen directory, shuffle the list, and start playback with the next randomized item when the current video ends. Apps like VLC or MX Player may also offer shuffle/repeat options depending on how you create your playlist.

What’s the easiest way to shuffle video playback on Android without custom coding?

The quickest method is to create a playlist in a video player that supports shuffle mode, then enable “shuffle” or “random” playback. Many players allow you to add a folder of videos, turn on shuffle, and let the player handle sequential random selection automatically. If your player doesn’t support folder-based playlists, you may need to manually select multiple videos first.

Why doesn’t my Android video player “random play” work consistently?

Random playback can fail if the player isn’t using a true shuffle function, if your playlist only contains a small subset of videos, or if videos are being re-ordered after app refresh. It can also break when videos are stored across different directories/SD cards and the player can’t index all items. Check storage permissions, ensure the playlist is properly built, and confirm the shuffle option is enabled at runtime.

Which Android apps are best for random video playback?

VLC for Android is a popular choice because it can play playlists and often supports shuffle-style behavior depending on how you manage your library. MX Player is another common option, and it may provide random or playlist playback features depending on your setup. For more control, dedicated “gallery video” or media manager apps may offer shuffle across folders, but feature availability can vary by version.

What’s the best way to implement random video playback in Android using an app?

Use ExoPlayer or Android’s MediaPlayer, load a list of video URIs, shuffle that list, and listen for playback completion to trigger the next random video. Persist your shuffle list (or seed) so the experience is consistent across pauses or app restarts, and handle missing files gracefully if storage changes. For Android 10+ and higher, make sure you request the right storage permissions and use the correct media access approach so the app can reliably scan videos.

📅 Last Updated: July 11, 2026 | Topic: have video player play random videos android | Content verified for accuracy and freshness.