Android の「Muting recently noisy」ログは通知チャンネルの話じゃない

  • Android
  • Logcat

この記事は、構成と文章の整理にAIを使っています。
あくまで読みやすくするための補助で、内容そのものをAIにすべて任せて書いているわけではありませんが、ところどころ相談しながら整えています。

Logcatで見かける以下のエラーログについて、通知チャンネルが原因になっている、という説明を見かけたので中身を確認した。

E NotificationService: Muting recently noisy 0|com.example.app|16|null|10011

ログの中身

| 区切りの部分は userId|パッケージ名|notification id|tag|uid という並び。今回の例だと以下の意味になる。

  • 0: ユーザーID（マルチユーザー端末での識別子。通常端末なら0）
  • com.example.app: 通知を送っているパッケージ名
  • 16: notify() を呼ぶときに指定する notification id
  • null: tag（未指定ならnull）
  • 10011: そのアプリのUID

これは通知チャンネルのIDではない。NotificationManager.notify(tag, id, notification) で識別される、個別の通知インスタンスを指すキーになっている。通知チャンネル（NotificationChannel）とは別の概念。

何をしているログか

これは NotificationManagerService 内のレート制限処理のログで、短時間に大量の通知を出しているアプリに対して、システムが個々の通知のアラート（音・バイブ・ヘッズアップ表示）を一時的に間引いている、という内容。実機のログでは直後にこういう行が続くことが多い。

E NotificationService: Package enqueue rate is 5.6. Shedding 0|com.example.app|16|null|10011. package=com.example.app

enqueue rate がしきい値を超えたパッケージの通知を間引いている、というのがそのままの意味。

アプリ側の対応

原因はアプリが短時間に通知を出しすぎていること。対応としては以下が有効。

  • 同一内容の通知を短時間に連投しない（id/tag を使って更新にまとめる）
  • 重要度の低い通知はそもそも送らないか、IMPORTANCE_LOW 以下のチャンネルに寄せる
  • 通知の重要度に応じてチャンネルを分ける（緊急系と情報系を分離するなど）

通知チャンネル自体はこの問題と無関係ではなく、重要度設定として使うのは正しい対策の一つではある。ただしログに出ているキーそのものが通知チャンネルを指しているわけではない、という点は分けて理解しておく必要がある。