Is there any limit on the number of notifications the android app can display? I am facing an issue after 24 notifications android notification does not appear.
There is no documentation which states this clearly.
This issue I have observed in Android 11. Looks like this is applicable to android 10 (https://support.google.com/pixelphone/thread/23619509?hl=en). I don't have android 10. So, I have not tested.
Please help me to get a documentation reference for this limit or this behavior can be changed using the settings of the device.
Yes, there is a limit of notifications that can be posted per app. The interesting thing was the number is not fixed and can be controlled by the Device Manufacturer. From my observation, a Google Pixel 3A phone had limited to 25 notifications were as an OnePlus 6T and a Samsung device had limited the notifications to 50.
If we carefully observe the NotificationManagerService.java source code, we can see a variable MAX_PACKAGE_COUNT declared to be 50.
And inside the code, it checks if the count is greater than the MAX_PACKAGE_NOTIFICATIONS, it has a message saying that “Package has. already posted max toasts. Not showing more!”
This is the reason we get limited by the number of notifications that are posted per app.
The number of notifications for a particular application has been set to 50 which is a default value set in notification manager. But more on that, the device manufacturer can also set this limit on their own.
Problem : Now the problem is that we can not change this number as it is not accessible to us or even visible.
Solution : If we want that our application delivers notifications continuously, we need to change a little bit of code in our application.
We have to clear the previous notifications which are not needed.
For that we can set Notification.builder.
NotificationCompat.Builder builder = new NotificationCompat.Builder(...);
builder.setContentTitle(...);
builder.setContentText(...);
builder.setTimeoutAfter(5000);
builder.setTimeoutAfter(5000);
The above line will auto-clear notifications after 5 seconds of notification arrival.
So newer notifications can be pushed by your application.
References : 1. Notification builder
2. builder.setTimeOutAfter();
Related
Android Api level 31 introduces 2 new Categories CATEGORY_WORKOUT, CATEGORY_STOPWATCH. I tried to find a detailed information about those but nothing detailed is documented.
https://developer.android.com/reference/android/app/Notification
Is there any advantage of using those for a workout or stopwatch application? earlier I was using Category Progress which is claimed to keep as long running task. I suppose that Android gives it priority.
These categories are for ongoing notifications either on your phone or on a WearOS device.
The category will help the OS prioritize the importance of the notification.
There is an example of the usage in this Edge Wear OS ongoing activity walkthrough: https://developer.android.com/codelabs/ongoing-activity
Can anyone suggest an Action (intent) which an Android 8.1.0 system should broadcast to registered receivers when changing Notification Channel setting values? Some years back, we did the work to update our notifications system into the required channels and groups and specified a broadcast receiver for the settings changes in the manifest (later on we had to fix that when they took away implicit intents, so now it registers in code too - but that's fixed already). Our receiver sets internal "display" settings which correspond to the notification-channel setting chosen by the user into our sharedpreferences file. That's what controls the display of the content when a user actually opens the app.
I have notes that say we tested this on Android 8, but the actions/intents we registered for don't exist until API28. I'm unclear on how this ever passed on the 8.1 devices, but maybe we were focused on the notifications only and didn't notice the display. So right now, we're stuck with notification settings changes working, but if a user happens to go to the app for something else, they still see messages they expected to be hidden.
Android 9+ notification settings changes work fine all the way through because the broadcast receiver registers for the new-in-API-28 NOTIFICATION_CHANNEL_BLOCK_STATE_CHANGED, ACTION_NOTIFICATION_CHANNEL_GROUP_BLOCK_STATE_CHANGED and ACTION_APP_BLOCK_STATE_CHANGED and these get delivered fine when a user changes settings, since I can see the receiver runs and sets the preferences as we want.
Just to debug this, I registered our BroadcastListener for a few extra intents (basically everything that looked like it might have something to do with notifications!) - like this:
// Register to receive a broadcast whenever notification settings are changed (before API 26 this was done by specifying in AndroidManifest only,):
notificationSettingsReceiver = new NotificationSettingsBroadcastReceiver();
IntentFilter filter = new IntentFilter(NotificationManager.ACTION_NOTIFICATION_POLICY_ACCESS_GRANTED_CHANGED);
filter.addAction(NotificationManager.ACTION_NOTIFICATION_POLICY_CHANGED);
filter.addAction(NotificationManager.ACTION_INTERRUPTION_FILTER_CHANGED);
filter.addAction(NotificationManager.ACTION_NOTIFICATION_CHANNEL_GROUP_BLOCK_STATE_CHANGED);
filter.addAction(NotificationManager.ACTION_NOTIFICATION_CHANNEL_BLOCK_STATE_CHANGED);
filter.addAction(NotificationManager.ACTION_APP_BLOCK_STATE_CHANGED);
this.registerReceiver(notificationSettingsReceiver,filter);
This proved that the code in my BroadcastReceiver is working fine in 8.1.0 if it would only get called; I can force it to run by changing a few Notification settings (disabling them, or changing the sounds, etc) and then switching the phone into do-not-disturb mode. The actual notification-settings-changes don't ever cause any intent to arrive at my receiver, but the DND change does, so this triggers the notification settings to get written into sharedpreferences (which is where our display code is expecting to find them).
Pre-android 8 notification settings still seem to work fine too and we write these changes into our sharedpreferences file directly. Something about compatibility must just handle this for us because it all still "just works" on API 23 devices.
If anyone could suggest a way for an API 27 device to listen for notification-channel settings changes, I would be most grateful! There has to be a way to to this in API 27, isn't there?
After a few days of looking around and trying things, I was unable to have the NotificationManager in API 27 send anything at all to our BroadcastReceiver.
I was able to come up with a solution, although at first it seemed a bit heavy-handed.
For Android O+ devices, I simply added the same "syncPreferences" block of code to our app's onCreate, onResume and onDestroy methods which calls the same function as our BroadcastReceiver (which works fine in API 28+) to write the values into our shared_prefs file at that time. I say "heavy-handed" since it does it every time, regardless of whether anything has changed, but it actually works very well. It's actually simpler than all the overhead of building a receiver and listening for notification changes... I could probably eliminate that whole process now!
As an amusing aside, as a trekker, I have to admit that I got quite a chuckle from whoever adds the android VERSION_CODES constants though! Check the comment I found while looking up API numbers-to-buildcode declarations:
/**
* Q.
* <p>
* <em>Why? Why, to give you a taste of your future, a preview of things
* to come. Con permiso, Capitan. The hall is rented, the orchestra
* engaged. It's now time to see if you can dance.</em>
*/
public static final int Q = 29;
Some users are reporting on Huawei EMUI 8.0 Oreo that the Notification Channel does not have the option to change tone "Sound" / "Notification Tone" from the app!
As of the official docs the developer can't change the settings anymore.
So how can I add an option for Huawei phones to change the "Notification Tone" again?
And does anyone know why the hell Huawei removed this feature?
I don't find official docs from Huawei how we can now let the user change the notification tone.
Offical docs I am referring:
https://developer.android.com/reference/android/app/NotificationChannel.html
https://developer.android.com/reference/android/app/NotificationChannel.html#setSound(android.net.Uri, android.media.AudioAttributes)
We ran into the same issue recently.
It is not a nice solution, but WhatsApp is doing the same.
Basically we show a ringtone selection inside our app and then delete and recreate the notification channel with a new channel id and the selected ringtone uri. You can copy most settings made to the channel to the new one except 'do not disturb'.
Like I said it is not a nice solution and I don't know what will happen if the channel is recreated a lot. But hopefully the ringtone is not changed too often.
Note: The notification settings screen displays the number of deleted channels, as a spam prevention mechanism.
Faced with same issue on chinese devices. Firstly, i have same solution like describe #Devenias. How it works in system: when you're defining a new channel, NotificationService save this channel in xml, after you changed it, it still contains in this xml. So on a new change of channel, NotificationService will check if it have a channel with a same name, and just retrieve it. So i make new channel with a new settings all the time, when user change vibration or ringtone in app. Also it works like a cache, just make unique channel name for pair<ringtone, vibration>. This solution is pretty hacky, since it works good on Honor's, Huawei's, Samsung's devices and Xiaomi Mi A1, but it have been crashing NotificationService with NullPointer in SystemUI on Xiaomi Mi Mix 2 (device make soft reboot, if SystemUI service crashed), so don't use this solution.
So nowadays a safe workaroud is to play sound and vibration manually.
I would like to have number badges on my application Icon set with a LocalNotification (ie: how many items are still unread in the app after the last session). I set a local notification to test this behavior using the following code and on Android, all I get is a top-bar notification with the number 10 in it, but no badge:
LocalNotification n = new LocalNotification();
n.setId("updatedLearnableCountBadge");
n.setBadgeNumber(10);
Display.getInstance().scheduleLocalNotification(
n,
System.currentTimeMillis() + 1000, // fire date/time
LocalNotification.REPEAT_NONE // Whether to repeat and what frequency
);
Is Badging on Android not implemented yet, or am I doing something wrong?
LocalNotificaiton doesn't mention any special conditions required to make the "setBadgeNumber" display properly, but are there some undocumented platform-specific conventions I'm not following here?
As far as I know Android itself doesn't support badging. It's a feature of iOS which we exposed due to user requirement but it can't be implemented outside of iOS to my knowledge.
I would like to know which users have uninstalled my application so that I can ask them for a feedback to improve the app. Hence, I would like to detect when the user has initiated the uninstallation process on my app.
One of the older solutions on StackOverflow had the following steps:
List< ActivityManager.RunningTaskInfo > taskInfo = am.getRunningTasks(MAX_PRIORITY);
String activityName = taskInfo.get(0).topActivity.getClassName();
if (activityName.equals("com.android.packageinstaller.UninstallerActivity")) {
// do whatever is needed
Since Lollipop, getRunningTasks has been deprecated. So how can com.android.packageinstaller.UninstallerActivity activity be detected without getRunningTask?
Alternatively is there any other method to detect uninstallation process has been started on my app? Using getAppTask probably?
Apparently you wont be able to do this, you will have to rely on something called silent notification.
What we did was we sent notification every 3 days or whatever frequency you want.
On the client side as soon as a notification is received we hit a network call which mark NotificationReceived for the client. Now since notification are not full proof we assumed a threshold of 2/3 missed notification as uninstall event. And for the client we have this counter above decided threshold we contacted them for feedback.
Also no one will be willing to fill your form at the time of uninstallation as user has already decided to uninstall your application.
Read these 2 questions and answers:
native solution
GCM solution
As I know you have to mix the two. Read the limitations of first solution. You have to confirm uninstallation event of the first solution with the second solution for a complete implementation.
Hopefully, this solution will work for you. It helps you understand the reasons for your app uninstalls, reduce the uninstall rate using a powerful predictive engine and also get app Re-installs through a unique actionable channel (Android version 4.0 and above).
Just set a variable named appLastPresent for every user in the server-side and update that variable every day by calling an API using WorkManager's PeriodicWorkRequest. Also set installedDate variable when the user installs the app.
Now set up a chron job on the server side to check if the difference between installedDate and appLastPresent is greater than 7 days. Then send the user an email or message enquiring for issues or feedback, if it is greater.
NB: User can be offline for 7 days. Therefore only send email enquiring like why you are not using the app, if uninstalled please let us know why