I'm adding sendBroadcast() to one of my apps but I won't be consuming the broadcast myself, so I'm wondering if there is a utility app or a debugger component I can use to monitor all sendBroadcast() messages on my device and see if the message I'm broadcasting is getting across.
I know I could probably throw something together, but if there is an exist app (that is known to work ;) that is the preferred route.
Thanks,
Jason
It is not possible to write this as an ordinary SDK app. You cannot listen for arbitrary broadcasts, only specific ones you explicitly register for.
Some broadcast information may be written to LogCat (I forget, haven't looked for that in ages).
Go figure, searched for 30 minutes for this and then found it 10 minutes after typing up a SO question...
https://play.google.com/store/apps/details?id=lt.andro.broadcastlogger
Related
I am trying to build an IM using Smack Library. I did it correctly and its working fine in foreground and I could start a STICKY service which can look for the message in the background. My issue is that I don't want a persistent service in the background, because it will eat up the battery of the android device, instead I want some broadcast to be fired up when the XMPP message comes with some events.
Is there any way I could achieve this? I have tried looking for example with the search term and I found nothing so I did not achieve any sort in this particular context so does not have any relevant code.
I think that all depends on what you want to archive.
If you need fast direct message arrival when the 2 clients are online, I think that the persistent service is the only solution with smack xmpp . With solid code development it should not eat up much battery...
If you don't really care if the message arrives after 2 minutes for example, you should use an intentservice (connect/get messages/disconnect) & a timer (e.g. every 2 mins) as long as the app is running.
What you describe (some broadcast to be fired up when the message comes) is more similar to PUSH mechanisms like Google Cloud Messaging...
Has anyone really used this? I am so in the habit of registering/unregistering my BroadcastReceivers inside an Activity that I almost stuttered when I saw this. Does this keep all my Broadcasts to my specific Linux Process ID that my app is running on? My Actions and Extras are package specific and the ones that are not are meant to be that way to allow other applications to possibly pick up an intent. I can see one easy use, I just did a test case with an AsyncTask, ProgressDialog, and an Activity. But what is the purpose? Is this for security? I am not a linux guru and was hoping for some input.
Per the LocalBroadcastManager documentation, the advantages are:
You know that the data you are broadcasting won't leave your app, so don't need to worry about leaking private data.
It is not possible for other applications to send these broadcasts to your app, so you don't need to worry about having security holes they can exploit.
It is more efficient than sending a global broadcast through the system.
You can also take a look at the LocalBroadcastManager source if you'd like to determine exactly how it works.
The issue seems simple enough - provide your own app that intercepts dial commands, and then dials them itself (imagine a VoIP application that if connected places a VoIP call, and if not connected, uses the phone's cellular capabilities to make the call).
this thread provides all the information you'd ever need - except there's a bit of a glitch:
Not every application seems to be using the same intents. I figure Intent.ACTION_DIAL must be the recommended standard option, and sure enough, most apps do that. Then there's Intent.ACTION_CALL_BUTTON, which seems to be of an oddity (my S3 tells me it has no application handling this action in the first place) and finally Intent.ACTION_CALL_PRIVILEGED.
Doing a little trial and error I figured that "native" apps (I'd call the native call log and contact application native) seem to be using Intent.ACTION_CALL_PRIVILEGED, whereas the rest uses INTENT_ACTION_CALL. And there lies the rub... if you register for both actions, then sure enough you can catch every dial command, but then what do you do with it? You can't fire off an intent with either of these actions since that'll just get you an infinite loop, there's no lower level action, and TelephonyManager conspicuously misses a makeCall method.
Since you cannot dynamically register and unregister intent filters, is there a solution for this dog chasing its tail?
How much performance does it costs to broadcast intents?
Is it okay to broadcast multiple per second or are intents expensive?
Intents are meant to launch different activities within the Android OS or to inform about basic actions. It seems like a bad design pattern to use them otherwise. As they travel between different processes and therefore implement the Parcelable interface, they are not the most light-weight.
If you are looking to update different activities at the same time you might consider using a common service.
According to this blog post, intents are 10 times slower than direct function calls
http://andytsui.wordpress.com/2010/09/14/android-intent-performance/
It doesn't cost THAT much, but think of it the same way as you would a broadcast in a network environment. If you want to continually send a message to a device, you wouldn't send broadcasts every 100ms. That would just flood the network. Sending a broadcast once every, say, 10 seconds might be appropriate though.
What exactly the best implementation is entirely depends on what you're doing. In certain circumstances, if you have several services running that need to be run independently, and you're only broadcasting these intents that fast for say, 10 or 15 seconds. That might be ok.
But we can't really say.
I would like to know how to intercept incoming calls and also how to forward them. I know there are several questions regarding this topic here and elsewhere on the net, but all the answers use the android.intent.action.PHONE_STATE action which is broadcast always after the phone begins to ring and the call screen is shown.
That's why I'm looking for a solution where i could intercept the call in an early stage before any notification (ringing etc..) has been done. I would like to know if maybe this is possible on a platform level in native code and if yes how ? Or perhaps with some kind of trick with the SDK ?
In general, if you can't do it in Java, you can't do it in the NDK. Most of the time the opposite is true: You can't do MOST things on Android in the NDK.
I don't know of a way to do that, and frankly doubt it exists: It would be a huge security hole if you could download an application that would forward calls to another number.
You may want to look at this source code, it may help you : http://code.google.com/p/auto-answer/
None of the existing apps in Android can forward a call based on a given number. All they can do is forward all or nothing. There's one app in particular (cBlocker) that can forward calls on schedule besides blocking incoming and outgoing calls and SMS based on rules.