When removing the last registration ID from a group, the notification_key that was used until now will be removed by Google.
For this reason, I want to know how many devices there are left in the group, so if the last device in the group signs out, I can remove the group from the database.
Since there is no 'get device count' functionality, I want to send a hidden notification (doesn't show up in the notification tray, gets ignored by app), and add the 'success' and 'failure' numbers.
However, I can't be sure whether any of the 'failures' are temporary, so I don't know whether to count them towards the device count.
So far, I haven't been able to reproduce this reply from FCM:
{
"success":1,
"failure":2,
"failed_registration_ids":[
"regId1",
"regId2"
]
}
which they claim is supposedly possible: https://firebase.google.com/docs/cloud-messaging/android/device-group .
So... two questions: How can I reproduce that reply, and should I count the 'failures' towards my device count per group?
Things I've tried that didn't work:
1) Uninstalling the app one one device from the group
2) Shutting down one of the devices
3) Adding an invalid registration ID to the group (which doesn't work)
PS: FCM/GCM really needs to up their documentation/FAQ game.
Related
I'm making a server that sends messages using FCM to clients depending on what happens (temperature and/or humidity change, a door is opened, etc.).
But if the token can change, how can I keep track of the device to send messages to the correct one (w/o using a login system)?
I was thinking to link the token to the sim iccid in a database, is this correct?
Use device's advertising id. It won't change unless the user manually changes it. Please check the thread How to get Advertising ID in android
Update 05/18/2017:
Starting Android O, ANDROID_ID will now be different per app per user in the device.
Original Answer:
If you're looking for a long lasting (possibly permanent) ID that you can use, I guess you can make use of ANDROID_ID:
String ANDROID_ID
A 64-bit number (as a hex string) that is randomly generated when the user first sets up the device and should remain constant for the lifetime of the user's device. The value may change if a factory reset is performed on the device.
Note: When a device has multiple users (available on certain devices running Android 4.2 or higher), each user appears as a completely separate device, so the ANDROID_ID value is unique to each user.
Constant Value: "android_id"
However, there are still some factors that you should consider depending on your use-case. I recommend going through the Best Practices for Unique Identifiers documentation.
FCM wise, it is usually associated with a user, hence it is commonly paired with the user details.
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
In Android Open Source Project, a lot of core API declarations have an integer parameter userId in the end. I traced back and figured out the integer comes from a class called "UserHandle.java". There is a simple comments saying this class represents a user on the device. It still confuses me. Why do we need such a class? What's the difference between different values of the class, such as "USER_OWNER", "USER_CURRENT", "USER_CURRENT_OR_SELF"?
Thanks in advance!!!
Ever since Jelly Bean, Android platform has supported multiple users. This means that multiple users may be able to use one device, yet not be able to access other user's files or communicate with another user's app.
The first user on the device is user 0. The rest start their numbering from 10,11,... (In JB the numbering was 1,2...).
USER_OWNER is user 0.
He has some extra privileges over the other users (mostly access certain settings that others can't or uninstall an app for all users).
Multiple users on one device requires that only one user can be active in a specific point in time, this user is referred to as USER_CURRENT (since Kitkat().
In general one user's application can't send a broadcast message or an Intent to other user's apps.
Only apps with system permissions can do that (for example when the battery is running low, an intent will be sent to all).
Whenever you send an Intent from your app, the system service verifies whether this is a valid Intent i.e. if its supposed to reach all users then it's not.
This means that even if you were to use a certain api with the wrong userId (for example you force userId=0 even though this is user 10), then your call will receive a SecurityException.
To avoid such exceptions, there is also the option to send an Intent with USER_CURRENT_OR_SELF.
This means you're trying to send to the current user, but if he's not allowed to receive the Intent, let the same user who sent the Intent receive it.
I am going to enter the Samsung 2013 app contest, and one of the requirements is that you use their Chord API http://developer.samsung.com/chord.
I plan on allowing users to send messages to all phones that have my app installed. From what I gathered from the information in the previous link, this means that I will need to have a constantly running background process for users to receive the messages when they are not looking at the app at the time.
I want to know if this is true, and if so, is this viable? I am considering using the method detailed here: Android: keeping a background service alive (preventing process death) if I go ahead with this.
I'm trying to use Samsung Chord too. I thing you don't need to do this. Samsung's API Chord already provides this control.
According Chord's API:
"If a Chord node doesn’t receive a UDP signal within a specified amount of time, it considers the “missing”
node to no longer be part of the network."
And, the only thing you have to do is:
"A node cannot receive a UDP broadcast if it is in LCD-off status. Therefore, if developers want the node to discover other nodes while the application is running, the node’s status should be set to LCD-on. To do this, use Android’s PowerManager.WakeLock."
Best regards,
Adriano
I used to use an app called Log Collector to see system logs. It would send them to my email or via bluetooth,
However, on Jelly Bean the "read log" permission for apps no longer exists and apps can't read the logs, and Log Collector is obviously no exception.
So does one now need to root the device to see system logs? There must be a way for the user to read them. I don't need to access them from an application, I need to read them as a human being. Is there a way?
I got the answer in this google groups thread:
https://groups.google.com/forum/?fromgroups#!searchin/android-developers/READ_LOGS/android-developers/6U4A5irWang/8xOi74KfRIYJ
the message by Mark Murphy replying to Matteo Sisti Sette (which is me).
(it doesn't seem to be possible to link to a particular message, is it?)
POWER + VOLUME_UP + VOLUME_DOWN will generate a report and a screenshot that you can send via email or upload to Drive (ridiculous you can't share it in an arbitrary way such as send via bluetooth or open as text file, but anyways).
(seems you have to hold them for a while and the action is launched when you release them)
At first I thought he was making fun of me and that would just reboot or something, but then I tried and it works.
Quote from Google+ and credits to +Ian Clifton :
"If you go into the developer options of a device running 4.2, you can check the box to add the Bug Report option to the power menu. This also adds it to the quick notifications menu (not sure of the proper name, but slide down the notification shade with two fingers on a phone or on the right side of a tablet)."
..and that would be right answer.. Cheers