Develop Reference

Android Native - how to intercept or filter logcat

I'm compiling in debug mode a certain .so in the Android-Native layer which by default outputs to the default logging file.
However, I do not want this data to be saved to the logs in the first place because it will overwhelm the logging file; I plan on streaming it off of the device.
POSSIBLE SOLUTIONS
Modify the .so code to output the debug info to NOT the logging file.
Definitely the most straightforward way but I'd prefer not to do this since this'll require modification of the .so. I agree this should be trivial modification but I have a requirement to modify the .so as little as possible.
Is there a way to create an alias for a file, pipe all writes to it through my app (like tee) and selectively allow writes to the real file?
Is there a built-in logcat filtering tool that can do this filtering for me with some regexs?

First of all, the first solution is indeed the trivial and the better one - since it remains in the code unlike the logcat filtering that might get deleted.
If the requirement is to modify the .so as little as possible, there is no real problem - you modify the code using #ifdef for debug only, so the code changes for debug mode, but the generated .so for release does not change. This will give you a very good control - but in case you have a lot of 'special' debug code, it will make your code a little ugly...
Edit:
If you want to write to you own log, you can run logcat using Runtime class, with your own parameters - look here: Using GREP command to filter logcat in Android.
Regarding the logcat filtering - you can use regex in the filtering in Android Studio. You have a 'regex' check box next to the input box. See here for more details: How to exclude certain messages by TAG name using Android adb logcat?

where's the SurfaceFlinger process in systrace resulting html file?

according to the documentation, there should be a SurfaceFlinger process in the graph so I can use it to find the cause of missing frames. I used to see it, but now a bunch of package names become ..., see below.
So how could I address my performance issues using this file?

Enable "CPU Scheduler". Without "sched" it may not get the process / thread names. (Note this may require root on the device.)
Some of the rows (e.g. VSYNC) are coming from SurfaceFlinger, so the data is there, just not labeled.

Persistent error on LogCat: "Error opening trace file: No such file or directory (2)"

This question has been asked no less than 17 times previously and to my great surprise, has never been answered! It has been closed, marked as duplicate and used to solve all manner of unrelated problems. I still cannot find an answer to the actual question in the title.
What seems to happen is that someone unfamiliar with Android runs a program, triggers an error, and gets a series of LogCat error messages. At the front of the LogCat trace appears the above, which they promptly post here. It is completely unrelated to the problem they are interested in solving. Once their problem is solved, they go away. The most popular answer of this kind is here: error opening trace file: No such file or directory (2).
My question is: what exactly does this message in LogCat actually mean? When does it happen, why does it happen, and is there anything I can (reasonably) do to make it go away? [My apps may have other errors, but they are not relevant here.]
Please do not vote to close this question as a duplicate unless or until you can point to another question that provides a sufficient explanation of this actual error message.
It should be said that we are developers (of course) writing code for the Android platform (of course) and we make extensive use of the Log class in our code. It seems that this message appears somewhere after the program starts and somewhere before the first use of the Log class.
The obvious answer would be that Log is expecting to find a specific folder or path, which happens not to exist. The answer may simply be to ensure that path exists, if we knew what it was or where it is set. We're using ADT, as it happens.
So I picked a small app at random and ran it. Here is the LogCat.
05-23 18:22:10.948: D/dalvikvm(27917): Late-enabling CheckJNI
05-23 18:22:11.057: E/Trace(27917): error opening trace file: No such file or directory (2)
05-23 18:22:11.590: D/libEGL(27917): loaded /system/lib/egl/libEGL_mali.so
05-23 18:22:11.598: D/libEGL(27917): loaded /system/lib/egl/libGLESv1_CM_mali.so
05-23 18:22:11.613: D/libEGL(27917): loaded /system/lib/egl/libGLESv2_mali.so
05-23 18:22:11.677: D/OpenGLRenderer(27917): Enabling debug mode 0
There are no calls to Log in this one. It's just Hello World.

The answer is: this is a red herring. Ignore it.
There is a perfectly good answer here, which I repeat.
The error message comes from the systrace code. It indicates that your device doesn't support systrace tracing. You can ignore it.
Log message is generated on line 172 of (android.googlesource.com/platform/system/core/+/jb-mr2-release/… . – fadden Aug 30 '13 at 4:32
The source code link is here.
Thanks to #FrozenFire and #Fadden.

using startMethodTracing and stopMethodTracing with ddms

I'd like to measure performance in a specific function (and everything it calls). To do so, it seems I should use Debug.startMethodTracing() and Debug.stopMethodTracing(), then somehow start DDMS tracing.
However, when I open a DDMS view in Eclipse and click the Start Method Profiling button, it starts immediately - not when startMethodTracing() executes. The result is a huge trace file with mostly irrelevant stuff in it. Too hard to narrow in (I tried a few times).
Apparently TraceView is deprecated. Should I hack a way to use that anyway? Is it any better? What is the correct approach to do what I need?
Thanks.

If you use Debug.startMethodTracing() and Debug.stopMethodTracing() a .trace file will be created on the device. The exact location of it is printed out in the logcat.
Look for entries that start with "TRACE STARTED" and "TRACE STOPPED". You then can use adb pull to get the .trace file from your device and open it in the tool of your choice for analysis (e.g. Eclipse or some third party product)
There is no need to manually use DDMS in Eclipse if you're using the above calls. The .trace file itself can simply be opened in Eclipse by using File -> Open

How to find this stack trace?

My program keeps crashing, but the logcat does not show any exceptions. I just get the following message, plus a lot of stats about CPU usage. Clearly I'm using too much of the CPU, but I don't know what part of my program is doing this. Where is the following file? I can't find it.
12-30 23:13:06.639: INFO/dalvikvm(7688): Wrote stack trace to
'/data/anr/traces.txt'

adb shell
-->
cat /data/anr/traces.txt
EDIT:
You need to have root access to modify the files in /data/ you should be able to access the file with an app like https://market.android.com/details?id=com.estrongs.android.pop
Once you have that app, open it --> Menu --> Settings --> Home Directory (Change from /sdcard/ to /) --> Exit the app --> Open it again
Then you should be able to browse to /data/anr/*
EDIT2 (Additional info, based on comments) for use with a published app after hands on testing:
Most developers rely on the developer console error reporting to see the stacktrace and error logs when a user submits an error report.
Others impliment their own or use a library like ACRA
Be warned some users do not install an app simply because it uses the permission to read sensitive log data.

For comfortable viewing without cutted head of file use following one-line command:
adb shell "cat /data/anr/traces.txt" | less

The ANR stands for "Android Not Responding" and it doesn't mean you're using too much of the CPU, it means that the UI main looper hadn't been called for a given amount of time. The UI looper takes care of user input, so from the point of view of your user, the app was unresponsive to input. Usually this is caused by doing long-running or blocking operations on the main UI thread. For example, downloading a file on the main thread could cause an ANR. Usually it's pretty easy to pick out the code that causes an ANR just from that information.

If you are on Windows with Android Studio, you can do the following:
In Andriod Studio:
View > Tool Windows > Device File Explorer
This should open a new window with all files on the device (where your stack trace is located), then you can navigate to '/data/anr/traces.txt', just double click on the file will open it up for you.