I'm writing an application in which I would be able to turn off/shutdown/power off the phone.
From what I read around the net there is no way to turn off the device from an application. Is this true?
On rooted phones you could use the reboot -p command, but:
Users who have a rooted phone are very few, I think maybe 1-5%.
From what I read reboot does not unmount filesystems.
If there is no way to turn off the phone without using the root command, what is the correct procedure to do that using reboot -p?
Have you checked the way the power off dialog turns the phone off?. It's a system service, though, and it runs with root priviledges, but you could find something to make it work there
You mean this? I tried to use the method shutdownAfterDisablingRadio() but I seem that can be used only by the operative system and not by custom applications, is that wrong?
The thing that worries me is that into 16000 applications on the Market there is not one that turns off the phone without requiring root permissions.
Have you considered using "am" to execute the Android system call via shell from within your application? IANAP -- I don't know the ins and outs of using AM to execute system calls, but I *do* know that it /can/ do so.
They have an app like this already...its called "quick boot"
Power off your phone, power off into bootloader, and power off into recovery mode?
Zei said:
They have an app like this already...its called "quick boot"
Power off your phone, power off into bootloader, and power off into recovery mode?
Click to expand...
Click to collapse
For rooted phones, he wants to make it for non-rooted phones
Zei said:
They have an app like this already...its called "quick boot"
Power off your phone, power off into bootloader, and power off into recovery mode?
Click to expand...
Click to collapse
noob it doesnt power off it reboots
IConrad01 said:
Have you considered using "am" to execute the Android system call via shell from within your application? IANAP -- I don't know the ins and outs of using AM to execute system calls, but I *do* know that it /can/ do so.
Click to expand...
Click to collapse
Very interesting! I did not know this tool. I tried to start some intent but have not yet managed to turn off the phone.
Code:
am start -a android.intent.action.ACTION_REQUEST_SHUTDOWN
Starting: Intent { act=android.intent.action.ACTION_REQUEST_SHUTDOWN }
Error: Activity not started, unable to resolve Intent { act=android.intent.action.ACTION_REQUEST_SHUTDOWN flg=0x10000000 }
Zei said:
They have an app like this already...its called "quick boot"
Power off your phone, power off into bootloader, and power off into recovery mode?
Click to expand...
Click to collapse
JAguirre1231 said:
For rooted phones, he wants to make it for non-rooted phones
Click to expand...
Click to collapse
Exactly.
In any case, if there is no alternative, I'd still know about the correct procedure for rooted devices.
JD82 said:
In any case, if there is no alternative, I'd still know about the correct procedure for rooted devices.
Click to expand...
Click to collapse
Bump
__________________
Code:
Process p = Runtime.getRuntime().exec("su");
OutputStream os = p.getOutputStream();
os.write("reboot\n".getBytes());
os.flush();
Should work on most ROMs.
senab said:
Code:
Process p = Runtime.getRuntime().exec("su");
OutputStream os = p.getOutputStream();
os.write("reboot\n".getBytes());
os.flush();
Should work on most ROMs.
Click to expand...
Click to collapse
for non-rooted phones, su shouldn't work :\
senab said:
Code:
Process p = Runtime.getRuntime().exec("su");
OutputStream os = p.getOutputStream();
os.write("reboot\n".getBytes());
os.flush();
Should work on most ROMs.
Click to expand...
Click to collapse
Thanks for your reply.
How to run a command as root I already knew:
Code:
public static boolean runRootCommand(String command) {
Process process = null;
DataOutputStream os = null;
try {
process = Runtime.getRuntime().exec("su");
os = new DataOutputStream(process.getOutputStream());
os.writeBytes(command+"\n");
os.writeBytes("exit\n");
os.flush();
process.waitFor();
} catch (Exception e) {
Log.d("*** DEBUG ***", "Unexpected error - Here is what I know: "+e.getMessage());
return false;
}
finally {
try {
if (os != null) {
os.close();
}
process.destroy();
} catch (Exception e) {
// nothing
}
}
return true;
}
[...]
runRootCommand("reboot -p");
I would be interested to know the correct sequence of commands to execute to turn off the phone without the risk of corrupting the filesystem.
I do not think is sufficient to run "reboot -p". Or it is?
@xidominicanoix: I know su doesn't work on non-rooted phones. I was answering JD82 for the procedure on rooted phones.
JD82 said:
I would be interested to know the correct sequence of commands to execute to turn off the phone without the risk of corrupting the filesystem.
I do not think is sufficient to run "reboot -p". Or it is?
Click to expand...
Click to collapse
On linux, reboot is the same command as "shutdown -r -q now". According to this manpage (i'm not on my Ubuntu machine right now to check there):
When the shutdown time arrives, shutdown notifies all users tells init not to spawn more getty's, writes the shutdown time into the /var/log/wtmp file, kills all other processes on the system, sync's, unmounts all the disks, sync's again, waits for a second, and then either terminates or reboots the system.
Click to expand...
Click to collapse
So yes, reboot *should* unmount the filesystems first avoiding corruption.
Hi senab and thanks for your reply.
In Ubuntu I restart without problems using "reboot", but I read this about the android version:
The basic command to reboot the device is called "reboot". Merely writing reboot will perform a restart of the device. The command will call "sync" before rebooting the device, but will not unmount the file systems. This is up to you. If a full system is running on the device, this might prove to be slightly difficult, and many people just reboot and hope for the best.
Click to expand...
Click to collapse
I would not release an application that causes damage to the user's filesystem.
sync is *usually* enough to avoid corrupting filesystems.
When it isn't is when the space between the sync and the actual reboot allows something to mess with the filesystem. Without looking at the actual implementation details of the reboot command, it may, in fact, be done in a way that is actually thread-SAFE.
Actually, since this reboot command actually sends a signal to the kernel, I believe that it is, in fact, thread safe.
Of course, another way to deal with this is to do something like remounting all corruptable filesystems as read-only just before issuing the reboot command. That would include /data, /sdcard, and possibly (if using apps2sd) /system/sd. I believe that this is excessive though.
Note: the reason why shutdown and reboot aren't available without root is simple: You don't want some douchebag writing a malicious program that randomly reboots any phone that it happens to be installed on.
Hi geeks,
of course native ARM code compiling could be done with the full blown SDK+NDK, but honestly i found it way too much in some cases.
So i started investigating about a more simple cross environment.
There are many solutions out there, but IMHO the easiest way is to use the agcc wrapper written by Andrew Ross.
To make it comfortable, one of the prebuilt toolchains from the android source repository is used (gcc-4.4.0).
The environemnt will create dynamically linked executables, so we will link against the bionic libs here.
If you don't know what i'm talking about, follow the links at the bottom or step over to use your phone as a phone.
In fact this solution is not re-inventing the wheel, but more a walk on a practical trail for native development.
Everything could be easily put together and equipped with the essential source packages, you get a very handy solution to compile simple c-code for your Android platform.
Only minor tweaks had been done to the agcc wrapper, and you might do as well to fit it to your needs.
Grab the complete package here:
http://dl.dropbox.com/u/8815400/android-agcc-4.4.0.tar.gz
Everything was choosen to work nicely for the Milestone platform.
To make it the most compatible i decided to use the includes and libs from the eclair branches.
It might also work for other devices, but some tweaks could be required then.
To start development for your platform you'll need a more or less up-to-date linux OS on your host.
Minimum should be:
Debian 5.0
Ubuntu 10
...
Simply extract the archive to a directory of your choice, user rights should be O.K. (the default directory of the package would be /opt).
To make everything work properly, it is required to modify the $DROID variable insdide agcc wrapper to point at your working directory (e.g. /opt/android).
It is also required to add the path to the android toolchain to the PATH variable of your system. There are different attempts to do so.
E.g. on Debian 5.0 add the following line at the end of your .bashrc:
Code:
export PATH=$PATH:/opt/android/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin
To check, if the toolchain is working, create a simple hello.c like this:
Code:
#include <stdio.h>
main()
{
printf ("Hello World!\n");
}
Compile the code on your host:
./agcc hello.c -o hello
The result is a 32-bit ELF executable for ARM. Transfer the binary to your platform and make it executable.
You might use adb to do so (usb debugging needs to be activated on your device).
Attach the Milestone to your host and type:
./adb start-server
./adb push hello /data/local
./adb shell
Now in the shell on your device type:
$ cd /data/local
$ chmod +x hello
$ ./hello
There you go!
It is also possible to compile even more complex tools using MAKEFILE.
Some details might be discussed here, if there's some interest.
Useful links:
The essential packages had been taken from source packages over here:
http://android.git.kernel.org/
Also some libs had been grabbed from this project:
http://gitorious.org/rowboat
Original agcc wrapper could be found here:
http://plausible.org/andy/agcc
Further information:
http://labs.embinux.org/index.php/Toolchain_For_Android
http://android-dls.com/wiki/index.php?title=Compiling_for_Android
http://elinux.org/Android_Tools
Happy hacking!
scholbert
Examples ...
You'll find some simple c-code examples for console here.
Most of them would require root access.
A good location to store them locally on your device is /data/local.
omapinfo v.1.0.0 (reads out some very special registers )
Code:
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/mman.h>
int main() {
printf("omapinfo v.1.0.0\n");
int fd = open("/dev/mem", O_RDWR | O_SYNC);
if (fd < 0) {
printf("Could not open memory\n");
return 1;
}
// map L4 core registers @ 0x4800 0000 to memory
volatile unsigned long *L4_core_base;
L4_core_base = (unsigned long*) mmap(NULL, 0x10000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0x48000000);
if (L4_core_base == MAP_FAILED) {
printf("Mapping L4 core base failed\n");
close(fd);
return 1;
}
// read some register values
printf("STATE : %8x \n",L4_core_base[0x22f0/4]); // check HS bit, boot mode
printf("PKEY0 : %8x \n",L4_core_base[0x2300/4]); // read out RPUB_KEY_H_0
printf("PKEY1 : %8x \n",L4_core_base[0x2304/4]); // read out RPUB_KEY_H_1
printf("PKEY2 : %8x \n",L4_core_base[0x2308/4]); // read out RPUB_KEY_H_2
printf("PKEY3 : %8x \n",L4_core_base[0x230c/4]); // read out RPUB_KEY_H_3
printf("PKEY4 : %8x \n",L4_core_base[0x2310/4]); // read out RPUB_KEY_H_4
// map L4 wakeup registers @ 0x4830 00000 to memory
volatile unsigned long *L4_wakeup_base;
L4_wakeup_base = (unsigned long*) mmap(NULL, 0x10000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0x48300000);
if (L4_wakeup_base == MAP_FAILED) {
printf("Mapping L4 wakeup base failed\n");
close(fd);
return 1;
}
//read CONTROL_ID
printf("CPU-ID: %8x \n",L4_wakeup_base[0xa204/4]);
close(fd);
}
Cheers,
scholbert
I'm sorry but I don't understand what the end result is.
My brain ain't big enough to figure out which problem this is solving.
Hi zeppelinrox!
zeppelinrox said:
I'm sorry but I don't understand what the end result is.
Click to expand...
Click to collapse
The end result is a very lightweight cross environment to write simple progs for your android device (c-code based).
The package could easily be installed and run on a netbook with linux OS.
Nothing more nothing less..
zeppelinrox said:
My brain ain't big enough to figure out which problem this is solving.
Click to expand...
Click to collapse
You don't need a big brain and there's also no specific problem to solve.
As i tried to point out, i needed this kind of tool to compile some very basic command line tools.
Pushing the whole Android SDK+NDK was way too much for this.
I did not find any package like this, so i thought i put it together myself and share it.
Of course this is mostly for fun, but could be used for hardware-oriented programming and similar stuff.
By using the memory mapped register access, some kernel settings could easily be overridden and this maybe useful for testing new drivers and stuff.
E.g. i'll try to compile i2c-tools next... let's see if it works .
Have fun!
scholbert
This is only practical for small native utility.
YongkiCA said:
This is only practical for small native utility.
Click to expand...
Click to collapse
That's what i said....
BTW here's another small native utility!
Look at the project page for info.
http://www.lm-sensors.org/wiki/I2CTools
Regards,
scholbert
Thanks for this thread scholbert! Thanks for taking the time I haven't tried this yet, but I may later, but right know acknowledging your efforts! Wonderful job
Phone:motorola charm
Kernel:2.6.29-omap1
# omapinfo
Code:
omapinfo v.1.0.0
STATE : 21b
PKEY0 : 62b63f1d
PKEY1 : 708c4d79
PKEY2 : cbb457fb
PKEY3 : f6272e49
PKEY4 : 4f2e156f
CPU-ID: 4b7ae02f
Hey Im trying to implement a reboot in my app for root users but the code below does not work. The SU prompt pops up but when i allow the action nothing happens, it will not reboot. Any ideas why?
Code:
try {
Runtime.getRuntime().exec("su");
Runtime.getRuntime().exec("reboot");
} catch (IOException e) {
}
Iv also tried this but it does not work either same result, su prompt shows, i allow it and it doesnt do anything.
Code:
Runtime.getRuntime().exec(new String[]{"/system/bin/su","-c","reboot"});
I'm a new to Android development and am writing an application that should execute Linux commands on button press. However, for whatever reason, I can't make any of them work.
Code:
public void getSU(View view) {
try {
Runtime.getRuntime().exec("su");
} catch (IOException e) {
e.printStackTrace();
}
This works to obtain SuperUser privileges for the app, but any other commands like "cp" or "mv" just plain don't work.
Final note: I do have Busybox installed and properly symlinked.
Does anyone have any ideas about what I'm doing wrong, or am I committing some sort of egregious Android error?
Making a screen capture application in c# and while doing so i discovered a.. bug?
Update: been classed as a DoS by google. be cautious of the PC and android apps you use as one spamming "screencap" at boot could render a NON rooted device useless.
Fix: none available yet, how could we stop the same command being executed hundreds of times on different threads?
while using
Code:
new Thread(() =>
{
Thread.CurrentThread.IsBackground = true;
Process screencap= new Process();
ProcessStartInfo screencapinfo= new ProcessStartInfo();
screencapinfo.WindowStyle = ProcessWindowStyle.Hidden;
screencapinfo.CreateNoWindow = true;
screencapinfo.UseShellExecute = false;
screencapinfo.RedirectStandardOutput = true;
screencapinfo.FileName = "cmd.exe";
screencapinfo.Arguments = " /c \" adb shell screencap -p /sdcard/screen.png & adb pull /sdcard/screen.png\"";
screencap.StartInfo = screencapinfo;
screencap.Start();
}).Start();
while looping a thread containing "adb shell screencap -p /sdcard/screen.png & adb pull /sdcard/screen.png"
after 10 seconds the device is glitching, 30 seconds the device is unusable, after 1 minute if you take out the usb the device reboots instantly.
Ive attached a logcat of the processes running.
Logat of screencap
Additional device info-
manufactur: ZTE
model: blade v0720
android version: 6.0
kernel version: 3.18.19
root: no
custom recovery: no
unlocked bootloader: no
Provides a DoS style attack, further updates will be posted HERE on the official google bug tracker