RemoteServiceException: плохое уведомление для startForeground: java.util.ConcurrentModificationException

Question

android.app.RemoteServiceException: Bad notification for startForeground: java.util.ConcurrentModificationException
  at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2204)
  at android.os.Handler.dispatchMessage(Handler.java:108)
  at android.os.Looper.loop(Looper.java:166)
  at android.app.ActivityThread.main(ActivityThread.java:7523)
  at java.lang.reflect.Method.invoke(Method.java:-2)
  at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:245)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:921)

Я получаю этот отчет о сбое уже довольно давно.Похоже, это происходит только на Android 8.0.0.

@Synchronized
override fun toForeground(id: Int) {
    fun action() {
        startForeground(id, builder?.build())
    }
    if (Looper.myLooper() === Looper.getMainLooper()) {
        action()
    } else {
        Handler(Looper.getMainLooper()).post { action() }
    }
}

Каждый канал настроен, и приложение может быть запущено на устройствах Android 8.0.0 и более поздних без каких-либо проблем во время тестирования, за исключением того, что я не могу воспроизвести сбой.

Мне интереснопочему происходит этот сбой и как его исправить.

Заранее спасибо.

Answer 1

Я также случайно сталкиваюсь с этим сбоем на устройствах Android 8.0.0.

Изучая исходный код AOSP, он выглядит следующим образом: http://androidxref.com/8.0.0_r4/xref/frameworks/base/services/core/java/com/android/server/am/ServiceRecord.java#540:

public void postNotification() {
...
} catch (RuntimeException e) {
    Slog.w(TAG, "Error showing notification for service", e);
    // If it gave us a garbage notification, it doesn't
    // get to be foreground.
    ams.setServiceForeground(name, ServiceRecord.this,
            0, null, 0);
    ams.crashApplication(appUid, appPid, localPackageName, -1,
            "Bad notification for startForeground: " + e);
}

Не уверен, чтоСтрока точно в блоке try над этим блоком catch вызывает его, но я предполагаю ошибку в самом AOSP.Работает с уведомлением асинхронно.Так что вероятность того, что приложение обновит свое уведомление, в то время как AOSP также работает с ним, довольно высока.