# getActivity/Toaster: an Android Toast wrapper for Android 7.1 to Android 11

> Toaster is a 34 KB Android library that wraps the platform Toast to fix crashes and silent failures across Android versions. It is for Android developers who ship toasts from background threads, custom layouts or server-driven messages.

**getActivity/Toaster** — Android 吐司框架，专治 Toast 各种疑难杂症

- Repository: https://github.com/getActivity/Toaster
- Stars: 3,514 · Forks: 429
- Language: Java
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/getactivity-toaster

## The Android Toast problems Toaster was written to absorb

The platform Toast API looks trivial and behaves differently on almost every Android release. Toaster exists to hide four of those differences behind one static facade. The first is a crash on Android 7.1: the README explains that Android 7.1 added a WindowToken check, the token comes from NotificationManagerService and expires, and when the app main thread is blocked, WindowManager validates the token during addView and throws. Google fixed this in Android 8.0 by catching the exception; Toaster cannot patch the framework, so it hooks the exception instead. The second is silent suppression: NotificationManagerService carries a static final boolean ENABLE_BLOCKED_TOASTS = true, and when that is true the service checks the app notification permission and drops the toast, logging Suppressing toast from package. The README notes that some Xiaomi builds set the flag to false, which is why the bug is device-dependent. The third is the Android 11 rule that a toast with a custom view cannot be shown while the app is in the background, a behaviour the official Toast documentation acknowledges by deprecating Toast.setView. The fourth is ordinary ergonomics: calling from a background thread, queueing, delaying, and knowing which line of code fired the toast. If none of those apply to your app, you do not need this library.

## How Toaster decides between a custom window, a hook and a system toast

The interesting part of the design is the branch taken at show time, and the README describes it directly. For the notification-permission problem, the library first checks whether the app is in the foreground. In the foreground it bypasses Toast entirely and renders through its own WindowManager. In the background it hooks the INotificationManager interface inside Toast and rewrites the package name passed to enqueueToast to android, because NotificationManagerService whitelists that package. The README is explicit that this hook stopped working on Android 10, where the reflection path is blacklisted, and that the foreground half of the problem was fixed in Android 10 anyway, so the hook is only attempted on Android 9.0 and below with the notification permission disabled. For Android 11, the branch is the reverse: in the foreground a custom layout is used, in the background the library falls back to the system style, trading customisation for the toast actually appearing. A single IToastStrategy decides queueing and immediate display, IToastStyle controls the view, and an IToastInterceptor can veto a toast before it renders. That interceptor is the extension point worth knowing about, because it lets you suppress toasts in release builds or rewrite text centrally without touching call sites.

## Installing Toaster from JitPack and showing your first toast

The library is not on Maven Central; the README routes it through JitPack. On Gradle 7.0 and above the repository goes in settings.gradle, and on older Gradle it goes in build.gradle inside allprojects. Then the app module gets Java 8 compatibility plus the dependency, and Application.onCreate calls Toaster.init.

```groovy
dependencyResolutionManagement {
    repositories {
        // JitPack 远程仓库：https://jitpack.io
        maven { url 'https://jitpack.io' }
    }
}
```

```groovy
android {
    // 支持 JDK 1.8
    compileOptions {
        targetCompatibility JavaVersion.VERSION_1_8
        sourceCompatibility JavaVersion.VERSION_1_8
    }
}

dependencies {
    // 吐司框架：https://github.com/getActivity/Toaster
    implementation 'com.github.getActivity:Toaster:15.0'
}
```

```java
public class XxxApplication extends Application {

    @Override
    public void onCreate() {
        super.onCreate();

        // 初始化 Toast 框架
        Toaster.init(this);
    }
}
```

The README's API list gives the calls you will use most: showShort, showLong, delayedShow and cancel, each overloaded on a text, a string resource id, or an object. debugShow behaves like show but only in debug builds. The README also states that the framework logs the source location of each call, so clicking the log line jumps to the class and line that triggered it. That matters when the toast text arrives from a server and you have no obvious call site to inspect.

```java
// 显示短 Toast
Toaster.showShort(CharSequence text);

// 显示长 Toast
Toaster.showLong(CharSequence text);

// 延迟显示 Toast
Toaster.delayedShow(CharSequence text, long delayMillis);

// 取消 Toast
Toaster.cancel();
```

## Global styling, interception and the cost of both

setView and setStyle are global, which is convenient and also the sharpest edge in the API. A global style is applied by the strategy at show time, so a library module or a third-party SDK that changes the style will change every toast in the process. If two modules disagree, the later call wins and there is no per-call override except the ToastParams overload. The interceptor has the same shape: it is global and single-valued, so it is fine for a project-wide policy such as dropping toasts in release builds, and awkward for anything scoped to one screen. The README gives no documented way to remove an interceptor other than setting another one, and it does not describe a reset for style or strategy, so treat these as process-wide configuration to be set once during startup rather than adjusted at runtime. This is a deliberate simplification, not an oversight, but it pushes discipline onto the caller.

## Where Toaster is the wrong tool

The library cannot make a background toast appear on every device. The README says so plainly: on Android 10 and later, if you need a toast in the background, the notification permission or the overlay permission must be enabled, and if you need it 100 percent of the time in the background, the overlay permission is required, because some vendor builds refuse even with the notification permission. The README cites a HarmonyOS 2.0 test where the notification permission was not enough. So if your product requirement is guaranteed background feedback, a toast is the wrong primitive and a notification is the right one. The second boundary is Android 11 and later with a custom layout: in the background the library silently substitutes the system style, which means your carefully designed view simply does not appear and nothing throws. If a branded background toast is a hard requirement, Toaster will not deliver it. Third, the Android 7.1 fix is a hook, and hooks are the first thing to break on a new OEM build; the README does not describe a fallback if the hook fails, which is worth knowing before you rely on it.

## Toaster against AndroidUtilCode ToastUtils and Toasty

The README carries a comparison table against AndroidUtilCode's ToastUtils (1.30.6) and Toasty (1.5.0). The size difference is the least interesting column: 34 KB against roughly 500 KB and 50 KB. The real split is scope. AndroidUtilCode is a general utility collection, so pulling it in for toast handling means carrying the rest of the library, and the README marks it as no longer maintained. Toasty is a toast-specific library with queueing support but, per the table, no background-thread calls, no local or global style setting, and no handling of the Android 7.1 crash, the notification-permission suppression or the Android 11 background rule. Toaster covers all of those and adds delayed display, which neither alternative lists. If you only need a queue, Toasty is smaller in concept; if you are already using AndroidUtilCode for other utilities, its ToastUtils may be good enough and you avoid a second dependency. The comparison is the project's own, so treat the feature ticks as claims to verify against the versions you actually resolve.

## Licence, releases and what upgrading costs

Toaster is Apache-2.0, which permits commercial and closed-source use and requires that you retain the licence and notice files; this is a description of the licence text, not legal advice, and you should read the LICENSE file in the repository for the terms that bind you. Because distribution is through JitPack, the version string in your build file is the release number, and the README pins 15.0 in its example, so an upgrade is a one-line change plus a rebuild. The repository layout is a standard Gradle setup with app/ for the demo and library/ for the code, so you can also vendor the library module if you want to patch a hook yourself. The last push was on 2026-04-10, and the releases listed are 13.6, 13.8 and 15.0, with the most recent on the same date as the last push. There is no published deprecation notice in the README, and no migration guide for the 13.x to 15.0 jump, which means a version bump should be validated by exercising the toast paths you actually use rather than assumed to be source-compatible.

## Conclusion

Adopt Toaster if your app targets Android 7.1 through 11 and you have hit the WindowToken crash, the suppressed-toast log line, or the Android 11 background rule with a custom layout. Do not adopt it if you only need a one-line wrapper around Toast.makeText and never customise the view; the platform API is enough. Before adding the dependency, verify that your app module compiles against Java 8, that JitPack resolves in your repository configuration, and that you are willing to call Toaster.init in Application.onCreate.

## FAQ

### How do I install getActivity/Toaster in an Android project?

Add the JitPack repository to settings.gradle for Gradle 7.0 and above, or to build.gradle for older Gradle, then add implementation 'com.github.getActivity:Toaster:15.0' to the app module dependencies and set Java 8 compatibility.

### How do I use Toaster to show a toast from a background thread?

Call Toaster.init(this) in Application.onCreate, then use the static methods such as Toaster.showShort, Toaster.showLong or Toaster.delayedShow. The README's comparison table lists background-thread calls as supported.

### Why does my custom Toaster layout not appear on Android 11?

Android 11 forbids custom toast views while the app is in the background, and the README states that Toaster falls back to the system style in that case, so the custom view is dropped rather than shown.

### Does getActivity/Toaster work if the app notification permission is disabled?

The README says the library checks whether the app is in the foreground and renders through its own WindowManager if so, and on Android 9.0 and below it hooks INotificationManager to bypass the permission check; that hook no longer works on Android 10.

### What licence does getActivity/Toaster use?

The repository is Apache-2.0, so commercial and closed-source use is permitted provided the licence and notice files are retained. Read the LICENSE file in the repository for the binding terms.

## Sources

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

---

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