Develop Reference

How to dump the XML layout of the foreground Android activity (without uiautomator)?

I've been using adb shell uiautomator dump and this works some of the time for some apps on my Pixel 2 device. When it decides to not work, I get this error message:
ERROR: could not get idle state.
I've read online that this is supposedly due to the UI not staying still while executing the dump, but even after letting apps idle for several minutes I still see that error. Even tried rebooting and rerooting the device. Is there a more reliable solution for this, preferably a native one?

You can try CulebraTester2.
It does not use uiautomator so you may not be affected by its limitation, which needs some idle time to be able to get the dump, and this doesn't happen when an animation is constantly being updated.
There are prebuilt APKs available at Github Actions (see Artifacts).
Install both APKs
Start server: ./culebratester2 start-server
Dump hierarchy: ./dump-window-hierarchy XML
The default format for the dump is JSON that's why you should specify XML in the command line if this is what you want.

What are the steps to get root access in android emulator for rebooting through code?

How do I get root access in order to reboot the emulator? How do I kill all unwanted processes along with the child process?

You have already root access to your emulator. To kill a process and all childs just use the device view in eclipse, select the emulator theere and chose which process you want to kill.
I have no idea on how to restart from code if you are looking for that. Rebooting the device should be easy: just close it and than boot it up again.
(I have the feeling I don't really get what you want...)

Most su binaries for Android depend on SuperUser.apk (available for free through the market). The su binary uses this apk to ask the user if it's ok to do whatever is being requested (and the user can opt to remember the answer). If you're using such a su, you need to also have that apk.
Once the pieces are in place, your application can spawn a process with the right arguments... something like argv[0]="/path/to/su", argv[1]="-c", argv[2]="(whatever command you want to run)", argv[3...n]=arguments to your command.

To kill a process in the command line, simply issue the following command line on the shell:
kill-9 YOUR_PID
If you know the name of the process, but not the pid, use
kill -9 $(pidof NAME_OF_PROCESS)
You can also use it on your code:
Runtime.getRuntime().exec("kill-9 YOUR_PID");
Check the man page for more details: http://unixhelp.ed.ac.uk/CGI/man-cgi?kill

ps-after rebooting i also wanted to kill all unwanted process except my specific app and its child process alone to run in emulator.
If that is really what you want to do - repurpose an android build as a generic embedded linux, then the way to go about it is to regenerate a ramdisk image (which android packs onto the kernel) containing an init.rc which launches your application rather than the android native services and (java-esque dalvik) android runtime. Rebuilding the ramdisk requires a unix-like OS and that arcane cpio command line which you can find in web search. I'd be tempted to leave the startup of ADB in there so you can debug the various things which will go wrong.
For testing purposes simply typing "stop" from the adb shell will shut down the android runtime and give you a UI-less virtual pocket linux box. There will still be some native services running but they may be more help than harm. Ultimately you may need to set OOM killer values on the things you add, though without the runtime up that may not be an issue in the near term if you don't consume much memory.
Or if what you want to do is have a very locked down and limited UI built on top of the android runtime, you would instead develop a custom home screen , test this on an unmodified emulator, and then deploy it on a build customized to lack any means of installing other applications.

How to delay umount of SDcard on Android to complete my own file io

My application needs a guaranteed time to complete some IO on an SDcard before the SDcard is unmounted. My solution is to write a linux kernel module that inserts a wrapper around the umount system call that will delay the actual umount and call me back to complete my work.
My code may have root privileged components.
Any less obstructive solutions?

Though I can't guarantee it, I believe that umount will automatically wait for that. That's one of the reasons to use umount (instead of directly removing the sdcard).
Also, you can't «write a linux kernel module» and "install" it into an android device. What you would have to do would involve recompiling android, making a custom ROM and install that to the desired device. Each device would need a different ROM, etc. I don't think this conceivable for you.
Anyway, umount should wait for any IO operation to finish (maybe with a timeout). I don't see a solution in case you have several files to send and what to ensure that all of them will be written.

Android logging levels

I'm having a little difficulty configuring Android logging. Here's what my code looks like:
if (Log.isLoggable("MY_TAG", Log.VERBOSE)) {
Log.v("MY_TAG", "Here's a log message");
}
Pretty simple, right?
However, I'm having quite a bit of difficulty getting the Log.isLoggable("MY_TAG", Log.VERBOSE) to return true.
Per http://developer.android.com/reference/android/util/Log.html, I tried adding a local.prop file to the /data/ directory which looks like this:
log.tag.MY_TAG=VERBOSE
but no luck. I also tried:
System.setProperty("log.tag.MY_TAG", String.valueOf(Log.VERBOSE));
but that doesn't work either.
Any ideas on what I'm doing wrong here? I'm running Android 2.1-update1 on a Nexus 1 if that makes any difference.

Try
adb shell setprop log.tag.MyAppTag VERBOSE

It seems that later versions of Android want /data/local.prop to be writable by root only. The adb push command appears to initially create files with granting everyone read/write access (because default file mask is 777). Android, wisely, ignores /data/local.prop since this can be a security risk.
I have only experimented with Android 2.3.3, and 4.1.2. The former has no issues with reading a local.prop that is world writable, while the latter appears to silently ignore the file's contents.
Creating a local.prop file as described in the original question:
log.tag.MY_TAG=VERBOSE
And then pushing it onto the device as follows seems to do the trick:
adb push local.prop /data/local.prop
adb shell chmod 644 /data/local.prop
adb shell chown root.root /data/local.prop
adb reboot
You can double check to make sure that the values in local.prop were read by executing:
adb shell getprop | grep log.tag
So in summary:
/data/local.prop is only read during boot.
Later versions of Android appear to require that the permissions on the /data/local.prop file must be properly set, or it will not be read. The file must be writable by root only.
Using adb shell setprop log.tag.MyAppTag VERBOSE also work. The issue is that the property values are lost after a reboot.

An important goal is to not ship a production app with a ton of log calls left in it, increasing its size, and even possibly even impacting its performance.
To do this, my recommendation is to put these constants at the top of each class that is going to have log calls:
static final boolean DEBUG = false;
static final String TAG = "<MyClass>"
Now where you log, do this:
if (DEBUG) Log.v(TAG, "Something");
Turn on your logs by changing the DEBUG constant to true. (If you want, you could have one class with these statics for all of your app's code to use... That makes sense for a small app, but as things get large it is nice to decide which parts to turn logging on.)
By doing this, when you build your app with DEBUG = false, all of your logging code not only isn't executed, but is completely stripped out of your app. This is nice because it allows you to leave fairly extensive logging in your code to be turned on when you need it, without worrying about how that will impact the size of your shipping app. Basically just throw logs in wherever you need them and don't worry about leaving them in.
This is the approach that a lot of the Android framework takes. For example, the Activity ManagerService.
This has those constants at the top, and various log lines sprinkled throughout based on them. (And a bunch of other sub-debug constants for various aspects of it, since this file is ridiculously stupidly large.)

Is there a way to visualize the activity stack (activities in memory) on Android?

I'm currently debugging my app which is quite complex and has up to 5 activity levels. In order to detect memory leaks (i.e. activities that aren't removed from memory even finish() is called, due to some references held somewhere) I want to check which activities are still alive in memory.
Currently I create hprof dumps, but it's not very convenient, cause every time I need to mount the sdcard, copy the hprof dump file from the sdcard to my PC, etc.
(Side note: I already tried to automate the pulling of my hprof file more easily, but I'm on an unrooted device and adb pull <hprof file> won't let me / no permission.)
Therefore I am wondering, if all I want to know is IF and WHICH activities are still currently alive in my memory, is there a way through the Android API or any other way on-the-fly with which I can achieve this (list all alive activities of my app), programatically.

cause every time I need to mount the
sdcard, copy the hprof dump file from
the sdcard to my PC, etc
You can use Eclipse's File Manager view while your phone is in Debug mode to copy data from your device, without mounting the SDCard.

I figure there's no way to visualize the activity stack within Android itself.