I wan to hide/show my caller id from my activity programmatically. I tried to find it in the android documentation but without the luck. Maybe you have any ideas?
I posted a question asking this on the Android Google group and got absolutely no answers at all. I've also seen a couple of other question on SO which also had no answers (or none that work).
I came to the conclusion that it simply isn't possible. My reasoning is this...
If I go to Settings -> Call -> Additional settings, I see an AlertDialog which has a HeaderTitle of 'Call settings' and I see a circular progress indicator and a message saying 'Reading settings...'.
It occurs to me that my phone is, at that point, accessing my phone/network provider. The resulting 'chooser' dialog gives me options for 'Network default', 'Hide number' and 'Show number' and when I make a selection (or even if I just 'Cancel' the dialog), I get another AlertDialog with circular progress indicator with the message 'Updating settings...'.
In short, it seems the Caller ID setting is not entirely 'local' to the phone settings and relies on interaction with the provider and, for whatever reason, as a result of this the Android APIs don't allow this to be manipulated programatically.
I'm not sure if this is something on the 'To Do' list for future versions of Android or if there are legal/security implications in allowing it to be done or some other reason. Whatever the case may be, I haven't found anybody so far who is able to explain why there isn't a method for TelephonyManager (for example) to simply switch this.
EDIT: No luck on getting the Additional Settings AlertDialog with the standard APIs either.
The reason I say that is that it is possible to pull up various parts of the device's 'Settings', e.g., in one of my apps I use android.provider.Settings.ACTION_WIRELESS_SETTINGS in the constructor of an Intent passed to startActivity(). This brings up the Settings page for enabling/disabling wi-fi, mobile internet and bluetooth.
android.provider.Settings has other similar ACTIONs for other Settings pages but there isn't even one for 'Call' never mind Call -> Additional Settings and nothing for the AlertDialog to allow you to choose to Hide/Show the outgoing Caller ID.
If this can be done then it would have to be an undocumented API unless I completely missed it (I spent a long time looking). I suspect examining the Android source-code may be the only way to find an answer and I haven't attempted that yet.
I have managed to get Additional call settings dialog. Explanation below:
Although it looks like it is part of the Settings, in fact it is part of the Native PhoneApp. If you take a look at the AndroidManifest.xml of the PhoneApp you will see that Activity GsmUmtsAdditionalCallOptions has defined IntentFilter for the android.intent.action.MAIN.
So, the code that I checked to work correctly on several phones:
Intent additionalCallSettingsIntent = new Intent("android.intent.action.MAIN");
ComponentName distantActivity = new ComponentName("com.android.phone", "com.android.phone.GsmUmtsAdditionalCallOptions");
additionalCallSettingsIntent.setComponent(distantActivity);
startActivity(additionalCallSettingsIntent);
If the #31# trick works for your needs for a single call then you could add a broadcast receiver that listens for the outgoing call notification and modifies the number to include #31# at the start before it gets dialled. Android allows the number to be changed on the way through like that.
Only works if your default is to enable caller ID and your network support #31# and you want to toggle it off using a widget, say.
The Caller ID is network specific not something that the phone controls. In fact in certain mobile network configurations the phone doesn't even 'know' its own phone number.
Some networks support sending an activate/deactivate caller ID network command. In GSM this is normally #31#. It can be permanent or on a per call basis.
Permanent requests the network to hide the caller ID for all calls.
Per call requests the network to hide the caller ID only for that call. The latter is achieved by prefixing the number being called by #31#, so for example calling #31#85432786426 would call 85432786426 hiding the caller.
Some networks support both, some only support one of them, and some do not enable it. Try your luck and try prefixing the dialed number with #31# and see if it works.
http://www.gsm-security.net/faq/gsm-caller-id-clip-clir.shtml
If you want a shortcut to the additional call settings, you can use App Cut and select GSM settings. It will place a shortcut on your home screen.
Related
I have configured my app to support Android Oreo with compileSdkVersion 26. I've also set up android:autofillHints="phone" for my phone number input field. When I tap on the field, I can see "Autofill" popping up. However, when I tap on "Autofill", "Contents can't be autofilled" toast appears and I see the following trace in logcat:
RemoteFillService Not handling { when=-3ms what=3 target=com.android.internal.os.HandlerCaller$MyHandler } as service for ComponentInfo{com.google.android.gms/com.google.android.gms.autofill.service.AutofillService} is already destroyed
View dispatchProvideAutofillStructure(): not laid out, ignoring
How should I fix this? I've confirmed that I have the phone number configured in Settings > System > Languages & input > Advanced > Input assistance > Autofill service.
UPDATE with a sample XML: In API 26 emulator settings, I can select "Autofill with Google". Using the Design tab of Android Studio, I added a "Phone" type EditText, and then manually inserted android:autofillHints="phone" in the XML element:
<EditText
android:id="#+id/editText"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:ems="10"
android:inputType="phone"
android:autofillHints="phone" />
Logcat peculiarities described above can be observed using this XML.
I'm the Android Frameworks engineer leading the Autofill Framework project, so I'll answer some questions:
The "Contents can't be autofilled" message typically means the Autofill Service does not know how to autofill the screen. When you're adding autofill support to your app, it's often easier to use an Autofill Service you can control first, rather than a "real" service like a password manager. As mentioned in a previous reply, we provide a sample service that can be used for this purpose.
When you long-press a text field and select AUTOFILL, you are in fact "forcing" an autofill request as mentioned in another reply (i.e., behind the scenes the text field is calling AutofillManager.requestAutofill()). If the Autofill Service knows how to autofill your screen, you shouldn't need to do that, as the autofill suggestions would show up right away once you focus the input field.
You shouldn't need to set importantForAutofill or call AutofillManager.cancel() in your case.
So, my recommendation is to try to use the sample Autofill Service implementation to test your app first. Most likely, the first time you access your app the autofill popup won't be shown because the service does not have data for it. But once your app triggers the save UI (for example, after you manually enter the phone number and the activity finishes) and you tap save, that data should be available the next time you launch the activity.
Hope that helps,
-- Felipe
This may well be the issue - as
as service for ComponentInfo{com.google.android.gms/com.google.android.gms.autofill.service.AutofillService} is already destroyed
Ensuring data is available
In some special cases, you need to take
additional steps to make sure that the data is available to the
Autofill Framework to save. For example, an activity can present a
layout with standard text views, but then destroy the layout and
replace it with one without child views, such as GLSurfaceView.
In this case, the data in the original layout is not available to the
framework. To make the data available to the framework, you should
call commit() on the AutofillManager object before replacing the
original layout.
You'll need to fix some of these issues within your java code.
Add IMPORTANT_FOR_AUTOFILL_AUTO and check that autofill isenabled().
You may need to manage some of the settings within the java force the Autofill request:
Sometimes, you may need to force an autofill request to occur in response to a user action. .../...
public void eventHandler(View view) {
AutofillManager afm = context.getSystemService(AutofillManager.class);
if (afm != null) {
afm.requestAutofill();
}
}
Do you have an app on you phone that implements an Autofill service? I tried it with "Autofill with Google" service, and could got my phone number autofilled without problems (with emulator running SDK 26). You will need a service part for get the autofill working. See this example.
Get the latest OS image. After downloading and installing the update that became available on 2017-09-21 for my Google Pixel XL device, autofill works perfectly. So, it suffices to have android:autofillHints="phone" in XML, no other changes are required to enable the autofill feature.
The "Contents can't be autofilled" - this was caused for me because i did not agree to the auto fill service. So go into your android settings in Oreo and above and search for "autofill" . find your service (mine was default googles) and there should be a prompt to agree to its service. toggle it off and one if it does not appear. Afterwards i was able to use autofill.
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'm developing a custom home screen launcher. As part of its functionality I would like to be able to show unread notification badges.
Instead of implementing my own API for this, I would like to hook onto existing standards. The most widely used is the one for Samsung's TouchWiz launcher.
It works through a ContentProvider with the authority com.sec.badge. Now, on Samsung devices, I can easily use a ContentObserver to observe changes to Samsung's ContentProvider and it works perfectly. However, on devices without an existing ContentProvider (i.e. non-Samsung devices) I would like to provide my own ContentProvider for this purpose. This also works perfectly to capture inserts from other apps.
However, when I roll my own ContentProvider I naturally get an INSTALL_FAILED_CONFLICTING_PROVIDER error when trying to install on Samsung devices.
I fully understand why this is happening since Android wants to avoid having conflicts in the providers.
What I would want help with is a workaround. Is it possible to somehow register my ContentProvider dynamically instead of declaring it in AndroidManifest.xml? That way, I could first check if the authority is already taken, and if so go with an Observer. Otherwise, register my own ContentProvider and go with that.
I realize that this might be bad practice but I don't really see any other way. Some apps (such as Facebook) also implement Sony's badge API that works through Broadcasts which avoids conflict, but not nearly as many existing apps use this process.
I've tried this:
ContentProvider test = new SamsungContentProviderSpoof();
ProviderInfo providerInfo = new ProviderInfo();
providerInfo.authority = "com.sec.badge";
providerInfo.enabled = true;
providerInfo.exported = true;
test.attachInfo(this, providerInfo);
but that obviously fails. I guess I need to somehow access some system ContentResolver and register myself there, but I don't know how.
I would like to hook onto existing standards
There are no existing standards. A few vendors have done their own thing, and that's it.
The most widely used is the one for Samsung's TouchWiz launcher.
Note that this mechanism is undocumented (AFAICT) and unsupported (outside of select Samsung partners).
Is it possible to somehow register my ContentProvider dynamically instead of declaring it in AndroidManifest.xml? That way, I could first check if the authority is already taken, and if so go with an Observer. Otherwise, register my own ContentProvider and go with that.
You are welcome to say that it is disabled (android:enabled="false") in the manifest, then conditionally enable it later using PackageManager and setComponentEnabledSetting(). You would know that you needed to do this by either trying to communicate with the existing provider (e.g., registering your observer) and getting an expected error, or by interrogating PackageManager to see if the provider exists.
However, not only will you need to claim that you are Samsung in terms of the provider, but also in terms of the custom permissions. That will break on the "L" Developer Preview, and probably going forward, for much the same reason that you ran into with the conflicting provider. At the present time, there is no workaround for this that I am aware of.
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
I want to develop an application that disables the Background Data (new feature in Android 1.5) and Auto Sync and then enables GPRS/EDGE connection and vice versa.
I figured out how to enable/disable GPRS/EDGE by changing the APN settings. (weird solution. However; Android developers couldn't think a user may want to disable GPRS/EDGE) But, I couldn't find a way to enable/disable Auto Sync and Background data.
I investigated the Android code and as I understood, the Sync operation is an intent. So, I wanted to reach with putExtra to the intent and trigger the enabling/disabling. But; I couldn't find the correct keyword. Or maybe I was totally wrong.
What is the right way to solve this?
In my HTC dreams, there is a checkbox to disable the auto sync. I can look for the menu arborescence if you wish so you can find what the callback function is in the Android source code. But I am pretty sure auto sync cannot be completely disabled. Unchecking auto sync will prevent sync from being performed on a timed basis, but it will occur everytime you run an app with sync capabilities if any network data connection is available.
Good luck anyway.
EDIT :
There are two ways to get the info you desire.
First, I think you can use the code in android-sources/packages/apps/Settings/src/com/android/settings/Utils.java to create an activity that will enlist all the keys of the intent then find the one you want.
The other way is to write a nice mail to the guy who made the Toggle Setting app (http://smartphoneandroid.com/2008/12/28/toggle-setting-perfect-app-for-android-phone.html) since he obviously found a solution to your problem. His email address is written in the app sheet on the android market. I won't write it here, but if you do not have access to real android phone, I can mail it to you on your mail address.
Background data is a secure setting, so cannot be changed by user applications. But bear in mind, it's just a setting - it's not enforced. Apps are meant to read it and respect it but I bet some don't.
To Disable the AutoSynch
ContentResolver.setMasterSyncAutomatically(false);
To Enable the AutoSynch
ContentResolver.setMasterSyncAutomatically(true);
Permission you require is
<uses-permission android:name="android.permission.WRITE_SYNC_SETTINGS" />
setMasterSyncAutomatically() on ContentResolver should do it. Check: general-sync-settings-auto-sync-checkbox-programtically