# Dimezis/BlurView: iOS-style blur for Android Views

> BlurView is an Android library that blurs the content behind a FrameLayout and draws the result as that layout's background. It is built for View-based apps that want a frosted-glass surface without switching to Compose.

**Dimezis/BlurView** — Dynamic iOS-like blur of underlying Views for Android

- Repository: https://github.com/Dimezis/BlurView
- Stars: 4,059 · Forks: 379
- Language: Java
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/dimezis-blurview

## What BlurView actually blurs, and for whom

The library is described as a dynamic iOS-like blur for Android Views. Used as a regular FrameLayout, it blurs its underlying content and draws that blurred result as a background for its own children. The children themselves are not blurred. That distinction is the whole point: a tab bar, a label or a set of controls sits on top of a frosted surface, and the surface is a snapshot of whatever is behind it.

It is aimed at developers working in the Android View system, not Compose. The README positions it against other blurring libraries and states that BlurView and Haze for Compose are the only libraries that use hardware acceleration for View snapshotting with near zero snapshotting overhead. If your screens are XML layouts and custom Views, that is the audience this project was written for.

## The BlurTarget and BlurView pair

Since version 3.0 the usage model changed: you wrap the content you want blurred inside a BlurTarget and pass that target to the BlurView through setupWith(). The target renders normally, and the BlurView takes its snapshot and blurs it. A BlurTarget may not contain a BlurView that targets the same BlurTarget, which prevents a self-referential loop. It may contain other BlurTargets and BlurViews, so nesting is allowed as long as the reference does not point back at itself.

Updates are event-driven. The README states that BlurView updates its blurred content when changes in the view hierarchy are detected, and that it honors position and size changes, including view animation and property animation. It also states that the library never invalidates itself or other Views in the hierarchy and updates only when needed, and that multiple BlurViews can be on screen without triggering a draw loop. That is the main architectural claim against the alternatives it names.

## Why the blur runs on the main thread

The README addresses this directly: blurring on other threads would introduce one to two frames of latency. Keeping the work on the main thread trades parallel headroom for a shorter path to the screen. On API 31 and above the blur is performed on the system Render Thread instead, and the README notes that the code path on API 31+ is now completely different from API below 31, with an explicit instruction to test both.

Below API 31 the library falls back to what the README calls optimized RenderScript Allocations on devices that require certain Allocation sizes, which it says greatly increases blur performance. The scale factor is the knob you adjust here: the README suggests passing a custom BlurAlgorithm and scale factor, and notes that a smaller scale factor on API 31+ gives a more precise blur with less flickering. That is a real trade-off between sharpness and stability, not a free setting.

## Installing BlurView and wiring a first target

Artifacts come from JitPack, and the README says to use release tags as the source of stable artifacts. Add the dependency to your module's Gradle file. The coordinate and version below are copied from the README:

```groovy
implementation 'com.github.Dimezis:BlurView:version-3.2.0'
```

Then wrap the content you want blurred in a BlurTarget and place a BlurView next to it. Anything inside the BlurView is drawn on top and is not blurred:

```xml
<eightbitlab.com.blurview.BlurTarget
    android:id="@+id/target"
    android:layout_width="match_parent"
    android:layout_height="match_parent">
</eightbitlab.com.blurview.BlurTarget>

<eightbitlab.com.blurview.BlurView
    android:id="@+id/blurView"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    app:blurOverlayColor="@color/colorOverlay" />
```

In code, find the target, find the BlurView, and call setupWith() followed by setBlurRadius(). The README uses a radius of 20f:

```java
float radius = 20f;
View decorView = getWindow().getDecorView();
BlurTarget target = findViewById(R.id.target);
Drawable windowBackground = decorView.getBackground();

blurView.setupWith(target)
       .setFrameClearDrawable(windowBackground)
       .setBlurRadius(radius);
```

setFrameClearDrawable() is optional. The README recommends it when your layout has a lot of transparent space and the content comes out with a low alpha after blur, because it draws that drawable at the start of each blurred frame and makes the background opaque. Rounded corners need no custom API: set a rounded drawable as the background, then call setOutlineProvider(ViewOutlineProvider.BACKGROUND) and setClipToOutline(true) on the BlurView so it does not draw outside the corners.

## SurfaceView, TextureView and the blur that will not appear

The clearest limitation is in the README's own list: TextureView can be blurred only on API 31 and above, and everything else that is SurfaceView-based cannot be blurred. That covers VideoView, MapFragment and GLSurfaceView. If your design calls for a frosted panel over a video or a map, this library will not produce it, and no amount of radius tuning changes that.

There is a second failure mode worth planning for. The README warns that the API 31+ path is completely different from the path below 31 and tells you to test both. A blur that looks correct on a modern device can behave differently on older ones, where the RenderScript allocation path applies. The optional frame clear drawable exists precisely because transparent layouts can leave the blurred result semi-transparent, which is the kind of visual bug that only shows up on certain screen compositions.

## BlurView against BlurKit, RealtimeBlurView and Haze

The README names its alternatives and gives a one-line reason for each. BlurKit and RealtimeBlurView are both marked with the same criticism: they constantly invalidate themselves. That is the difference in approach. Those libraries redraw on their own schedule, while BlurView claims to update only when the view hierarchy changes and to leave the rest of the hierarchy alone. If you have several blurred surfaces on one screen, that difference is what decides whether you get a draw loop.

Haze is the Compose counterpart. The README groups BlurView and Haze together as the two libraries that use hardware acceleration for View snapshotting with near zero snapshotting overhead, so the split is not quality but platform: Haze for Compose, BlurView for Views. The README also lists TextureView blur on API 31+ and blurring of Dialogs and their backgrounds as capabilities it supports.

## Licence and the cost of staying current

The project is Apache-2.0, and the README carries the copyright notice for 2025 Dmytro Saviuk. Apache-2.0 permits commercial use and modification under its stated conditions, including preservation of notices and the disclaimer that the software is provided without warranties. That is a summary of the licence text, not legal advice; read LICENSE.md in the repository for the terms that bind you.

The upgrade cost is dominated by the version 3.0 change. The README points to BlurView_3.0.md for key changes, migration steps and what you need to know, and the current usage pattern with BlurTarget is a consequence of that release. Any code written against the pre-3.0 API needs that migration document. Releases are tagged as version-3.x.y, and the README directs you to use those tags as the source of stable artifacts. The last push to the repository was on 2026-07-31.

## Conclusion

Adopt BlurView if you are on the View system, want the blurred surface to follow layout, scroll and animation changes, and can wrap your content in a BlurTarget. Do not adopt it if you need to blur a SurfaceView-based view such as VideoView, MapFragment or GLSurfaceView, since the README states those cannot be blurred, or if you are already all-in on Compose, where Haze is the closer fit. Before committing, check the BlurView_3.0.md migration notes, confirm that your minSdk path and your API 31+ path both behave, and verify the exact JitPack coordinate and version tag you intend to ship.

## FAQ

### How do I install Dimezis/BlurView in an Android project?

Add the JitPack dependency using a release tag, for example implementation 'com.github.Dimezis:BlurView:version-3.2.0'. The README says to use JitPack and release tags as the source of stable artifacts.

### Why does BlurView need a BlurTarget?

Since version 3.0 you wrap the content you want blurred in a BlurTarget and pass it to the BlurView through setupWith(). The target renders normally and the BlurView uses its snapshot for blurring.

### Can BlurView blur a VideoView or a MapFragment?

No. The README states that everything SurfaceView-based, including VideoView, MapFragment and GLSurfaceView, cannot be blurred. TextureView can be blurred only on API 31 and above.

### Why does BlurView do its blurring on the main thread?

The README says blurring on other threads would introduce one to two frames of latency. On API 31 and above the blur is done on the system Render Thread instead.

## Sources

- [Dimezis/BlurView on GitHub](https://github.com/Dimezis/BlurView)
- [Issues](https://github.com/Dimezis/BlurView/issues)
- [License: Apache-2.0](https://github.com/Dimezis/BlurView/blob/master/LICENSE)
- [README](https://github.com/Dimezis/BlurView/blob/master/README.md)
- [Releases](https://github.com/Dimezis/BlurView/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dimezis-blurview