Separate the JNI function that controls logging levels into two.

Separate the JNI function that controls logging levels into two.

The parameters for Logging.enableTracing() were creating the impression
that they control level and severity of one tracing system and they are
meant to be used together. In fact the "levels" parameter controlled one
tracing system (WEBRTC_TRACE), and the "severity" parameter was
responsible for a completely different one: setting the severity level
above which log messages from LOG() will be directed to the
platform-specific debug output (logcat on Android).

The method signature suggested that the "path" parameter applied to both
systems - while it was only meaningful for the WEBRTC_TRACE; LOG
messages were directed to ADB logcat no matter what the Path value was.
It is possible to redirect LOG messages to a file, but that is done
using a completely different set of APIs
 - PeerConnectionFactory.startInternalTracingCapture().

I've separated these two methods to make it more clear which of the
parameters controls which system.

NOTRY=true

Committed: https://crrev.com/4c4cb5b98456cb16d9174485bd59e58a861fd0f5
Cr-Commit-Position: refs/heads/master@{#13334}

[skvlad, 2016-06-29 18:39:06]

Description was changed from

==========
Separate the JNI function that controls logging levels into two.

The parameters for Logging.enableTracing() were creating the impression
that they control level and severity of one tracing system and they are
meant to be used together. In fact the "levels" parameter controlled one
tracing system (WEBRTC_TRACE), and the "severity" parameter was
responsible for a completely different one: setting the severity level
above which log messages from LOG() will be directed to the
platform-specific debug output (logcat on Android).

The method signature suggested that the "path" parameter applied to both
systems - while it was only meaningful for the WEBRTC_TRACE; LOG
messages were directed to ADB logcat no matter what the Path value was.
It is possible to redirect LOG messages to a file, but that is done
using a completely different set of APIs
 - PeerConnectionFactory.startInternalTracingCapture().

I've separated these two methods to make it more clear which of the
parameters controls which system.

BUG=
==========

to

==========
Separate the JNI function that controls logging levels into two.

The parameters for Logging.enableTracing() were creating the impression
that they control level and severity of one tracing system and they are
meant to be used together. In fact the "levels" parameter controlled one
tracing system (WEBRTC_TRACE), and the "severity" parameter was
responsible for a completely different one: setting the severity level
above which log messages from LOG() will be directed to the
platform-specific debug output (logcat on Android).

The method signature suggested that the "path" parameter applied to both
systems - while it was only meaningful for the WEBRTC_TRACE; LOG
messages were directed to ADB logcat no matter what the Path value was.
It is possible to redirect LOG messages to a file, but that is done
using a completely different set of APIs
 - PeerConnectionFactory.startInternalTracingCapture().

I've separated these two methods to make it more clear which of the
parameters controls which system.

BUG=
==========

[skvlad, 2016-06-29 18:39:06]

skvlad@webrtc.org changed reviewers:
+ deadbeef@webrtc.org, glaznev@webrtc.org, pthatcher@webrtc.org

[skvlad, 2016-06-29 19:03:17]

added reviewers

[pthatcher1, 2016-06-29 19:05:31]

lgtm

[pthatcher1, 2016-06-29 19:16:26]

lgtm again

[skvlad, 2016-06-29 20:55:13]

Fixed two more things:
 - separated the loggingEnabled and tracingEnabled flags in Logging.java; now
it's possible to turn on logging without tracing or vice-versa.
 - Exported the LS_NONE severity to Java applications so that they can
completely turn off logging (as opposed to setting it to a high value like
Error).

[Taylor Brandstetter, 2016-06-29 21:42:49]

lgtm. By the way, you can remove "BUG=" from the description if there's no bug.

[pthatcher1, 2016-06-29 21:54:55]

lgtm

lgtm again again

[pthatcher1, 2016-06-29 21:55:00]

lgtm again again

[AlexG, 2016-06-29 22:02:34]

lgtm

[skvlad, 2016-06-29 22:10:08]

The CQ bit was checked by skvlad@webrtc.org

[commit-bot: I haz the power, 2016-06-29 22:10:20]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-06-29 22:17:29]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-29 22:17:31]

Try jobs failed on following builders:
  android_dbg on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/android_dbg/builds/14642)

[skvlad, 2016-06-29 22:28:32]

Description was changed from

==========
Separate the JNI function that controls logging levels into two.

The parameters for Logging.enableTracing() were creating the impression
that they control level and severity of one tracing system and they are
meant to be used together. In fact the "levels" parameter controlled one
tracing system (WEBRTC_TRACE), and the "severity" parameter was
responsible for a completely different one: setting the severity level
above which log messages from LOG() will be directed to the
platform-specific debug output (logcat on Android).

The method signature suggested that the "path" parameter applied to both
systems - while it was only meaningful for the WEBRTC_TRACE; LOG
messages were directed to ADB logcat no matter what the Path value was.
It is possible to redirect LOG messages to a file, but that is done
using a completely different set of APIs
 - PeerConnectionFactory.startInternalTracingCapture().

I've separated these two methods to make it more clear which of the
parameters controls which system.

BUG=
==========

to

==========
Separate the JNI function that controls logging levels into two.

The parameters for Logging.enableTracing() were creating the impression
that they control level and severity of one tracing system and they are
meant to be used together. In fact the "levels" parameter controlled one
tracing system (WEBRTC_TRACE), and the "severity" parameter was
responsible for a completely different one: setting the severity level
above which log messages from LOG() will be directed to the
platform-specific debug output (logcat on Android).

The method signature suggested that the "path" parameter applied to both
systems - while it was only meaningful for the WEBRTC_TRACE; LOG
messages were directed to ADB logcat no matter what the Path value was.
It is possible to redirect LOG messages to a file, but that is done
using a completely different set of APIs
 - PeerConnectionFactory.startInternalTracingCapture().

I've separated these two methods to make it more clear which of the
parameters controls which system.

NOTRY=true
==========

[skvlad, 2016-06-29 22:28:41]

The CQ bit was checked by skvlad@webrtc.org

[commit-bot: I haz the power, 2016-06-29 22:28:47]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-06-29 22:30:47]

Description was changed from

==========
Separate the JNI function that controls logging levels into two.

The parameters for Logging.enableTracing() were creating the impression
that they control level and severity of one tracing system and they are
meant to be used together. In fact the "levels" parameter controlled one
tracing system (WEBRTC_TRACE), and the "severity" parameter was
responsible for a completely different one: setting the severity level
above which log messages from LOG() will be directed to the
platform-specific debug output (logcat on Android).

The method signature suggested that the "path" parameter applied to both
systems - while it was only meaningful for the WEBRTC_TRACE; LOG
messages were directed to ADB logcat no matter what the Path value was.
It is possible to redirect LOG messages to a file, but that is done
using a completely different set of APIs
 - PeerConnectionFactory.startInternalTracingCapture().

I've separated these two methods to make it more clear which of the
parameters controls which system.

NOTRY=true
==========

to

==========
Separate the JNI function that controls logging levels into two.

The parameters for Logging.enableTracing() were creating the impression
that they control level and severity of one tracing system and they are
meant to be used together. In fact the "levels" parameter controlled one
tracing system (WEBRTC_TRACE), and the "severity" parameter was
responsible for a completely different one: setting the severity level
above which log messages from LOG() will be directed to the
platform-specific debug output (logcat on Android).

The method signature suggested that the "path" parameter applied to both
systems - while it was only meaningful for the WEBRTC_TRACE; LOG
messages were directed to ADB logcat no matter what the Path value was.
It is possible to redirect LOG messages to a file, but that is done
using a completely different set of APIs
 - PeerConnectionFactory.startInternalTracingCapture().

I've separated these two methods to make it more clear which of the
parameters controls which system.

NOTRY=true
==========

[commit-bot: I haz the power, 2016-06-29 22:30:48]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-06-29 22:30:57]

Description was changed from

==========
Separate the JNI function that controls logging levels into two.

The parameters for Logging.enableTracing() were creating the impression
that they control level and severity of one tracing system and they are
meant to be used together. In fact the "levels" parameter controlled one
tracing system (WEBRTC_TRACE), and the "severity" parameter was
responsible for a completely different one: setting the severity level
above which log messages from LOG() will be directed to the
platform-specific debug output (logcat on Android).

The method signature suggested that the "path" parameter applied to both
systems - while it was only meaningful for the WEBRTC_TRACE; LOG
messages were directed to ADB logcat no matter what the Path value was.
It is possible to redirect LOG messages to a file, but that is done
using a completely different set of APIs
 - PeerConnectionFactory.startInternalTracingCapture().

I've separated these two methods to make it more clear which of the
parameters controls which system.

NOTRY=true
==========

to

==========
Separate the JNI function that controls logging levels into two.

The parameters for Logging.enableTracing() were creating the impression
that they control level and severity of one tracing system and they are
meant to be used together. In fact the "levels" parameter controlled one
tracing system (WEBRTC_TRACE), and the "severity" parameter was
responsible for a completely different one: setting the severity level
above which log messages from LOG() will be directed to the
platform-specific debug output (logcat on Android).

The method signature suggested that the "path" parameter applied to both
systems - while it was only meaningful for the WEBRTC_TRACE; LOG
messages were directed to ADB logcat no matter what the Path value was.
It is possible to redirect LOG messages to a file, but that is done
using a completely different set of APIs
 - PeerConnectionFactory.startInternalTracingCapture().

I've separated these two methods to make it more clear which of the
parameters controls which system.

NOTRY=true

Committed: https://crrev.com/4c4cb5b98456cb16d9174485bd59e58a861fd0f5
Cr-Commit-Position: refs/heads/master@{#13334}
==========

[commit-bot: I haz the power, 2016-06-29 22:30:58]

Patchset 3 (id:??) landed as
https://crrev.com/4c4cb5b98456cb16d9174485bd59e58a861fd0f5
Cr-Commit-Position: refs/heads/master@{#13334}

[skvlad, 2016-07-21 23:27:01]

Patchset #4 (id:60001) has been deleted