-
Notifications
You must be signed in to change notification settings - Fork 6k
Guard Android logs #8824
Guard Android logs #8824
Changes from all commits
d67a843
c31d7a6
9af3fa5
43db149
2b36e51
a4200ac
4c27404
9e08955
f66638e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1821,16 +1821,18 @@ private boolean didChangeLabel() { | |
| } | ||
|
|
||
| private void log(@NonNull String indent, boolean recursive) { | ||
| Log.i(TAG, | ||
| indent + "SemanticsNode id=" + id + " label=" + label + " actions=" + actions | ||
| + " flags=" + flags + "\n" + indent + " +-- textDirection=" | ||
| + textDirection + "\n" + indent + " +-- rect.ltrb=(" + left + ", " | ||
| + top + ", " + right + ", " + bottom + ")\n" + indent | ||
| + " +-- transform=" + Arrays.toString(transform) + "\n"); | ||
| if (childrenInTraversalOrder != null && recursive) { | ||
| String childIndent = indent + " "; | ||
| for (SemanticsNode child : childrenInTraversalOrder) { | ||
| child.log(childIndent, recursive); | ||
| if (BuildConfig.DEBUG) { | ||
| Log.i(TAG, | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Doesn't Android already take care of avoiding log statements when built in release mode?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't know if it can because this is a library. Either way, the linter is telling us we should be guarding this this way.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (specifically for logging levels below warning)
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there someone who could clarify whether we need this in actuality? I've got a lot of logs in the embedding and unfortunately this is quite a tedious practice per log statement. I would definitely appreciate if we could determine with confidence what the behavior is and ideally avoid this. Another option might be to introduce our own Log class that internally contains these guards.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Only needed for log levels below warn. Linter clarifies it, right?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Plus we don't want to be adding more noise to logcat for informational logging outside of debug mode do we?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The documentation says that verbose logs aren't compiled into release build, and debug logs are but are stripped at runtime. We could do a quick check to confirm that just logs out at every level when the engine initializes and check what gets printed with +1 to our own Log class wrapper instead of needing to guard at every call site though.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not strongly opposed to that, but I think we should generally avoid informational logging in the embedder outside of temporary logs for local debugging. Creating a utility class could encourage people to add logging that we don't need. IOW, informational logging that remains in this codebase should be painful. We only have a few callsites (some of which are already in helper classes or methods), and even of those I think two of them should be upgraded to errors or warnings.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (I say this in part because logcat is already super chatty, and we should avoid adding to chatter when you're looking for flutter specific logs)
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Understood. I think requiring the callsite checks makes sense then. |
||
| indent + "SemanticsNode id=" + id + " label=" + label + " actions=" + actions | ||
| + " flags=" + flags + "\n" + indent + " +-- textDirection=" | ||
| + textDirection + "\n" + indent + " +-- rect.ltrb=(" + left + ", " | ||
| + top + ", " + right + ", " + bottom + ")\n" + indent | ||
| + " +-- transform=" + Arrays.toString(transform) + "\n"); | ||
| if (childrenInTraversalOrder != null && recursive) { | ||
| String childIndent = indent + " "; | ||
| for (SemanticsNode child : childrenInTraversalOrder) { | ||
| child.log(childIndent, recursive); | ||
| } | ||
| } | ||
| } | ||
| } | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.