I want to use C2DM in my android application. I am using code schemas shown in official tutorials. Everything seems to work fine, but I have problem with handling registration properly.
There are 2 methods in C2DMMessaging class which I have to use: firstly register() and next getRegistrationID(). If I use them sequentially, I get null form the getRegistrationID(). The problem is registration is asynchronous. In my application in the beginning I need to know the regidtrationId, I can start the rest of the app only after I get it.
I tried to do some synchronization using monitors (i.e. wait() in register method and notify() in C2DMReceiver.onRegistered()), but it didn't work (the code of onRegistered() hasn't been reached, after calling wait() in register()).
In other words what I need is making registration synchronous, so I could continue, only after I get registrationId. What is the right way to do it?
Make sure you are following below guidelines:
To develop and test on the Android Emulator, you need to download the Android 2.2 version of the Google APIs Add-On into your SDK.
Make sure you set android:minSdkVersion="8" in the manifest.
Make sure you have at least one Google account synced on your emulator or device.
Related
Before I begin, I understand that GCM is depreciated, but due to time and resource constraints on this ticket, I don't think migrating to FCM is feasible at this juncture. I didn't write the app (the contractor who did it is long-gone by now), I just need to fix it if possible. If it's not possible without doing a migration, I'd like to just relay that information onwards instead of continuing to bash my head against this any longer.
My question, in short, is this: Was there anything introduced in Android 9.0 (API 28) that would preclude the GCM registration process from working? The app works fine on all preceding versions of Android, but not Pie.
More info: When the app starts on a fresh 9.0 device, a call to GCMRegistrar.getRegistrationId() is made. It returns a blank string, as expected. Intent filters are created, receiver is registered, etc. Finally, a call to GCMRegistrar.register() is made. On every other version of Android, I get a response with a registration token that gets fielded in the onRegistered method in the GCMIntentService class. For some reason, this callback method is never called on devices running Pie.
What I've tried: Already updated play-services-gcm to v16.0.0. Min sdk is 14. Target is 28. Ran some debug broadcasts that target my receiver, it still functions. Still can't find a good reason why onRegistered suddenly isn't being called on this version of Android.
I'm more or less unconcerned about the code and/or manifest because, again, it has been chugging along fine on hundreds of devices for many years now. Did Google just cut life support for GCM registration at the OS level with Pie or something? If not, are there Pie-specific changes that need to be made to get it to work? Looking at Google's documentation, their solution seems to be "migrate to FCM", but as I mentioned before, that's not an option at the moment.
As I mentioned in my comment, the rollout isn't supposed to come to full fruition until April of 2019. With that said, it's hard to say without code, but depending on your implementation and that you mentioned the GCMIntentService it could have something to do with the changes to how background Services are allowed to run in Android Pie. See this post for more details.
Check your logcat to see if you get any errors when trying to start the Service during the registration process.
How can we disconnect a call in Android. I know this has been asked many times. There are many other answers which state that our app needs to be a system app to disconnect a call but then the answer at this link states that it is not so. But, even the answer there does not help to disconnect the call.
Then I saw that SDK 23 adds a new class Call which the Android document says can be used to handle calls. It has a function called disconnect(). So, how can this be used, if our app is not the dialer app? I only need the data to cut/answer the call. (Don't want to become the default dialer app, nor the system app) https://developer.android.com/reference/android/telecom/Call.html#disconnect()
Could I be guided towards what is the latest information in this regard? For both Marshmallow and pre-Marshmallow devices. I feel the solution to both might be different.
Not sure of the solution for pre-Marshmallow, but for M+ I feel the Call class is to be used.
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
I had posted a similar question
How to access sms's or call logs on devices with cordova apps
and based on that we have no permission to access call logs.
How does Truecaller access call logs or call events - on Android it shows who is calling and on iphone the number is detected by the app after call and then it shows who called.
Can we do the same for Cordova apps?
I did find a cordova-calllog-plugin to access device call history. Hope this should help, not tried personally though.
Also looking at the following link, i guess its definitely possible to acheive this in corodva apps
I would like to notify my server that the user deleted the application. How can I accomplish this?
Get application uninstall event in android
According to this post what you ask for is not possible. Are you by any chance using a C2DM implementation?
Unfortunately there is currently no way for an Android package to execute code when it is removed. However, you can register a BroadcastReceiver for ACTION_PACKAGE_REMOVED in a different package that will be called when packages are removed from the phone.
Also see this question.