I'm working on a hardware/firmware/Android app project where the Android (in this case a Nexus 7 tablet) connects to a custom hardware platform via USB. The Android is in Accessory mode, which means the other end of the wire (the Host) supplies power to the Android. The hardware has a dedicated 5V 2A switching supply for the USB connector so there is plenty of current available for the tablet.
When the Android is plugged in to the hardware, it reports that the battery is charging and it requests 500mA from the USB connection (for those who don't know, the USB protocol requires the device to inform the host of its current requirements). The hardware easily provides this current and the 5V stays rock-solid.
Despite this, the charge level never changes as long as the device remains in use. This application uses the tablet in what is basically a kiosk mode - the display stays on at full brightness continuously. Sleep the tablet and the battery charges, but leave it on and there is no reported change in the battery level.
The only explanation I can think of is that the Android's power supply circuitry cannot simultaneously handle the current requirements of both full operation and battery charging. But I wonder if this is a conscious decision based on expected power availability, and if there may be some sort of configuration option in the OS that would inform the OS that more current is, indeed, available. Perhaps then the OS would request more current from the Host and have enough to both charge the battery and run the device at the same time.
Anyone have any data on this? Thanks!
When I started a company that designed battery chargers for cell phones and the like, I didn't realize that it took more than providing a voltage source to a USB connector. At first we encountered having to provide different voltages on the data pins to tell the connected device how much current it could expect to draw. Now there are several manufacturers of USB interface ICs that do all the dirty work of handshaking and act as current limiters as well. Most smartphones today draw an average of 1A from the 5V USB bus. Some can, and will (especially Apple products) draw up to 2.1A if allowed. Most tablets run in the range of 1.5A to 2.1A. Any of the above will run in a mode drawing lesser current, if the device finds the charger unable to supply the full current. This will sometimes, as in your case, allow the device to either run or charge, but not both. In some cases, the available current isn't enough to maintain a charge level , and the device's battery slowly discharges, even though it's connected to a charger. If you Google "USB charger data pin voltages" you can see how to tell your device it can draw more current. The proper method though would be to use a controller IC something like TI's TPS2511 "USB Dedicated Charging Port Controller and Current Limiting Power Switch". Hope this helps and isn't too too late.
Related
I see many reasons why an app should behave different if the device is connected to a power supply, via USB cable ore otherwise.
For example, with power on and effectively charging, it could be used as an image viewer, which would be prohibitive if running on battery.
So, how to let an app check if power supply is on, and, if the battery is charging or still running low (due to other power consuming processes or perhaps just because it's old and leaking).
Edit: in view of the comment that points to a method to get noticed of changes of power supply:
This is valuable, maybe for other applications, but I'm asking for actual power supply minus battery need for recharging.
Android 4.3 added new 'software' feature that keeps Wifi get scan results even if Wifi is off. It says that this mode consumes very low power.
My question is how this technically done, and how much power saved compared to just enabling Wifi?
The logic is simple: driver and wpa_supplicant is never unloaded from the memory, unless scan-only mode is disabled in WiFi advanced menu via Scanning always available option.
In terms of power consumption - the numbers will differ for every WiFi solution, but according to my experience (being an WiFi engineer for one of the Android OEM's for last 4 years), the difference is minor. Below is an example of some average consumption numbers:
Phone is awake, WiFi disabled: ~220mA (depends on many factors, just an example)
Phone sleeps, WiFi disabled: ~5mA
Phone sleeps, WiFi enabled (sure, applies to Scan-Only mode as well): +5mA
So, if you are an active user, turning Scan-Only off will not give you huge power savings. On the other hand, if the phone usage is somewhat passive, turning this option off could give some extra battery life.
Personally, I keep this option on, since I prefer immediate WiFi availability when I enable it over that minor battery win.
I have the bluetooth mac-id of the target device. The bluetooth however is in hidden/not visible mode.
Both phones are android. (Non-root).
I did my research and I * know * that I can CONNECT to a device (in most cases) if I know the mac-id, however I want to just scan for proximity and NOT connect i.e. if the target device is in bluetooth range and I know its mac-id, can I * just * know if its in proximity (or in loose terms, scan for it?)
The short answer is no, you cannot discover undiscoverable Bluetooth devices.
Having a device in undiscoverable mode is a security measure implemented by manufacturers to prevent abuses such as device tracking. This make a standard bluetooth adapter (such as yours) completely unable to state whether an invisible/undiscoverable device is close or not.
However, it turns out this kind of security is not optimum and has been broken recently. You can find here Michael Ossmann's work on Ubertooth, a small Bluetooth adapter able to detect undiscoverable devices. You can find here a great presentation of what this is, build this dongle using open source plans and even buy his dongle.
EDIT :
It is possible to know whether a bluetooth device is around, even if he is in an undiscoverable mode, by knowing his full MAC address in the first place.
The technique is to try a PAGE request, sending all the 6 bytes that are composing the seeked Bluetooth host MAC identifier. A PAGE request allows one to connect with a Bluetooth slave when knowing his BT ADDR. Devices that are in undiscoverable mode does not respond to inquiry scan (device discovery intent), but they do respond to page scan which is used by a device wanting to connect to an another previously known device.
You might be able to do what you intend by using Bluesniff, a security proof of concept allowing you to discover hidden devices. It might support page scanning.
Note that this is to be taken as an educational resource, and I do not encourage this kind of practice in a commercial application.
Can Android be woken up from sleep by a peripheral device such as an arduino microcontroller?
Additional details:
I am looking to save power by putting the Android device to sleep and having the low-power peripheral device wake up the Android device only when an "interesting event" occurs (e.g. abnormal sensor reading)
The device probably cannot be woken from true CPU sleep (which is a level beyond having the screen off) by ordinary software/signalling means.
However, enabling a 5v power source to the USB jack probably will wake up the majority of devices which can charge via USB.
If they are connected to an actual USB host (vs a simple power supply/charger) my suspicion is that they would not enter CPU sleep at all. Both the android accessory kit and IOIO schemes have the external microcontroller functioning as a USB host and providing power, so it's likely sleep would not be an issue. Or if you need to save power, you could probably make the externally sourced power switchable.
Two additional possibilities to consider are using a partial wakelock to prevent CPU sleep, or setting alarms to wake the device periodically so that background code can check for some event.
Just tested this. I have some USB thumb drive OTG adapters and when I connect the adapter without thumbdrive, the phone woke up. I think it has something to do with two pins on the micro USB socket, pin 5 and pin 4 tight up together.
Adapter I am talking about:
Pins:
I want to know the difference between the two flags
BatteryManager.BATTERY_STATUS_DISCHARGING
And
BatteryManager.BATTERY_STATUS_NOT_CHARGING
I developed an application that uses these two flags, and I expected to see "discharging" when I unplugged the phone from the charger, but instead it simply says "not charging".
What is the difference between the two ?
from : Battery is low. Charging current not enough...Is there intent before this message is shown?
Some devices (tablets?) consume more power than what can be provided via USB port.
I can find no clear definition of the two in the Android APIs or elsewhere online.
My best guess is that BATTERY_STATUS_DISCHARGING indicates that the device is actively draining power, while BATTERY_STATUS_NOT_CHARGING indicates that the device is plugged in but is not receiving enough power to actually charge -- for instance, if it is plugged into a low-power USB port.
However, there are other reports from developers that certain devices never return BATTERY_STATUS_DISCHARGING, even when completely unplugged: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-reviews/1AjyPYt0tQs
In particular, the Nexus 7 2013 seems to have this bug (confirmed by personal experience): https://code.google.com/p/android/issues/detail?id=124768.
Presumably, you ran into a similar bug.
The other option for not charging is simply that the battery is full, hence no need for charging or that there is no battery at all.