I can send MMIs using the approach described in e.g. Call forwarding. After the MMI is sent, there is usually a reply such as "Call forward successfully activated" or some-such.
Is it possible for the activity which started the intent to access this reply (especially for MMIs which query status messages such as "Is call forward on?") ?
Is it possible for my activity to prevent the system displaying the reply to the user directly? I mean this in the sense of "Not bother the user unnecessarily" rather than "stealthily doing things behind the user's back"; i.e. I don't care if the UI displays status icons etc, I just don't want the user having to confirm a large message box each time.
If not normally, how about on a root-ed phone?
In case this is MMI dependent, I'm mainly interested in MMIs that set, query, or cancel call-forward.
You couldn't necessarily block the popup, but for example in my app, you can send an sms to enable call forwarding, so you could run the mmi code (call startActivity from a broadcast receiver), and set an alarm to start the home screen about 10 seconds later. That wouldn't remove the popup, but it wouldn't be quite as annoying that way, I don't think.
If it really is important and you still care, you could break down the settings application using dex2jar and then use A java decompiler to read the jar file.
If anybody finds out the answer to this question, I would also be interested. I may do the work myself sometime, but I just don't care enough right now or have the time.
Related
I have been working a bit on reading radio logs to retrieve USSD replies, rather than the aidl,
though I am not yet sure which suits my purpose better. I am still hoping to trap menus as well as simple exchanges.
Anyway, I can now read the replies programmatically, but they still land onscreen in a system dialog that I need to press OK to dismiss.
Is there a programmatic way to dismiss this system dialog?
What I am writing is some code that will execute my own USSD (ie 3rd party from carrier) on an android used without human interfacing (there is no one present to press OK). It's used more to send info to the server than to receive info back. I did this on an old Wavecom modem ages ago, so it has been a frustration discovering how difficult this was to do in Android.
In as much as the documentation is minimal, this app actually does a good job intercepting USSD responses:
https://github.com/alaasalman/ussdinterceptor
I need to remap the Honeycomb "Back" button to a button in my app (service) but after hours of search I'm still nowhere. The functionality must be there system-wise like the back button in ButtonSaviour (see market)
Most solutions for emulating the Back button are based on calling finish(). Not sure if it will work in my case since I have to call finish() from whatever activity I find on the foreground. I do manage to get the foreground application with the code
ActivityManager am = (ActivityManager) getContext().getSystemService(getContext().ACTIVITY_SERVICE);
List<RunningTaskInfo> T = am.getRunningTasks(5);
System.out.println("top activity: "+T.get(0).topActivity);
but I'm not sure how I should send a finish() intent to that..
I also tried the solution posted here http://www.anddev.org/throwing-simulating_keystrokes_programatically-t717.html but I couldn't get around the IWindowManager (has it been removed in Honeycomb?). That solution, however, looks interesting because with that I could send KeyEvent.KEYCODE_BACK from anywhere, anytime.
Please let me know which is the best way to implement this functionality SYSTEM-WIDE, i.e. from a service rather than from a specific application of mine.
cheers
PS: The app is meant to run on my own rooted tablet rather than for distribution to others.
Why does people spam the thread with advises about designs and good practices when the question clearly states that this will not be used for the market?!
Replacing android nav bar is sometimes required in some applications, even if no more than for own pleasure (or programmer satisfaction).
try from java Runtime exec
input keyevent 4
4 means back
button savior most likely uses hidden api, I had encountered that somewere, but don't remember now. When I will find it, I will post back.
The reason you're not finding an answer to this is that this is a terribly hacky way to do things and it indicates that there is something majorly broken with the design of your app. You should not be able to "call the back button," that doesn't make any sense at all. In fact, you really shouldn't change the behavior of the back button at all, users get really upset when you do that. If you have a service, and you need to send messages to an Activity, then use a messenger. But you should certainly not (and certainly cannot) be changing the behavior of other apps from your service. (This would indicate a major security flaw in the system, and would let you hijack someone else's UI, doing potentially dangerous, or at least annoying, things.)
Will the activity be open when you want to simulate the back button? If so, you could set up a timer inside your activity that checks for an exit file every 5 seconds or so. Then, from your service, create the exit file when you want to simulate the back press. When the activity sees that the exit file was created, delete that file and call finish().
As others have suggested, though, doing things this way means that you might need to rethink the app's design. What exactly are you trying to achieve?
I am developing an android app which makes no reference to the sensor aspect of the phone. At a certain pint the program sends an sms and then sleeps for five minutes. If I move the phone during this sleep period a dialog box displayed earlier reappears. I realise this is rather vague without code at this stage but to start with is this something to be expected. I am wondering if one of the broadcast listeners is being triggered by the movement but even if this is so I cant make the connection with the dialog box. Any pointers will be much appreciated.
Fist off, I would take care of the orientation change possibility by forcing the app into an orientation by using the option in the manifest file.
Second, I would look at what other apps are on the device that might have an affect on this functionality. Assuming by your question, your app uses BroadcastReceivers. If this is the case, provided your business logic permits, use explicit intents ( new Intent(this, )) in place of implicit intents and receivers. If this is not possible because of business logic, then perhaps using permissions to protect against accidental implicit intent receive triggers. Ref: http://developer.android.com/guide/topics/manifest/permission-element.html (its a good starting place anyways).
Without more info on your specific business logic or source code I can't go much deeper into the problem, but my first suggestion would probably give the simplest result. Just remember to set this attribute for each activity that this problem affects.
Steve.
"How do you hang up incoming calls (in Android of course)?"
First, I know this question has been asked and answered several times, and the response is always "you can't". But if we look in the market we get a few applications (all private software, no access to the source code... :-( ) that do this action, such as CallFilter, Panda firewall and others...
So... does somebody know how these apps do the hang up action, (or terminate, or disconnect or whatever you call it..)?
And other question, if the first don't get a response.. does somebody know how send an incoming call to the voice mail?
Of course, all questions are about how to do it programmatically. So with the voicemail question I know there's a flag in contacts that is used for that, but like I said, I'd like to know the programmatical way.
Thanks all!
Edit 1:
I have been seeing the LogCat traces using the application CallFilter and one trace seems to be interest, when it receives an incoming call, the PHONE_STATE is CALL_STATE_RINGING and fast appears one trace:
"05-03 19:32:34.416: INFO/UsageStats(78): Something wrong here, didn't expect com.android.phone to be paused"
and when CallFilter have done whatever do new trace "05-03 19:32:34.486:
INFO/UsageStats(78): Unexpected resume of com.android.phone while already resumed in com.android.phone"
appear, so i think CallFilter do something in one object com.android.phone, but i don't know how access to this.. any idea??
Edit 2:
I have performed at other times, and i don't see anymore the log traces above, so can be that the above may be that this does not mean anything.. i'm not sure..
the CallFilter application simply show one sec the incoming call, and then hang up.. how they do!!!???
I don't know how to hang up incoming calls, not sure if it's possible.
You can, i think, enter airplane mode programmatically, but it's a brutal method and really not advised. Changing such a setting should be done only by the user when he chooses to.
You may try using this API:
http://www.androidjavadoc.com/0.9_beta/com/android/internal/telephony/ITelephony.html
so i was wondering if its possible to for an application that i would write to be constantly running in the background and alter regular phone operations. For example this could be something like as soon as you receive a text from anyone you forward it automatically to another number. Is something like this at all possible?
Just to be clear I don't want to solve that particular problem through some other means, just want to know if apps can accomplish that.
Also if that is possible is it possible for an app that i write to alter more immediate and instant things, like an incoming call.
thanks all for reading this, and hopefully a helpful response :)
It depends on how far you want to go, but I would expect that what you want to achieve probably isn't possible.
The Android OS does reserve some actions and prevent them from being doing programmatically. For example, you can display the Dialer with a number filled in but the user has to press the call button to make a call. Similarly, you can display the SMS app with a message already written but it is up to the user to send the message.
I don't know for sure, but I assume this is for security. For example, let's imagine you could write an application which could start a call with no user interaction. I would release my Super-Handy-Dialer application which makes quick calls for you making you life easier, but what it also would do is wait until 2am and call my premium rate phone line every night for 3 hours.