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.
Related
I found out there's a system function called IBluetoothManager.enableNoAutoConnect(), which by the name, seems to do exactly what I've been searching for hours: enable Bluetooth without auto-connecting to devices.
I can call the function, but...
java.lang.SecurityException: no permission to enable Bluetooth quietly
Because...
if (callingAppId != Process.NFC_UID) {
throw new SecurityException("no permission to enable Bluetooth quietly");
}
So, is there any other way of calling this function? Like some ADB command? Or through another class? I also found a function that does the same here, in AdapterService.java. But I don't know how to get to it (doesn't even appear on Android Studio).
Note: I have root and system-privileged permissions (just not signature ones), and I'm using the internal/hidden SDK, so I have access to the classes and everything without needing reflection (and still, AdapterService doesn't show up - unless there's a problem with the "SDK" and it's not showing all it should?).
(PS: I say "quietly" in the title because in the source, the variable that tells if it's auto-connect or not is called quietMode.)
EDIT: actually the function is directly in BluetoothAdapter, without needing to go for the interface. Not sure how I didn't notice it. But anyway, same problem.
EDIT 2: more specifically for Android Oreo and below (or Pie and below), as I just found a function called setSilenceMode() on BluetoothDevice, and it might do what I'm wanting (not tested), but still, missing on older APIs.
Thank you
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'm looking into porting some existing code to take Android M's new way of dealing with permissions into consideration. However the permission API needs to have an activity associated with it (for example the requestPermissions() method's first parameter is an activity).
So how should a service that needs to check if a permissions has been granted and request for permissions use this new API if the service doesn't have an activity?
Is it possible for the service to create a dummy invisible activity just for use with the permissions API? (if its possible I don't like the thought of doing that anyway though).
Or suppose its not a service but a model class that needs to perform a permissions check, in MVC a model shouldn't have any knowledge of the Vs and Cs and yet now either it has to in order to know which Activity to use with the permission API. Or potentially lots of code might have to migrate from model code into Activity code.
Any thoughts on how to migrate non activity based code that needs to check/prompt for permissions over to Android 6.0?
Update: I left out an important piece of information - this is code that is pre-installed (our company provides code that device manufacture's place in rom) and often may be run at device boot time and run in the background. Therefore the usual situation of a user being prompted for permission when they launch the app or later (and there therefore being an activity at that point) does not necessarily apply.
So how should a service that needs to check if a permissions has been granted and request for permissions use this new API if the service doesn't have an activity?
There is almost always an activity, except for pre-installed apps and plugins for other apps. Otherwise, your service is unlikely to ever run, as nothing will have used an explicit Intent to start up one of your app's components, so it will remain in the stopped state.
For the ~99.9% of Android apps that have an activity already, if the permissions are needed for the whole operation of the app, request them on first run. As Snild Dolkow notes, if the user later revokes the permission through Settings, you can detect that without an activity, then use other UI options (e.g., Notification, app widget) to let the user know that operation is suspended until they grant you the permissions again, which they would then do through your activity.
Is it possible for the service to create a dummy invisible activity just for use with the permissions API?
Presumably you can have a Theme.NoDisplay activity use requestPermissions(). However, from the user's standpoint, it will not make much sense, unless there's some alternative UI (app widget?) that they are interacting with. Popping up a permission dialog out of nowhere is unlikely to make you popular.
UPDATE 2019-06-15: Note that Android Q bans services popping up activities frmo the background. Please use a notification instead.
in MVC a model shouldn't have any knowledge of the Vs and Cs and yet now either it has to in order to know which Activity to use with the permission API
Do not touch the models until you have requested the permission, and gracefully fail if the permission is revoked. You already have to gracefully fail in other circumstances (out of disk space, no Internet connection, etc.), so a revoked permission should be handled in much the same way.
using this new 6.0 API seems like an recipe for bad design and tight coupling
You are welcome to your opinion. Based on what I have read, the Android engineers believe that asking the user for permissions is part of the user experience and is best handled at the UI layer as a result.
Again: the vast majority of Android apps will not have a problem with this, as they have a user interface. Apps that do not have a user interface and need dangerous permissions are in for some amount of rework.
this is code that is pre-installed (our company provides code that device manufacture's place in rom) and often may be run at device boot time
First, please understand that this is so far from normal that you can't even see normal from where you are due to the curvature of the Earth. :-) You can't really complain that Google did not optimize this particular scenario.
As I understand it, even system apps should be asking for runtime permissions. The Camera app did, for example, on the 6.0 preview. That being said, there's gotta be some database on the device somewhere that is tracking what has been granted, and presumably there is some way to pre-populate it. However, the user could still revoke it from Settings, presumably. But, the manufacturer could pull some stunts (e.g., messing with the Settings app) to possibly even preclude that scenario. I'd be looking in the same area as "how do I get it so my app cannot be force-stopped?" that device manufacturers can do.
Your alternatives would be to get rid of the dangerous permissions or to migrate your app off the SDK and into a standard Linux binary that would be run as part of the boot process and be put into a Linux user group that has access to the stuff that you need.
Ask for it when the user enables whatever feature your service provides. They'll be in one of your activities at the time. Yes, it means that your activities need knowledge of what permissions your services will require.
The service can always check for the permission by itself, though, since checkSelfPermission() is available in all Context instances. So you don't need an activity for that.
I guess an alternative would be to have your service post a notification saying "feature X requires you to approve more permissions". Actually, that may be a good idea regardless, in case the user goes into settings and revokes any permissions after the fact. That notification would then take the user to some activity with an "enable feature X" button/checkbox -- ask for the permission when that is selected.
You can send a notification. Look this library to manage the permissions: permission library
Is is possible to detect network reject reason for outgoing calls in Android?
For example, let's assume a person is out of credit and is attempting a phone call. In this case, the Network will reject the call (since the person is out of credit). How can an App detect this?
Thanks!
A "bit" late xD, but I believe you're looking for this: https://android.googlesource.com/platform/frameworks/base/+/master/telephony/java/android/telephony/DisconnectCause.java. I just found it with help of what you said on one of the error codes: "Network is busy" --> searched "network is busy site:android.googlesource.com" on Google, without the quotes (saying this because they matter on Google searches, in case anyone didn't know).
That's DisconnectCause class and there's also PreciseDisconnectCause: https://android.googlesource.com/platform/frameworks/base/+/master/telephony/java/android/telephony/PreciseDisconnectCause.java. You can know this last one because on the first one, it's said that class is used on PhoneStateListener on onCallDisconnectCauseChanged() (which may be what you want), and on Android Developers, we can see that method has 2 parameters, which give 404 error on Android Developers. So I seached the .java class file on Google for Android Source links and there they are.
Notes on using this method:
it requires API 30 at minimum (pity...);
but more important, it requires READ_PRECISE_PHONE_STATE (the app must be installed as system app) - or some other trick with root commands.