Develop Reference

Multiple phone calls from android app

I'm implementing a function where an outgoing alarm is triggered, f.e. If the phone falls down and doesn't move for 60s afterwards. Then, between 1-5 numbers should be called. Example of how it should work:
Phone falls down and doesnt move for 60s
Number 1 is called
Number 1 doesn't accept call in 20s
Number 2 is called
Number 2 doesn't accept call in 20s
Number 3 is called
Number 3 accepts call, alarm is being terminated
The alarm is triggered correctly, and I can make a call. But I couldn't find anything on how to determine if a call was accepted after x seconds, and how to start a new call then. Any help / sources?
Edit:
Via the PhoneStateListener I'm now able to see if the call was cancelled. However if it's not, I can't get the actual state, so I don't know if it's still ringing, if it's actually calling or if it has gone to the mailbox. In the description of the CALL_STATE_OFFHOOK it's pretty clear that you can't see wheter the call was answered or the number has just been dialed. Is there any workaround for that, maybe even with rooting the phone or something like that? Any hint is appreciated.

It seems like this isn't possible.
The documentation for Intent.ACTION_CALL states that it doesn't return an output (at least I guess that's what the oh-so-helpful "Output: nothing" comment means).
Similar questions here and here have not gotten any useful positive responses.

While using an intent makes it NOT possible since you can't check the state, that's NOT the way you should call the telephony service since you want your program to be in control. The best way is to this is to:
a) enable telephony permissions in your app:
b) instantiate the Telephony manager class in your activity, then
c) handle Android call states dial/listen in your activity to store the previous state. If it was 'ringing' and current state is idle a they cancelled the call. If the current state is off-hook and the previous state was ringing, they answered the call. See a working sample here:
http://www.compiletimeerror.com/2013/08/android-call-state-listener-example.html

What timeout value should I set to avoid problems in a REST based Android application?

It may sound stupid but. I've set the timeout to 5 seconds and testing with a 3g connection it seems to be too little when in my experience it really sounds like an eternty.
What's a common use value for users not to desperate and keep the things together?

There are really no special, commonly used values for something like timeouts. A value that works for one user may not work for the other. The important thing from a UX perspective is, when the timeout does occur, the user is informed of:
A timeout has occurred.
The next appropriate action to recover from it, such as, restart the app, wait a while, contact support etc.
via unambiguous error message.

Doesn't sound stupid, but it depends on the interaction between your app and the server. Unlike a router based timeout, some routers begin their calculation when they begin to do the work (Heroku comes to mind). In this case, anything under 30 seconds is good.

Time since the app is open in android

Hello
In my android application i would like to get Time since when the app is opened.
Initially what i tried was getting the time when the app is loaded from the server and then taking the difference with the current time from the device.But by doing that if the user changes the time then i willnot be getting the actual time.
Its not posiible to hit the server again for the same.
Is there any way to achieve this in android?
Please share your valuable suggestions.
Thanks in advance:)

Try the "SystemClock" class, "uptimeMillis()" method.
Store the result in a variable when the app starts.

Echoing what I said for your other question, you first need to become familiar with the activity lifecycle and understand the novel meanings (almost meaninglessness) of common words like "open" and "start" in the life of an android app.
There isn't any way you can prevent the user from changing the system time - you just don't have the right to do that to users. Normally this should be a rare event, unless you do something that makes them want to, such as lock them out of a free version of your app after so many minutes. (However if the phone is on a mobile network, presumably the mobile network occasionally adjusts its time to correct for errors in the device's oscillator, or administrative time changes)
What you can do is check the system time on every entry point to your application. If it ever goes backwards, well... something is going on. If the clock has been set back, you could assume no time between the calls with the negative time difference and resume your time meter from there, at least keeping all the previous used time in your record.
It may be that there are cpu cycle counters which you could query and correlate to system time, but this may be highly device specific and may in fact be resettable. And it may get weird if the cpu frequency is demand throttled.
You might be able to set a countdown timer as a bound on the maximum possible time between entry points at which you could meter. I don't know if these work reliably across system time changes or not - ideally they would. Testing or reading the source will reveal.

Use elapsedRealtime in your onCreate() store it. More reliable.

Is there a Dropped Call Listener

Does the Android SDK have the ability to to trap a Dropped Call event? If so, what is it called? I've been prowling the documentation looking for it.
Is there a difference between a hang up, and a dropped call?

Does the Android SDK have the ability
to to trap a Dropped Call event?
No.
Is there a difference between a hang
up, and a dropped call?
To humans, yes. To Android, no.

Just a bit of additional information.
The Android system does know when a call is dropped for what ever reason, i.e. Congestion, No Circuit Available etc. However none of this information is parsed through to the sdk. In the source at some point android basically mashes a whole bunch of telephony related information into a few, excruciatingly vague sdk calls. For example - the only indication we get of a call end is the changed in a PhoneStateListener from OffHook to Idle. Which literally encompasses every single reason for a call ending.
Even different states of the call are mashed together. Where as we should be able to get information like whether the phone is alerting the b party or actually has an active connection, this is reduced to the three states available, offhook, idle and ringing - note ringing is only when your device is ringing, not when the person you are calling phone's ring.
Sorry to be another bearer of bad new, but alas. all we can hope for is better support at a later stage

How can I detect when outgoing call has been accepted

I am not able to detect when outgoing call has been answered, I have registered BroadcastReceiver for PHONE_STATE broadcast, but onReceive() gets called only when number is dialed and when call has ended.
Edit: If it is not possible with current API (1.5 or 1.6) please enlighten me ?

Android does not have specific listener yet for making sure whether the call(outgoing call) is answered or not. The moment a number is dialled it goes to off_hook state (in case of outgoing call). This is one one of the gap which android telephony has to yet come up with

I don't see you getting any specific answers, so I try with a general one that may help. If you are referring to calls going out the PSTN (Public switched telephone network), you won't be able to detect when the far side answers. The way the phone network is structured, you won't be able to get that information except in very special cases. Usually what you see on the handset is the moment the call is being routed out of the cell network.
As for in network (same subscriber), it may be possible to get that information, but I'm not sure. You may want to look into CDMA or the protocol used by your carrier to see if it is going to even be possible to get farside information.