This might be a nit-picky thing, but in Xamarin when running an Android app, it dumps tons of lines in the console that start with [Mono]
Is there any way to disable these logs?
Thanks in advance
This can be done by changing the state of Monos execution environment on the device; which is just a set of environment variables that alters Monos behaviour (be it garbage collection, logging etc). In this case, to alter the logging behavior we need to modify the values stored in the environment variables MONO_LOG_LEVEL and MONO_LOG_MASK.
Xamarin.Android offers 2 mechanisms developers can use to change the execution environment:
1. Using adb shell setprop debug.mono.env. This can be done as a post build action.
2. Using an environment build file to change the execution environment state per project.
I prefer to use method 2 as it's easier to edit a text file than changing build actions. Do this using the steps outlined below.
Adding An Environment File
Add a plain text file called environment.txt to the root path of your Xamarin.Android project.
Right click on environment.txt and set its build action to AndroidEnvironment.
The environment file is series of key=value pairs seperated by newlines. For logging, we can set the following variables:
MONO_LOG_LEVEL
debug
info
message
warning
critical
error
MONO_LOG_MASK
asm
dll
cfg
all
type
gc
For example, we can ignore most messages by filtering MONO_LOG_LEVEL by error:
environment.txt
MONO_LOG_LEVEL=error
Background reading:
Android Environment
Mono - Logging Runtime Events
What I do is below. It's still imperfect as the window holds 10k logs, including the hidden ones, so mine eventually disappear. Additionally, I can't seem to copy from the window.
1) Use a tag of "AAA" for all my logs.
2) View the output in Tools>Android>Device Log
3) Sort alphabetically by Tag.
4) I find that the outputs beneath mine are still distracting. I can click the "filter" for the Tag and uncheck everything but mine. Annoyingly, I have to repeat this step periodically as new tags are not filtered by default.
Related
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 I can find full list of Bitrise default environment variables with actual values?
I can see list of variables in Select variable dialog:
but there's no possibility to check their values. I don't want to print all of them in command line using echo and check their values.
Would be nice to have this information in bitrise.io documentation, which is missing at the moment.
I've found some bitrise* repositories in github, and in the source code of steps I was able to check some default values for environment variables. It's still not the desired result.
Why we don't have docs for the values: because it can change any time. The point of Environment Variables is that you can reference things where the value might change. The variable's meaning remains the same, but the value might change.
For example, $BITRISE_SOURCE_DIR refers to the main working directory, which (by default) is the code directory (where your code is git cloned). On the OS X stack it's usually /Users/vagrant/git, on the Android Docker stack it's usually /bitrise/src; but we don't guarantee that the location won't change in the future, and you can change this location as well.
Another important thing is, if you use the bitrise CLI to run your automation on your own Mac, the $BITRISE_SOURCE_DIR environment variable will be set by bitrise to the directory you call bitrise from, which is usually the same directory as on bitrise.io VMs, the one with your code.
Why is this important? If you use the $BITRISE_SOURCE_DIR environment in your script instead of a hardcoded value, it'll refer to the same thing (the source code directory path), no matter which environment you use to run your automation.
I've added a tagging / date-stamping system to my Android build system similar to the thread found here on Stack Overflow: embed version details in android APK
This worked out great for me, The post was awesome and I simply modified the Perl to put in a datestamp like thus:
perl -npi -e 's/(Build Date:)(.+)(DEV-MOB)/"Build Date: " . localtime() . " DEV-MOB"/e;' $MANIFEST
The issue I'm dealing with now is that Eclipse wants to continue building over and over. As soon as it sees that the AndroidManifest.xml has changed, it starts another autobuild, thereby changing the AndroidManifest.xml and sparking another autobuild... Rinse, lather, repeat.
I've turned off the "Build Automatically," and the result are fine for me (i.e. only build on a debugging deployment and/or after a clean), not on every single file save and/or change as Eclipse is want to do. Co-worker wants the Autobuild functioning as normal, and says my date stamping is defective otherwise.
How do I get the "Builder" to mark the tree as refreshed and/or up-to-date after modifying the AndroidManifest.xml, so that the tree doesn't keep looping? Looks like the flag that says "refreshed" is evaluated and triggers a new build after the previous build.
Thanks, I can post more details on the date stamping if desired.
DD
Check that your builder comes first in the Project builders list order.
I have some information generated in the Android Emulator, and the only way I can see to get it out is using the Log class.
However, you cannot copy-and-paste from the DDMS log window. This is really annoying as I cannot use the information in another application, for example, without retyping it.
Is there a better way to get debug information out of the emulator? What happens when you write more complex applications? What do you do when you need to verify it is writing correct information to URLs, databases, files etc?
Thanks!
Using the DDMS logcat window you can select lines and copy and paste text to other windows.
If you use java.util.logging instead of the Log class you could attach a handler to write the log file out to a text file if that would make things easier. Logcat is still available when using java.util.logging but by default INFO and above is only available.
You could just use the command line logcat utility: adb logcat
Left click on a line, then CTRL + C to copy. If you wan the entire log, CTRL + A to select all, and then CTRL + C. Paste it anywhere you want.
LogCat Rows are called items.
Each item has several attributes.
Currently, you can only select one or more items and do the following things:
-Copy with ctrl+c
-Save to a text file using the save button.
I started my emulator with ./emulator -trace profile -avd emulator_15. I then tracked down the trace files to ~/.android/avd/rodgers_emulator_15.avd/traces/profile, where there are six files: qtrace.bb, qtrace.exc, qtrace.insn, qtrace.method, qtrace.pid, qtrace.static. I can't figure out what to do with these files. I've tried both dmtracedump and traceview on all of the files, but none seem to generate any output I can do anything with.
How can I view the proportion of time taken by native method calls on Android?
You need to use tracedmdump to convert the output. This is a shell function defined in build/envsetup.sh in the full Android sources. If you're using the SDK, rather than building from a full tree, I'm not sure this will work.
(If you don't have the sources and want to take a peek at the tracedmdump function, you can see it here.)
If you used emulator -trace profile, you'd run tracedmdump profile. This will dig through various binaries to retrieve symbolic information and associate it with the trace data, generating an HTML summary and a traceview-compatible trace file.
It's worth noting that the VM will execute more slowly with profiling enabled (the interpreter has overhead on every method call and return, and it's running in the slower "debug" interpreter), while native code continues to run at full speed, so you have to be careful when drawing conclusions.
General comment: don't forget to use F9 or one of the method calls to start/stop the tracing -- the -trace flag just enables the feature.
In order to use those six files, there are other scripts in the same directory as that of dmtracedump such as read_pid, read_trace, profile_trace etc. U should first run post_trace on the trace directory containing the six files, then you can use any one of them to get profile info such as how often each basic block executes, the pids they belong to etc.