Develop Reference

Effect of Frequently executing dumpsys on the Android system

I execute dumpsys meminfo every 2 seconds to sample memory usage of particular Android applications. Sometimes, the application (or even the emulator) crashes while the application is doing dumb things (e.g., rotate the screen back and forth). So, I want to understand how does "executing dumpsys meminfo frequently" affect the state of the whole system.

I have a memory monitoring script that executes dumpsys meminfo a couple times a second and writes the info to a file and it almost never crashes, but I always test using physical devices.
It may be that your emulator just doesn't run fast enough to handle it. Android emulators are incredibly slow.

How will adbd and monkey runner affect the performance of the android device

I am doing some performance testing of the device and want to use the adb and monkey runner to automate andorid UI*. The concern is the background process would affect the actual performance of the device.
Questions are:
Through what mechanism does monkey runner work?
How much the performance* will be affected by the services of adb and monkeyrunner running on the device?
*sending command via adb to run monkey runner and pull the logcat.
*hardware performance: cpu mem power

The MonkeyRunner intro page has a good description of how MonkeyRunner works. Based on my personal experience using MonkeyRunner shouldn't impact your app's performance, however MonkeyRunner itself can sometimes be slow, so I wouldn't ever use MonkeyRunner to measure my app's performance.

Android debugging via Bluetooth

I was using earlier adb to debug Android applications over wifi, usb - it was great.
Right now I am wondering if it is possible to connect phone with adb via bluetooth.
I did a quick research but didn't find anything - have you tried it already ?

It is not supported by the current adb software, however you could probably make it possible if you have a rooted device (or possibly even if not - see below) either by modifying adb or by using bluetooth to tunnel a channel it does support, such as tcp.
You would need to obtain the source for the adb program - the same source is used to build both the PC and the device versions. First step is to just build it with unmodified functionality, which may take a fair amount of build system modification unless you do so as a part of a complete android source build (the way it was intended to be done)
Then you would modify it to add a bluetooth channel as an option and install it on the device (why you need root) and in your path on the PC. You'd think you could run it from an alternate location on the PC, and you likely can as long as you use it from the command line, but if your fire up DDMS it may kill off the running adb server and launch a new one using the default in the path, so ultimately you'll have to put your modified version there.
IF you can already get your device to accept adb connections over tcp (possible with root, perhaps possible in some cases without) there is another option, which is to not modify ADB (or at least not modify the device side) and instead come up with something running on the device which accepts bluetooth connections and forwards the traffic via local loopback to the tcp port on which the stock adb is operating. This would save the trouble of having to rebuild adb.
If you have some kind of tethering or similar network-over-bluetooth solution, you might even be able to leverage that to carry adb-over-tcp-over-bluetooth without writing any code.
Finally note that it is not 100% essential that the adb daemon run as a more privileged userid or be installed in place of the official one - you can run an adb daemon as an ordinary application and do many of the expected things with it. However, whichever adb daemon is running first will grab the unix domain java debug socket, and so only that adb daemon will be able to provide the full java debug services. More primitive things like logcat, shell, running process list, push/pull, etc will at least partially work without this, provided that your adb daemon doesn't quit (modification may be required) when it is unable to claim the debug socket. If you can kill the official adb daemon and exploit a race condition, you may be able to get an unofficial one started before it restarts - you would probably need to have a script or program to do this and run it with setsid from the official adb shell, meaning you'd need to connect via USB first. At that point, you'd also be able to start your unofficial adb daemon running as the same userid as the official one.
You may want to spend some time estimating or testing if the performance (speed) will be satisfactory before investing in a lot of time setting this up for real.

I know this is a bit old but I seem to have found a post that does this. All credit goes to the author of fomori.org for finding this and making the information available. Today it helped me, maybe tomorrow I'll help you by making it easier to find.
Source

How does the bootloader pick up the command after a "restarting system with command"?

Looking in the android source for the reboot command we find the following line:
__reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, \
LINUX_REBOOT_CMD_RESTART2, argv[optind]);
Which is the standard Linux system call to reboot the system with a specific command, see Unix System Call Reboot.
In Android this command is used to tell the bootloader to start either the kernel in recovery mode or to go to the fastboot mode within the bootloader.
My question is: How does the bootloader pick up the command? And is this functionality implemented in U-Boot? (I am unable to find it searching either through Google or in the U-Boot source.)
Additionally it seems this is not specific to Android, but is the way Linux performs a "reboot with a command". Any information on how this is "normally" handled/used in Linux?

When the system is rebooted using LINUX_REBOOT_CMD_RESTART2, the supplied command string is passed to all of the notifiers registered with register_reboot_notifer(), and finally to machine_restart() - the architecture-specific function that actually performs system restart.
Most architectures ignore the passed command entirely - for an example of one that doesn't, see SPARC. The SPARC implementation of machine_restart() passes the supplied string to the boot command of the PROM.
The ARM implementation of machine_restart() ends up passing the supplied command to arch_reset() which is implemented separately on each ARM platform - from what I can see, most if not all of those implementations ignore the passed command, at least in the upstream kernel. This may not be the droid you're looking for.

Write "boot-recovery" command in MSC partiton. The bootloader reads the string from MSC partition and loads the recovery kernel. This was the way the recovery kernel was loaded in Froyo and before. The same approach can be followed in GB/HC/ICS.
Another method is to carve out some memory and pass some flag which is read from he bootloader. The only issue is that the DRAM contents might get lost during reboot unless you put SDRAM in self refesh mode. So during restart this needs to be taken care of.
First method is useful when the power goes off during the update process. In this case the device need to go into recovery kernel again. In that case MSC partition must be cleared only after whole update process is successful.

I have no clue how they do it in Android, but on our systems where we use u-boot as well we have a similar mechanism.
We reserve a very small memory portion that is reserved for "communication" from bootloader to kernel and the opposite direction as well. If this memory can survive a reboot (put the RAM in self-refresh mode before rebooting, or in Flash), it's then easy to read the value in the bootloader start and to determine if you have to start the kernel and then your system usually or you want to go to a special mode of the bootloader.

On some ARM processors the running kernel sets a flag in one of the CPU registers which is then read by UBOOT keep in mind this stuff if very hardware specific.

Monitor data consumption in Android app?

I'm building an app that relies on a lot of online content. I'd like to monitor how much is being downloaded and attempt to minimize it as much as possible. These days, with more and more carriers implementing data caps, users deserve an application that has gone through data consumption testing.

Well, not exactly advanced tools. But you can use iptables in the underlying Linux system to give you network info. I used this a little while ago to do a bit of tracking. You needed a rooted phone. I've only tried this out thus far on my G2, not sure how it would fare on an emulator or something of the sort. But assuming that you did have a rooted phone, which will have the iptables command available, can use iptables to segment some traffic off into a chain and then get the stats out of the chain:
iptables -N app
iptables -A OUTPUT -d a.b.c.d -j app
If you wanted to track data you were sending to IP a.b.c.d from your handset. Then you can dump the stats from iptables using "iptables -L -v -n" to get the packet count and byte count by rule.
Might not be the right solution for you given that you control the source of the program. But comes in really useful for monitoring when you don't have the ability to modify the code.