When attempting to pair with a Bluetooth device (programatically), in the case where, for example a pin code is incorrect, Android will display a toast notification to the user.
I'd prefer to handle this fully in code without the default system toasts.
Is it possible to hide these system notifications ?
It appears that these toast msgs are coming out of BluetoothEventManager.java in the platform Bluetooth settings package and are triggered based on the reason for the pairing failure, identified by an EXTRA_REASON in the Intent associated with the BOND_NONE state transition. Only specific reasons cause a toast msg to be displayed. If you can manipulate the reason code in that Intent, you'll suppress the toast.
So far, I haven't been successful in doing that though.
As a more heavy-handed alternative, if you can modify and build your Android platform source, you can gut the .showError() method in
./packages/apps/Settings/src/com/android/settings/bluetooth/Utils.java
and prevent the toast messages as well.
Related
I have an app that reads notifications through TTS. With Google's change in policy for apps using Accessibility, I switched to Notification Listener, though that meant I had to remove the option to read toast messages. I released the update last night and already received feedback from someone who wanted the toast feature back.
Is there any way to read toast messages without using Accessibility? My search for a solution came up empty.
Update (2018-01-16)
After a little digging into the Android source, I found this relevant method in the Toast class (API 27):
private void trySendAccessibilityEvent() {
AccessibilityManager accessibilityManager =
AccessibilityManager.getInstance(mView.getContext());
if (!accessibilityManager.isEnabled()) {
return;
}
// treat toasts as notifications since they are used to
// announce a transient piece of information to the user
AccessibilityEvent event = AccessibilityEvent.obtain(
AccessibilityEvent.TYPE_NOTIFICATION_STATE_CHANGED);
event.setClassName(getClass().getName());
event.setPackageName(mView.getContext().getPackageName());
mView.dispatchPopulateAccessibilityEvent(event);
accessibilityManager.sendAccessibilityEvent(event);
}
That makes it clear that if no accessibility services are enabled, toasts aren't dispatched to the handler that AccessibilityService uses, so some kind of hack to access toasts the same way Accessibility gets them would be impossible without any services enabled. Of course, I'm trying to avoid creating an accessibility service again and don't want to rely on users having a different one enabled.
It appears that if there is any way to access toasts without Accessibility, it may have to be some fairly complex reflection to reach Toast$TN.mNextView or .mView through com.android.server.NotificationManagerService.mToastQueue and $ToastRecord.callback. It's a bit over my head right now as I'm not very familiar with reflection, but I'm still digging.
I want to send an SMS message in my application and I want to ask what will happen if the user has a tablet. Will my app crash?
Will it do something strange?
I am using the following method:
SmsManager.getDefault().sendTextMessage(destinationAddress, scAddress, text, sentIntent, deliveryIntent)
Technically, tablet device won't be able to "find" your application from Google play store, since your app requires telephony features.
However, if tablet user got your application some other way, and install it manually, you can not prevent them. When application running, it might crash if the firmware does not handle the exception correctly. But I don't think it would happen, most of the chance it won't take any effect.
Well, that depends on the tablet, if it has a SMS slot or not, I assume you are interested in the type that doesn't has a slot, in this case the tablet will take a long time and the system will ask for wait or cancel, if wait then it will finally show an error message, the error message depends on the Android version, and your application crashes in this case...
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
This question is pretty much a duplicate but the linked issue was never really resolved and the thread is a few months old so I didn't want to resurrect it.
The default behavior of apps running on an ICS device with Android Beam turned on is to push a message with the application Uri that will be processed by Google Play on the receiving end.
I am trying to develop an activity that will push NdefMessage if condition A is true and will otherwise disable pushing messages. The API documentation for setNdefPushMessage(...) seems to indicate that this is possible by passing in a null message:
Pass a null NDEF message to disable foreground NDEF push in the specified activities.
However, trying to simply ban all pushes via the following code still results with the "Touch to Beam" UI coming up and an application Uri being sent...
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
getNfcAdapter().setNdefPushMessage(null, this);
}
Does anyone know if it is actually possible to disable pushes from an Activity? A few systems apps do it but I have not been able to locate the code that achieves this. Any help is much appreciated.
This seems to be a bug in Android ICS. Although the documentation says you should be able to disable it by setting the NDEF message null, this simply does not work. Good news is that it has been fixed and now does work in Android 4.1 Jellybean.
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.