I use Debug#startMethodTracing(in Activity#onCreate) and Debug#stopMethodTracing(in Activity#onWindowFocusChanged) to get method call traces. But I can not find ViewRootImpl#performTraversals in trace in Monitor. What's wrong?
Related
I have a Firebase Performance Monitoring trace called my_trace.
Now, I start this trace when I load an image:
void loadImage() {
final Trace trace = performance.newTrace("my_trace");
trace.start();
// ... (loading that happens asynchronously)
trace.stop();
}
This works fine when I try to load a single image, however, in my application I need to load many images in parallel.
This means that the following error is reported when I load my images:
Trace 'my_trace' has already started, should not start again!
How do I correctly start a trace multiple times in parallel as I want to record the performance of every single loading process?
Note: I cannot use HTTPMetric as the loading trace also contains image conversion and not just downloading.
You can record it manually by storing the start time yourself and then just recording the duration. This should work.
Reference: https://firebase.google.com/docs/reference/js/firebase.performance.Trace#record
As the error message says, there can only be a single trace with a unique name active at any time. So you'll either have to wait for the first my_trace to finish before starting the second (running them sequentially instead of in parallel), or you'll have to generate a unique name for each trace.
Given how the API is structured it should be possible to allow multiple traces of the same name to run in parallel. If you think Firebase should consider allowing that, I recommend you file a feature request.
Traces are allowed to run in parallel already. Traces are not indexed by trace names. As long the trace object is unique, you should be able to run traces in parallel. Same trace object cannot be re-used.
Eg: (Incorrect way of using trace object)
final Trace trace = performance.newTrace("my_trace");
trace.start();
trace.start(); // This would not work. Fails with the error message that the trace is already started.
// ... (loading that happens asynchronously)
trace.stop();
Eg: Right way using the same trace name multiple times in parallel.
final Trace trace1 = performance.newTrace("my_trace");
final Trace trace2 = performance.newTrace("my_trace");
trace1.start();
trace2.start();
// ... (loading that happens asynchronously)
trace1.stop();
trace2.stop();
I have an app in production and I'm using Firebase for error and crash logging. Lately, I've been seeing some lines in the stack trace of the exceptions, starting with <OR>. Below is an example taken directly (save for the package name) from an exception reported by Firebase:
Exception java.lang.NullPointerException: Attempt to invoke interface method 'void com.mycompany.myapp.managers.b$a.f()' on a null object reference
com.mycompany.myapp.managers.PermissionManager.getInstance (PermissionManager.java)
<OR>.checkPermission (PermissionManager.java)
<OR>.onRequestPermissionsResult (PermissionManager.java)
com.mycompany.myapp.activities.ShareImageActivity.onSaveShare (ShareImageActivity.java)
com.mycompany.myapp.activities.ShareImageActivity$3.onClick (ShareImageActivity.java)
I know that this is not a regular stack trace since onRequestPermissionResults does not call checkPermission and checkPermission does not call PermissionManager.getInstance.
I assume this is one of the ways Android obfuscates the stack trace for the sake of security, but I couldn't find any documentation on this. Does anyone know how to interpret this stack trace?
The you see here is an indication that that Crash Reporting could not determine the actual object at that point. Currently, there is a known situation with Proguard deobfuscation where it could be ambiguous which object is the target here. This could be the case if you're stripping line numbers from your classes, which it looks like you are doing. This situation may improve if you are able to change your Proguard settings to remove the stripping of line numbers.
Add this to your proguard-rules.pro:
// obfuscate file name and keep line numbers
-renamesourcefileattribute SourceFile
-keepattributes SourceFile,LineNumberTable
It should remove ambiguity and you should not see <OR> in your stacktrace anymore.
In the Android Open Source Project's code style, it states that we shouldn't use System.out.println() but I don't understand why. Can anyone explain? What should I use to trace my app's log?
Here's the line for reference:
System.out.println() (or printf() for native code) should never be used. System.out and System.err get redirected to /dev/null, so your print statements will have no visible effects. However, all the string building that happens for these calls still gets executed.
You should use the android.util.Log class.
Here's a description of what the Log class does:
API for sending log output.
Generally, you should use the Log.v(), Log.d(), Log.i(), Log.w(), and Log.e() methods to write logs. You can then view the logs in logcat.
The order in terms of verbosity, from least to most is ERROR, WARN, INFO, DEBUG, VERBOSE. Verbose should never be compiled into an application except during development. Debug logs are compiled in but stripped at runtime. Error, warning and info logs are always kept.
These are the available methods of the Log class:
Log.d() - Send a DEBUG log message.
Log.e() - Send an ERROR log message.
Log.i() - Send an INFO log message.
Log.v() - Send a VERBOSE log message.
Log.w() - Send a WARN log message.
Log.wtf() - What a Terrible Failure: Report an exception that should never happen.
The methods above (with the exception of Log.w and Log.wtf which have 3 possible patterns of arguments) require the following arguments:
String tag, String msg:
tag: Used to identify the source of a log message. This value may be null.
msg: The message you would like logged. This value may be null.
String tag, String msg, Throwable tr - Similar to the first pattern, but allows for an exception to be specified. This pattern should be used if you want to log an exception to the log output.
(For Log.w and Log.wtf) String tag, Throwable tr Similar to the third pattern, but does not allow for a message to be specified. Note that you can still pass a message but it should be in the second arrangement of arguments.
EDIT: Going straight to answer your question: println() of System.out and System.err will still be displayed in logcat but with limitations.
You can't log VERBOSE, ERROR, or DEBUG using System.out or System.err.
You can't define your own tag, it will display System.err or System.out with your text. For instance:
System.out.println("Hello!") is equivalent to Log.i("System.out","Hello!")
System.err.println("Hello!") is equivalent to Log.w("System.err","Hello!")
System.out.println("") in android will not run well because there is no Terminal that the app is corrected to.
You would be better off using Log.(d)(v)(e)(i)(w), because there is something actively monitoring LogCat.
System.out.println() will print to LogCat, but only after an additional set of System instuctions, making it not as efficient, however, as i said, it still works.
if we want to trace the android project
we can do it using Log class
there is some methods like
Log.e(TAG,MESSAGE)
Log.v(TAG,MESSAGE)
Log.w(TAG,MESSAGE)
Log.d(TAG,MESSAGE)
Log.i(TAG,MESSAGE)
its a static method of Utils package. put it line by line and u can watch it in the LogCat..
thats at enjoy with android
From your own link:
System.out.println() (or printf() for native code) should never be
used. System.out and System.err get redirected to /dev/null, so your
print statements will have no visible effects. However, all the string
building that happens for these calls still gets executed.
In addition, at the beginning of that page, it says:
The rules below are not guidelines or recommendations, but strict
rules. Contributions to Android generally will not be accepted if they
do not adhere to these rules.
So DON'T do it!
You can use the built in Log utility that will print right out to the LogCat.
You can use Log.e(String, String) for errors which will appear in red. There is also v, d, i, and w for verbose, debug, info, and warning respectively.
The following should do the trick to print the exception
1. Log.d("myapp", Log.getStackTraceString(new Exception()));
or
2. You can get longer stack traces by digging deeper. For example:
Log.getStackTraceString(e.getCause().getCause());
Log is the best way to trace our android project
like following code...
it will help u...
just look in DDMS logCat that how exactly project is build...
requirement... android.utils.Log; package is used..
#Override
protected void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
for(int i=0;i
{
Log.e("i = ",""+i);
Log.v("i = ",""+i);
Log.i("i = ",""+i);
Log.w("i = ",""+i);
Log.d("i = ",""+i);
}
}
i hope it will help u
I want to convert a charsequence to String value,I use the following code for that
string passwordTxtValue;
passwordTxtValue = passwordTxt.getText().toString();
System.out.println(""+passwordTxtValue);
But i am not getting the value,how can i resolve this.
In Android System.out.println() gets redirected to LogCat and printed using Log.i(). In java you have System.out.println() instead of that you can use Android Log class in Android for the same purpose. And you can see the output in the Logcat. And one upperhand to see in the Logcat is you can get Stack Traces of any uncaught Exceptions.
Your value get converted correctly, but the java method println() won't work in Android
My logcat window in Eclipse only displays the first few lines of the StackTrace for each exception. This means that I often can't see where an exception occured. Is there any way to change this setting?
If you're referring to the "...12 more lines..." part, you only see that for exceptions that were the cause of another exception. If the top part of the stack trace is the same as the earlier trace, the full set of frames is only shown for the outermost exception, and the other traces get the "..." treatment.
Put another way, the chunk of a trace that isn't shown is a duplicate of a trace that appeared earlier in the exception cause chain. For example, suppose I have code where the method main() calls one(), which calls two(), and so on. four() throws an exception. two() catches it and re-throws it. The exception will look like this:
java.lang.RuntimeException: re-throw
at Foo.two(Foo.java:14)
at Foo.one(Foo.java:7)
at Foo.main(Foo.java:3)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.RuntimeException: first
at Foo.four(Foo.java:23)
at Foo.three(Foo.java:19)
at Foo.two(Foo.java:12)
... 3 more
The "caused by" exception says "... 3 more" rather than explicitly listing one(), main(), and dalvik.system.NativeStart.main. So to get the full trace of the initial exception, you would start by reading its trace, then continue at the trace above.
Note there is no overlap -- two() appears in both, but in the "first" trace it's on the call to three(), and in the "re-throw" trace it's on the throw instruction.
you can overload all the log methods (log.d, log.i, log.e, etc) with (String tag, String msg, Throwable tr) parameters, where the third parameter is the exception. This will give you the full stacktrace in logcat
http://developer.android.com/reference/android/util/Log.html
If your code calls a method which produces too tall of stack you can (and should) handle the exception in your code and output whatever is relevant to logs.
If you have no exception handling whatsoever and you don't even know where in your code should you be putting such a handler then the problem is entirely elsewhere - you should be handling exceptions a bit better than that.