I'm making an app where a BroadcastReceiver intercepts an outgoing call and starts an activity with an AlertDialog right before the phonecall is actually placed. I've tested on several phones with different results. On two of the phones I've tested everything works great, the activity is started before the call is placed and therefore "interupts" the phonecall. After the activity is shut down, the phonecall resumes as normal.
On the third phone, an HTC, this doesn't work. The phonecall is placed before the activity starts. How can I prevent this? Are there any priorities I should be looking for?
Welcome to the wide world of HTC headaches when it comes to android development, specifically regarding broadcast receivers. Sense always seems to handle things differently, or in some special way. Though this isn't really the best answer, it is too long for a comment. After looking around a bit, this is a known issue with HTC. A quick fix seemed to have been found at Problem with interecepting outgoing calls on HTC Desire, though somewhat outdated.
They state that you can try
As it seems the HTC Desire (2.2) responds to setResultData(null)
which will stop the out dial. Then you can place a new intent
(Action.CALL) to call the new number. Not so nice workaround, but as
a user you hardly notice it.
Again I am not even sure if this works, or is the answer you are looking for, but it was too much for a comment :P
Related
I'm creating an application that needs to detect the biggest acceleration that the phone detects. Currently it works, but it does not continue the task when the screen turns off. To achieve what I have now, I wrote in onCreate:
mSensorManager = getSystemService(SENSOR_SERVICE) as SensorManager
mAccelerometer = mSensorManager!!.getDefaultSensor(Sensor.TYPE_LINEAR_ACCELERATION)
I have initialized these variables globally in the class. I then have implemented onSensorChanged(), onResume(), onPause() and left onAccuracyChanged empty.
From what I have understood implementing functions like this is different than more simply creating an asynchronous task. How would I go about changing this so to make it work in the background as well? Thank you!
You won't be able to use the Sensors API when the app went to the background even with WakeLock - the official documentation is clear about that.
You can easily proceed with using Sensors API even with the phone screen disabled inside a foreground service, though. In order to do that use this documentation as a start - Foreground Service. This doesn't guarantee the eternal live of the Service but it will most definitely live longer than an ordinary Service as well as you will have the access to the Sensors API. I am not sure about WakeLock in this case - you will have to try(but I think you won't need it).
Here is a span of answers. Some of them contain sample code and even links to sample projects
Here and here there are neet examples in form of medium articles.
I am developing an App that plays back audio, using media player. The Problem is the response time from when the headphone are removed to the time the audio playback is paused. The same problem can be found in RandomMusicPlayer
I have followed instructions from Handling the AUDIO_BECOMING_NOISY Intent
from android website. I thank you for any help you provide.
Peace.
Thank You ssuukk, for your response. Between development and other obligations have delayed my response. I now have time to post the solution to my problem.
My audio track is a voice track oppose to music, and I was getting about three to four word out after removing the headphones. I implemented Handling the AUDIO_BECOMING_NOISY Intent from android website and RandomMusicPlayer, and the RandomMusicPlayer has the same problem. I did suspect, not implementing as an inner class and the need for a second intent was the problem.
I found my solution here
Peace.
You need to be more specific. I'm using AUDIO_BECOMING_NOISY in my application and it never was any lag between removing headphones and pausing, nor a single complaint from an user that player is pausing too late. So the problem must be somewhere in your code.
I wanted to learn more about the Android Services / Broadcasts, so I started a simple project, to create a battery monitoring app. It turned out pretty good, I'm using it for a few days now, but I want to add a new function: to show since when is the phone charging/discharging.
First I thought that I would create two static fields in my BoradcastReciever extension class, where I get and publish the data about the battery, one for the actual state (charging/discharging), and one for the time, when the change in state happened. This way, I could just subtract from the current time the last change, and know exactly since when is the phone charging/discharging.
But there is a problem with this solution: It won't show the correct data at first, when a user starts the app. I wouldn't make a big deal of it, but I saw that Android tracks this data somewhere, because inside my phone settings I found this information, so why take the hard way.
So my question is: is there an easy way to get from the Android system the date/time (no matter what format) of the last charging state change?
I looked at the BatteryManager reference but there are no constants named after what I seek, and which I could use, to get the information from the Intent of my receiver.
The Android OS tracks the connect/disconnect of a power source, but does not make this data accessible to apps. You have to record this all yourself, using intent filters.
The two intent filters to use are android.intent.action.ACTION_POWER_CONNECTED and android.intent.action.ACTION_POWER_DISCONNECTED; with these, you can monitor when the power source is connected and disconnected.
You can find information about this process explained incredibly clearly here. Another blog describing the process can be found here.
I have developed a baby app where I need to lock all keys and ways out of the app, in order to be able to hand over the phone to my daughter. I used the "replace home screen" method to capture the home key, and that works great. All other hard keys (except power button, but that's not an issue since it's not easily pressed anyway) are locked. But the often discussed long press of home key is still launching the recent apps and offers a way out (which of course the daughter finds almost instantly).
I have seen other apps in market (toddler lock and more) work around this by emptying the recent apps list (or filling it with an icon that leads back to the baby app), but I have no idea of how to accomplish this. Anyone have a solution? How do I fill the recent apps from my app? Toddler lock even resets the recent apps after the lock-app is exited.
You could create an activity in your application that does nothing, and start it with an intent with the FLAG_ACTIVITY_NEW_TASK flag set. Fire this intent however many times you need to fill the history (my Incredible has 8 spots). For repopulating the history, look into ActivityManager.RecentTaskInfo.getRecentTasks (int maxNum, int flags)
See Documentation
It looks like you need to hold the GET_TASKS permission
The intents that originally fired those apps are stored as baseIntent, so you should be able to store them yourself(don't forget the extras), and re-fire them in order to repopulate the history list.
This is a hack, but it should work
Edit: After playing with this a little, it looks like you would need to have 8 different activities for this method to work, which is not realistic.
You need to do what is described in Mobius's post, but also set android:taskAffinity="" on the dummy activity elements in the android manifest file.
This has probably been asked before, but I can't find a good way of implementing it. I'm trying to write a program that manages a form of messages, and these messages are received from an external data source. This all works. However, the problem comes when I try to notify the user: I would like to have the notification jump directly to the message when it is touched, but this seems to mess up the back stack. This is probably best explained by example:
I open up the message list, the main activity, and browse for a while.
I hit home and go into another app (let's say Music).
A new message is received. A notification comes up, which I touch. The message detail view is displayed.
Now I hit Back. What I want to have happen is that I return to Music, but unfortunately, Back sends me to the message list, and then hitting Back will return me to music.
The both the list and the detail activities are marked as "singleTop", and the exact flags that I use for the notification Intent are:
FLAG_ACTIVITY_NEW_TASK
FLAG_ACTIVITY_CLEAR_TOP
FLAG_ACTIVITY_SINGLE_TOP
I figure if the Messaging application can do this, why can't I?
I have found one way to do this, but it's still not ideal:
Change the detail activity to have a different task affinity from everything else.
Add android:launchMode="singleTop" and android:excludeFromRecents="true" to the detail activity's manifest entry.
(Optional) Modify the list activity to open the detail activity with FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET. (This makes the task more like the built-in messaging app.)
The only fault to this scheme is that switching back over to the app will always go back to the list activity, but at least it is consistent. If someone else has a better way to do this, I'd love to hear it.