Home » Android » android – NotificationManager failing to display notification with "notify: id corrupted: sent 1, got back 0" warning

android – NotificationManager failing to display notification with "notify: id corrupted: sent 1, got back 0" warning

Posted by: admin June 15, 2020 Leave a comment

Questions:

I’ve had a problem with NotificationManager in my app for the past couple of days and I don’t seem to be getting closer to solving it.

I have a very simple service which does not do anything at the moment. It is just supposed to display notification:

public class UpdateService extends Service {
private static final String TAG = "UpdateService";
private static int NOTIFICATION_ID = 1;
private UpdateServiceBinder binder = new UpdateServiceBinder();

@Override
public void onCreate() {
        Log.i(TAG, "Service created");
}

@Override
public int onStartCommand(Intent intent, int flags, int startId) {
    Log.i(TAG, "Service started");

    sendNotification(100);

    return Service.START_NOT_STICKY;
}

private void sendNotification(int updatedItems) {
    NotificationCompat.Builder builder = new NotificationCompat.Builder(getApplicationContext())
            .setSmallIcon(R.drawable.icon)
            .setContentTitle("Sync")
            .setContentText("Updated " + updatedItems);

    Intent resultIntent = new Intent(getBaseContext(), MainActivity.class);

    TaskStackBuilder stackBuilder = TaskStackBuilder.create(getApplicationContext());
    stackBuilder.addParentStack(MainActivity.class);
    stackBuilder.addNextIntent(resultIntent);

    PendingIntent resultPendindIntent = stackBuilder.getPendingIntent(0, PendingIntent.FLAG_UPDATE_CURRENT);

    builder.setContentIntent(resultPendindIntent);

    NotificationManager manager = (NotificationManager) getApplicationContext().getSystemService(Context.NOTIFICATION_SERVICE);
    manager.notify(NOTIFICATION_ID, builder.build());
}

@Override
public IBinder onBind(Intent intent) {
    return binder;
}

@Override
public boolean onUnbind(Intent intent) {
    return true;
}

public class UpdateServiceBinder extends Binder {
    public UpdateService getService() {
        return UpdateService.this;
    }
}

}

Unfortunately, when the service is started and the notification is supposed to be displayed nothing happens. The service is definitely started according to log messages. At the same time there is warning from NotificationManager:

11-30 23:24:34.620: I/UpdateService(28356): Service created

11-30 23:24:34.800: I/UpdateService(28356): Service started

11-30 23:24:34.808: W/NotificationManager(28356): notify: id
corrupted: sent 1, got back 0

I tried using different numbers than 1 but it did not help. I am not sure what to make out of it. The code I’m using comes from the Android documentation on service in here and notifications in here. When I isolate the code in separate clean app which is setup in similar way to the one I’m working on notification is displayed correctly. Has anybody had this problem before or has any ideas?

Any help appreciated.
Thanks!

How to&Answers:

I had this problem then I remember that I had disabled the “Show Notification” from my “App info”. I enabled it and notifications are back again.

  1. Go to Settings > Apps (Application Manager).
  2. Tap the app you want to stop.
  3. Tap to uncheck the box for Show notifications.

FYI it might differ from one android device to the other, however they are all more or less the same.

Answer:

Startin from API 25 (Nougat), Android puts rate limiting in place to block apps from DDOSing the notification shade. The commits to AOSP introducing this change can be seen here.

I was seeing these logs on my side because I was trying to update a progress notification inside a loop:

Observable.range(0, 100)
  .subscribe(progress -> updateProgressNotification(progress));

Adding an delay of 200ms between each emission fixes the problem for me:

Observable.range(0, 100)
  .zipWith(Observable.interval(200, TimeUnit.MILLISECONDS), (progress, delay) -> progress)
  .subscribe(progress -> updateProgressNotification(progress));

You can read more about this problem on my blog.

Answer:

I found a solution to this problem. I had to change the package name from com.gttn.sample to com.gttn.sample2. Not really sure why I had to do it but the notifications show properly and the warning disappeared.

Answer:

When you install and reinstall the app many times something

unchecked the “Show Notifications” in Settings > ApplicationManager > “Your app”.

Just check again “Show Notifications” and be happy!

Answer:

I have written code which download the song and update the progress of the download as the progress in the notification. If u see in the line 6 of code ,If that condition is removed then notification is updated very fast as the while loop reads the bytes from the input stream now this causes repeated updates on the notification and this is recognised as the problem starting from noughat verions which keeps the rate limit on the notification update.Hope you got some idea about it.

 int previousPercentage = 0;
 int currentPercentage = 0;
 while ((bytesRead = inputStream.read(bytes)) != -1) {
       totalbytes = totalbytes + bytesRead;
       currentPercentage = (totalbytes * 100) / length_of_file;
       if (previousPercentage != currentPercentage) {// line : 6
        updateProgressNotification(builder, notificationId, currentPercentage);
       }
       previousPercentage = currentPercentage;
       fileOutputStream.write(bytes, 0, bytesRead);
 }

Answer:

I’m not sure why you’re using getBaseContext(), but I suggest you use getApplicationContext() instead. Also, I’m not sure why you’re binding to the Service.

Answer:

just looked into this problem myself. without additional lines from your logfile (should be within 5 lines after) there might be a message similar to “E/NotificationService( 287): Suppressing notification from package by user request.” This is a new setting in ICS (maybe JB) to disable notifications on a per-app basis. Go to Settings –> Apps –> and click the checkbox “show notifications” near the top. for obvious reasons, changing the package name would circumvent this setting very effectively.