So, as the title describes, I'm looking for a way to boot an Android device when the power charger is connected. We are making dedicated devices, in kiosk mode, and are using the Android Management API to setup everything on the device.
This covers most of our requirements, like preinstalling apps, disabling everything else, hooking it up to Managed Google Play, getting device reports etc... But for this power thing, I can't find any solutions in the docs.
The problem is that the physical power button isn't accessible to the user (don't ask my why :)), and when the battery drains they have to be able to power it up again, without unscrewing the case to get to the physical button.
I know this can be done in different ways, but I can't find anything that would work with Android Management API. I'm looking at this "fastboot" approach, since it seems pretty simple https://source.android.com/devices/bootloader/unlock-trusty#off-mode-charging
Initially, I though I could run this somehow using the devices/issueCommand endpoint https://developers.google.com/android/management/reference/rest/v1/enterprises.devices/issueCommand, but that seems to support only some predefined commands like: LOCK, RESET_PASSWORD and REBOOT.
Maybe I'm just missing something. If someone has another approach in mind, please share.
If it's any help, we also have the Android Management API hooked up to the PubSub API, and a topic there that the pulls the reports of the devices. Theoretically, I could listed to the "power connected" event there, and run some command on the device. But again, the problem is how to run this command on the device remotely.
Maybe a solution would be to make another app that will run as a background process that runs this command. I guess I would need to add it as "receiverActivity" in the policy. But the same problem remains... how to invoke this activity from the Android Management API.
The bottom line is that this needs to be fully automated. Running this command on each device manually is not an option.
Also, worth mentioning, this is an Ionic app. Although it's probably not impossible, we would like to keep this logic outside of the app itself. Ideal solution would be just to run some adb command remotely using the Android Management API.
Or maybe there is a good 3rd party app that does this, and I could install that app in the policy and invoke it somehow.
All suggestions are welcome. Maybe there is a simple solution that I've missed.
UPDATE AFTER COMMENTS: I'm not looking how the actual app can do this. I'm looking for a way to execute some "native" command when the device is initially setup from the Android Management API policy. So it should execute only once. When it sets up everything initially. It should edit some file on the device (or run some command) to enable this feature. Later, it shouldn't care if the device is turned on or not, or what apps are running on it. There are a few different ways how to do this suggested here https://android.stackexchange.com/questions/20021/automatically-power-on-android-when-the-charger-is-connected. I'm looking for a way to trigger one of these commands when the device is setup initially (only once). In other words, this should execute only when the device is enrolled. It shouldn't care about any apps running on the device.
So the "free" way to do this is using the fastboot commands. But from the AMA API this is currently not (and most likely ever) possible. This problem will always be hardware specific, since the bootloader is controlling the boot process, and the bootloader is custom made for each device.
There are options for different manufacturers though. Look into OEMConfig apps (which you can get in the Play Store for Work or from the manufacturer themselves).
Samsung has it's KNOX API, and the paid ProKiosk mode supports controlling Power Control.
Regarding the post in your question solving the problem, you will not be able to modify any files in the system since that's restricted to root. This will also never work for Managed Devices.
You could "half-automate" the process by setting up a raspberry pi or some other device with a script that waits for fastboot devices to get connected and executing the command. That way you just visit every device and put it into fastboot and plug in the device and you're off to the next one.
For clarification: adb and fastboot are two entirely different things. Fastboot is running while the device is in it's bootloader. Adb is running while the device has started android. It should technically be not possible to execute fastboot commands while android is started since the bootloader has already exited.
Related
Is it better to test your application via USB (directly connecting your phone to the Android Studio) or by downloading the APK version of your app. I've been using emulator and it's really time consuming because it keeps lagging on my laptop. I wanna know which is faster and safer?
Connecting your phone via USB is always a more reliable and faster option (even if u don't consider the time it takes to copy and paste your APK file from pc to phone) You can also do a activity restart rather than restarting whole app this way which is less time consuming. You can even specify a certain activity to launch for testing. It also provides lots of Monitoring options like device monitoring, Network Monitoring, Database Inspection, Layout Inspection and so on.
Objective
I'm developing a custom app for internal use on a rooted android mini-pc.
The goal (between others... so...many...others...) is to be able to turn on and off a tv using the serial port embeeded on the tv.
I'm using an FTDI UART RS232 serial usb cable for it.
Status
The application is working right now, using an android library (serial-driver) i can communicate with the tv, but the problem is that the device asks for permissions every install (and sometimes, weirdly, again on the same device), so it needs to be improved.
Issue
Since the device doesn't have mouse or keyboard by default, when this happens someone has to click the buttons, and since the device is normally hidden behind the screen, it can be really annoying.
My two bits
This problem, i feel, can be solved by two methods, but i still haven't been able to make them work.
Since the device is rooted, i might be able to modify an unknown (to me) parameter that allows me to bypass the permission request. For this i have tried to make an intent filter for the usb device, and to rewrite the interface that controlls this behaviour, both without success. Is there a way to make this android version more lenient about permissions?
I use for other reasons SuperSU inside the app, so i can use the full width of the might shell power. Using this i've been trying to send commands manually to the device (/dev/bus/usb/00X/00Y), but this haven't worked. My theory is that it's beacuse of the permissions of the device path, but even doing an unhealthy chmod 777 i cannot have them working.
So, that's my problem right now. I hope someone here can help me.
Additional data
Running: Custom Android 4.4.2 (Cannot be changed)
Needs to be doable solely from within the apk (but it can use shell commands)
We don't have the manufacturer signature to install it as a system app
We can use only one app, so i cannot have another one to move this one to /sys/apps, and i don't know if an app can do that to itself.
using Busybox stty -F /dev/.../ returns "Operation not permitted"
I have a hobby android app idea that basically just uses Android's sensors and logs them long term for several days (external battery). The sensors needed are in $200 phones, and I can get ones for under $100 if the screen doesnt work.
My question is, is it pretty easy to make an app that starts and loads via debugging, keeps running when disconnected and when I connect I can extract the log file, or would this so be difficult I would be ahead just to spend the extra $100?
As mentioned, turning on USB debugging without the screen isn't possible. You can't enable USB debugging over USB for security reasons, so your only option would be to use hardware commands to put the device in firmware download mode (presumably it will have a way to do that), then load a custom OS which allows USB debugging by default.
Personally I think that's more than $100 worth of work, so I'd just go with the working device. Then you can use it for other stuff down the line.
Alternately, you can probably get a replacement screen for not too much, and for most devices changing the screen is relatively easy. I'd look into that option as well.
The first barrier you may find is that you must activate the Developer Options in the settings and the USB Debugging. And when you connect to the computer, you must accept that cumputer as the Debugger.
I don't know if it's possible to do it without a working screen.
App will keep running & yes you can can extract the log file when connecting again.
But the problem is in the first step. if your screen if not working, then how would you add your workstation as a trusted device in your "display not working device". I doubt if there is such way, because we need to do several things like switching on developer options, usb debugging etc.
I hope you got your answer.
A client is releasing a product (employee training/guide), and have contracted us to create a companion application for the Android OS.
Being a global entity that routinely has employees in areas without network access, they are releasing their product via CD.
They would like the ability for their users to optionally install this companion application to their personal Android devices (their own cell phones/tablets etc).
Since some will be in areas without network/internet access, they would really like the ability for an installer to be on this CD to install the Android application.
I am somewhat familiar with being able to install applications onto Android using ADB, but was under the impression this would require root.
Is there a method by which an application could be installed from a computer, in such a way that a non-tech savvy user could use it (IE classic installer application, just different target).
Don't want to be asking these people to root their devices, install ADB and so forth.
I think the ADB route is asking for trouble as you're reliant on the right drivers being present on the machine. Sometimes it'll work fine, sometimes it won't.
You could potentially provide the APK on an SD card for the phone, but there's no consistent app to use to open the APK from the phone, so that's unlikely to be any better.
Surely if they are using phones they do SOMETIMES have network access? I suspect you're going to struggle to find a nice solution, and although not ideal maybe better to just require that users install the app when they do get a connection?
Going down that route, you could provide the APK via email, a web link, Android Market, or any alternative market.
Do remember that the cost of a solution isn't just building it, but the support too. My sense is when you're looking at the possibility you might have to help users install the right driver, you need to look for a better solution as that's the road to hell.
I am somewhat familiar with being able to install applications onto Android using ADB, but was under the impression this would require root.
No.
Is there a method by which an application could be installed from a computer, in such a way that a non-tech savvy user could use it (IE classic installer application, just different target).
There is the Sideload Wonder Machine, but I haven't tried it, and it is Windows-specific. It also would still require adb-compatible drivers, which the user may or may not have installed on their Windows machine.
Otherwise, there are no network-less options at this time that I am aware of.
Well, there is still another option that nobody mentioned, which does not involve dealing with USB drivers. BTW, this is only a Windows problem, in most Linux distros ADB works out-of-the-box.
This option is through WiFi:
configure Tethering & portable hotspot
connect the computer to the hotspot
start some kind of web server on the computer (apache will do, probably microapache could be of help if using Windows)
on the phone open the URL containing the APK (the IP was given by the hotspot)
download
install
Voila !
I am looking generally in to Android development.
I keep seeing information on root however I am unclear how this relates to general android app development.
I understand that there is an emulator however when I get to actually test the software on a phone does that phone have to be a rooted device or is this only required if you wish to edit the core features of the os?
Finally are there are any development disadvantages to rooting the device such as that is no longer behaves like other android phones I may deploy too?
Thank you
You don't need root to develop for Android.
The easiest setup is to run Eclipse with the Android Development Tools installed. Then, you can debug your application in the emulator, or register your phone with the SDK and debug directly on your phone. The only thing you need to do on your phone is check the development mode under Settings -> Applications
I can understand the allure of having a rooted device, but I can't really see a reason for changing the bootloader or os binaries. You can, however, change most of the default applications (including the Home application) with other applications available on the Market. For instance, OpenHome is about $5 and allows you to replace the home app, add themes, and replace many of the core apps (e.g. clock).
Rooting is only required, if you want to play around with advanced features or update your firmware, etc.
If you develop your software using the Android SDK you will be able to use it on your phone regularly (as long as you have the corresponding version). No rooting needed.
I have never heard of any problems according to your concerns. But I cannot deny that there are none. Though I personally don't expect that there are any problems with rooted phones.
On the Nexus S running Android 2.3, the /data folder is not visible in the DDMS File Explorer or the ADB shell, but it is visible in the emulator. This occurred with debug turned on in both the manifest and on the phone. I confirmed that debug mode was properly enabled by successfully stepping through the app using breakpoints and also by receiving messages from logcat.
Not being able to see the /data folder means that you will not be able to get your application's private data.