I'm a newbie in both Java and Android and I'm trying to figure out how to do the following action. Btw, I find that the official Google Android documentation is NOT for newbies and would like any referral to something a bit more... non-native programmer friendly.
Ok, here goes:
I would like to turn on/off Bluetooth automatically when I plug in/unplug the phone - pc or ac.
So, I have found the following components:
BatteryManager: Seems like using the ACTION_BATTERY_CHANGED intent is the way to go, and setting up a broadcast receiver for when this changes. Is it correct?
I've also found BluetoothAdapter and within that, there's the enable() method. Which says: "do not use without explicit user action to turn on Bluetooth." - is plugging in the phone a explicit user action? Is this the right thing for me to use? The same goes for disable(), of course.
Also, the BroadcastReceivers I've seen examples for in the Internet(s) only show me how to launch an intent - usually to open a new activity. I assume I can have the Broadcast Receiver launch a method in which I will turn bluetooth on and off? Can an intent be a method, and not just activity?
Any help would be appreciated!
BatteryManager: Seems like using the ACTION_BATTERY_CHANGED intent is the way to go, and setting up a broadcast receiver for when this changes. Is it correct?
Yes, that is one way to monitor things like when a charger has been connected (including plugging to a USB port with charge capability). You can also use ACTION_POWER_CONNECTED.
is plugging in the phone a explicit user action?
NO - most definitely not unless you create a pop-up asking for the user's consent. To quote the docs for the enable() method...
Bluetooth should never be enabled without direct user consent. If you want to turn on Bluetooth in order to create a wireless connection, you should use the ACTION_REQUEST_ENABLE Intent, which will raise a dialog that requests user permission to turn on Bluetooth. The enable() method is provided only for applications that include a user interface for changing system settings, such as a "power manager" app.
When I plug my device to charge, 9 times out of 10 I don't want it to do anything but charge. If I had your app installed on my phone and found out it was enabling Bluetooth silently and without my knowledge, your app would be un-installed straight away.
There are known security issues with Bluetooth and, depending on user settings, you could put somebody's device at risk if it is enabled without their knowledge.
Can an intent be a method, and not just activity?
No, an Intent is part of a messaging system. See Intents and Intent Filters. Yes, I know it's not very 'newbie-friendly' but Android is a complex beast and if you really want to program successfully for it you've got to read this sort of stuff.
Related
Android M has a new feature called App Standby where an app is put into an idle state when it's not being utilized (see docs) and, among other things, its network access is disabled.
I can't seem to figure out a way to determine when the app goes into and out of this state (via a broadcast intent or something of the like) and I really need to as my app relies on having network periodically to check the status of a server.
Can someone help me figure out how to determine when my app goes into and out of idle state?
I've been digging through the M preview 2 source and down through the calls of $ adb shell am set-inactive it appears that there's a AppIdleStateChangeListener but it appears to only be used internally to Android and isn't exposed to us lowly developers who want to know when our apps can use the internet :-(
So far, it appears that when ACTION_POWER_CONNECTED is broadcast, all apps come out of standby...this is a potential workaround if Google doesn't expose something for us before release.
I have a requirement where I would want to initiate and manage GSM calls (Like the ones we make via Phone)
I will be connecting to a GSM Module/DTMF Module (context: robotics) via this method and would be sending instructions via DTMF tones.
I don't want to open up the phone dialer via an Intent with tel: data, would rather want to manage the telephony myself.
First thought that the system might not allow a third-party app, without a signature matching system's signature, to do telephony stuff, but then I wondered how some of the apps available in the market are doing it. (I'll attach links as soon as I find suitable ones)
EDIT: The apps that I had seen, were launchers and call manager apps, and once installed, had replaced my default phone apps (and thus were making calls instead of the default phone app doing it)
EDIT: I have found this question asking something similar, and also has an answer: Android Dialer application. I'll try this out and post back if I get any success.
Any pointers will be greatly appreciated.
Before someone tells me this cannot be done, I have done plenty of research on why on process cannot interfere with one another and under what conditions this is possible. Our problem is that the Bluetooth support between devices is inconsistent and the solution on some devices is to stop the existing Bluetooth service and run a separate app (BlueFTP) which is then able to listen on the freed port and manage OPP communication.
android.permission.RESTART_PACKAGES permission plus ActivityManager.restartPackage() doesn't work as it simply restarts the offending package.
Process.killProcess does not work for the obvious reasons (read the API)
android.permission.KILL_BACKGROUND_PROCESSES permission plus ActivityManager.killBackgroundProcesses() is ignored because (I believe as per the API) the Bluetooth app is not considered a background app and therefore not eligible to be killed.
Currently if a client is having an issue with a specific phone, we get them to go to the running apps and force stop the offending OPP Service before refreshing BlueFTP so that the port listener starts. The offending service has more than one possible name depending on the phone and Android version.
So. The process is currently manual but I was hoping there would be a way to achieve this via code mirroring the force stop option in settings. A lighter option could be to assist in opening the settings for that service rather than needing to explain to clients how to get there, but I'd prefer a complete solution if one is available.
Note that while our the dev phones have root access, the client phones will not.
You can use implicit intents for your services in other apps to close them. It wouldn't need extra permissions as well, unless your service enforces a permission for it's access.
Oh, I overlooked the fact that it's a third party app. In that case, you can't really do much. Sorry.
I tried posting this on the Android Developers list and didn't hear anything - maybe some of you have insight into this!
I'm working on an app that should have the ability to disable incoming calls for a user-specified period of time. It should work much the way a "DND" (do not disturb) button works on an office phone.
I've looked over the SDK, and I can't find any way to send phone calls to voicemail or disable the big incoming call screen without putting the phone in airplane mode. That would be OK if I could keep Bluetooth enabled. (I'd like the user to be able to listen to music via a Bluetooth headset while phone calls are blocked.)
In summary, any of the following would work if I could do them from my app:
Programmatically send all calls to voicemail (like a "DND" button) this would be ideal since it would still be in the call log at the end of the "do not disturb" time.
Intercept the incoming call in my app and bounce it.
Disable all radios but Bluetooth and Wi-Fi - This has the disadvantage of losing the call log.
Prevent the built-in phone call app from displaying its incoming call screen (I can disable the ringer and vibration) even though the call is received
Is any of these possible? Or maybe another approach I haven't thought of?
Just a side note: For Android phones to be the best possible productivity tool, it should be possible to use a device for email/Internet/apps without receiving constant interruptions from calls. Humans have a significant context-switch time.
As a security measure, the SDK does not provide APIs to handle incoming calls. Apart from cutting off the network radio and going into a semi-airplane mode (Option 3), I don't see how this is possible, IMHO.
I write an android app for athletic examinations in my corporation.
Specifically, in one mile run examination, examiner person needs no interruptions at all, because he will loose 400m checkpoint passes of examinees.
No phone calls, SMS, messages, alarms, calendar notifications, nothing, nothing, nothing.
Until now, I think the easy way: a dialog which informs examiner to go to flight mode. It doesn't cover all these interruptions, but it is the best solution so far.
Is something better out there?
That kind of interruption is simply unavoidable and out of your app reach. Android system receive and emit all kind of interruptions (events) from notification to low battery. Every event has its own app which respond events using intent-filter, broadcast listener, etc. so you can't really have access to all apps that wasn't yours.
Simply put, no you can't. Your Airplane mode solution + No disruption mode might be the best option.
Sounds like you could use the Android Service feature.