Add Java binding for new getStats implementation.

Add Java binding for new getStats implementation.

Very similar to the current interface, but matches the new C++ structure, and
exposes the stats values as Objects which can be downcast to more specific
types (where the previous API only exposed the values as strings).

BUG=webrtc:6871
Review-Url: https://codereview.webrtc.org/2807933003
Cr-Commit-Position: refs/heads/master@{#17746}
Committed: https://chromium.googlesource.com/external/webrtc/+/82215872f8f75410366cb5cb986e816fe8f77364

[Taylor Brandstetter, 2017-04-09 05:46:21]

deadbeef@webrtc.org changed reviewers:
+ hbos@webrtc.org

[Taylor Brandstetter, 2017-04-09 05:46:21]

hbos, here's what I was thinking of for the Java API. Is this close enough to
the vision you had? If not, what changes would you suggest?

[hbos, 2017-04-10 10:19:42]

On 2017/04/09 05:46:21, Taylor Brandstetter wrote:
> hbos, here's what I was thinking of for the Java API. Is this close enough to
> the vision you had? If not, what changes would you suggest?

Looking good.

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
File webrtc/sdk/android/api/org/webrtc/RTCStats.java (right):

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStats.java:19: *  dictionary. */
nit: Here and elsewhere, /** and */ on separate lines unless the entire comment
is a /** single line */.

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStats.java:21: private final long
timestamp_us;
nit: Here, constructor, getter and toString: timestampUs

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStats.java:55: *  - Long (for 32-bit
unsigned and 64-bit signed integers)
Being able to distinguish between for example uint32_t and int64_t would only be
useful for serialization where we need the types to match between C++ and Java,
such as exporting to the same database between two platforms, in all other cases
you'd only need to know the Java type. Not sure whether to add a type enum or
not?

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStats.java:61: return members;
I thought about returning Collections.unmodifiableSortedMap(members) instead but
arrays are mutable even if the map isn't, so we can't go const either way. But
hey, giving ownership of the stats to the caller makes sense.

One thing to consider: For arrays, do we return primitive arrays or boxed
arrrays? E.g.
- int[]: An array of ints.
- Integer[]: An array of references to Integer objects wrapping ints.

One might think int[] makes more sense, but the upside of boxed arrays is they
can be converted to Object[], primitive arrays can't - there's no "generic" way
to iterate primitive arrays, but you can do so with objects, which is good for
looping through all stats.

I think the slight overhead is worth Object[], let's do it this way. Looks more
consistent too.

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStats.java:74: builder.append(",
").append(entry.getKey()).append(": ").append(entry.getValue());
An array toString() is not printed as e.g. "[1, 2, 3]" but as e.g.
"[Ljava.lang.Integer;@41975e01". Also we might want \" around strings.

builder.append(", ").append(entry.getKey().append(": ");
if (entry.getValue() instanceof Object[]) {
  Object[] array = (Object[])entry.getValue();
  builder.append('[');
  for (int i = 0; i < array.length; ++i) {
    if (i != 0)
      builder.append(", ");
    if (array[i] instanceof String)
      builder.append('"').append(array[i]).append('"');
    else
      builder.append(array[i]);
  }
  builder.append(']');
} else {
  if (value instanceof String)
    builder.append('"').append(value).append('"');
  else
    builder.append(value);
}

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
File webrtc/sdk/android/api/org/webrtc/RTCStatsCollectorCallback.java (right):

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStatsCollectorCallback.java:15: /** Called
when the stats report is ready.*/
nit: Space between . */

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
File webrtc/sdk/android/api/org/webrtc/RTCStatsReport.java (right):

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStatsReport.java:21: this.timestamp_us =
timestamp_us;
nit: timestampUs

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStatsReport.java:44:
builder.append(stat.toString());
nit: append(stat)

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/src/jn...
File webrtc/sdk/android/src/jni/peerconnection_jni.cc (right):

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/src/jn...
webrtc/sdk/android/src/jni/peerconnection_jni.cc:902: ScopedLocalRefFrame
local_ref_frame(jni);
If we should use ScopedLocalRefFrame for each scope we should have this in the
beginning of each function as well. However, I think because these are private
helper functions we can skip ScopedLocalRefFrame altogether relying on each
entrance point from C++ to JNI (that is, OnStatsDelivered) having done the
necessary ScopedLocalRefFrame already.

[Taylor Brandstetter, 2017-04-10 23:59:32]

deadbeef@webrtc.org changed reviewers:
+ magjed@webrtc.org

[Taylor Brandstetter, 2017-04-10 23:59:33]

magjed: PTAL. Also, do you know if there's any reason to use
"ScopedGlobalRef<jclass>", when "ClassReferenceHolder" ends up holding a
reference anyway? I was copying the old getStats implementation, but maybe it's
not right.

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
File webrtc/sdk/android/api/org/webrtc/RTCStats.java (right):

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStats.java:19: *  dictionary. */
On 2017/04/10 10:19:42, hbos wrote:
> nit: Here and elsewhere, /** and */ on separate lines unless the entire
comment
> is a /** single line */.

Done.

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStats.java:21: private final long
timestamp_us;
On 2017/04/10 10:19:42, hbos wrote:
> nit: Here, constructor, getter and toString: timestampUs

Done.

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStats.java:55: *  - Long (for 32-bit
unsigned and 64-bit signed integers)
On 2017/04/10 10:19:42, hbos wrote:
> Being able to distinguish between for example uint32_t and int64_t would only
be
> useful for serialization where we need the types to match between C++ and
Java,
> such as exporting to the same database between two platforms, in all other
cases
> you'd only need to know the Java type. Not sure whether to add a type enum or
> not?

If we don't have a clear use case, I'd suggest just leaving the type enum out
for the time being.

Also, if it had to, an application *could* figure out the type from the name of
the member ("payload_type" will always be a uint32_t, for example).

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStats.java:61: return members;
On 2017/04/10 10:19:42, hbos wrote:
> I thought about returning Collections.unmodifiableSortedMap(members) instead
but
> arrays are mutable even if the map isn't, so we can't go const either way. But
> hey, giving ownership of the stats to the caller makes sense.
> 
> One thing to consider: For arrays, do we return primitive arrays or boxed
> arrrays? E.g.
> - int[]: An array of ints.
> - Integer[]: An array of references to Integer objects wrapping ints.
> 
> One might think int[] makes more sense, but the upside of boxed arrays is they
> can be converted to Object[], primitive arrays can't - there's no "generic"
way
> to iterate primitive arrays, but you can do so with objects, which is good for
> looping through all stats.
> 
> I think the slight overhead is worth Object[], let's do it this way. Looks
more
> consistent too.

I had the same line of thinking about arrays. And I don't have any strong
feelings about returning modifiable/unmodifiable structures.

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStats.java:74: builder.append(",
").append(entry.getKey()).append(": ").append(entry.getValue());
On 2017/04/10 10:19:42, hbos wrote:
> An array toString() is not printed as e.g. "[1, 2, 3]" but as e.g.
> "[Ljava.lang.Integer;@41975e01". Also we might want \" around strings.
> 
> builder.append(", ").append(entry.getKey().append(": ");
> if (entry.getValue() instanceof Object[]) {
>   Object[] array = (Object[])entry.getValue();
>   builder.append('[');
>   for (int i = 0; i < array.length; ++i) {
>     if (i != 0)
>       builder.append(", ");
>     if (array[i] instanceof String)
>       builder.append('"').append(array[i]).append('"');
>     else
>       builder.append(array[i]);
>   }
>   builder.append(']');
> } else {
>   if (value instanceof String)
>     builder.append('"').append(value).append('"');
>   else
>     builder.append(value);
> }

Done, good catch.

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
File webrtc/sdk/android/api/org/webrtc/RTCStatsCollectorCallback.java (right):

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStatsCollectorCallback.java:15: /** Called
when the stats report is ready.*/
On 2017/04/10 10:19:42, hbos wrote:
> nit: Space between . */

Done.

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
File webrtc/sdk/android/api/org/webrtc/RTCStatsReport.java (right):

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStatsReport.java:21: this.timestamp_us =
timestamp_us;
On 2017/04/10 10:19:42, hbos wrote:
> nit: timestampUs

Done (at least my mistake was consistent...)

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStatsReport.java:44:
builder.append(stat.toString());
On 2017/04/10 10:19:42, hbos wrote:
> nit: append(stat)

Done.

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/src/jn...
File webrtc/sdk/android/src/jni/peerconnection_jni.cc (right):

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/src/jn...
webrtc/sdk/android/src/jni/peerconnection_jni.cc:902: ScopedLocalRefFrame
local_ref_frame(jni);
On 2017/04/10 10:19:42, hbos wrote:
> If we should use ScopedLocalRefFrame for each scope we should have this in the
> beginning of each function as well. However, I think because these are private
> helper functions we can skip ScopedLocalRefFrame altogether relying on each
> entrance point from C++ to JNI (that is, OnStatsDelivered) having done the
> necessary ScopedLocalRefFrame already.

Confession: I was just copying the pattern of the previous code without really
understanding why it was necessary. I agree it appears pointless; removing.

EDIT: Oh, it was necessary after all. When I removed it I got:

"JNI ERROR (app bug): local reference table overflow (max=512)"

I guess you can only have 512 local references, and there can easily be more
than 512 things in the stats.

[hbos, 2017-04-11 09:36:13]

lgtm

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
File webrtc/sdk/android/api/org/webrtc/RTCStatsReport.java (right):

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStatsReport.java:21: this.timestamp_us =
timestamp_us;
On 2017/04/10 23:59:33, Taylor Brandstetter wrote:
> On 2017/04/10 10:19:42, hbos wrote:
> > nit: timestampUs
> 
> Done (at least my mistake was consistent...)

:)

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/src/jn...
File webrtc/sdk/android/src/jni/peerconnection_jni.cc (right):

https://codereview.webrtc.org/2807933003/diff/20001/webrtc/sdk/android/src/jn...
webrtc/sdk/android/src/jni/peerconnection_jni.cc:902: ScopedLocalRefFrame
local_ref_frame(jni);
On 2017/04/10 23:59:33, Taylor Brandstetter wrote:
> On 2017/04/10 10:19:42, hbos wrote:
> > If we should use ScopedLocalRefFrame for each scope we should have this in
the
> > beginning of each function as well. However, I think because these are
private
> > helper functions we can skip ScopedLocalRefFrame altogether relying on each
> > entrance point from C++ to JNI (that is, OnStatsDelivered) having done the
> > necessary ScopedLocalRefFrame already.
> 
> Confession: I was just copying the pattern of the previous code without really
> understanding why it was necessary. I agree it appears pointless; removing.
> 
> EDIT: Oh, it was necessary after all. When I removed it I got:
> 
> "JNI ERROR (app bug): local reference table overflow (max=512)"
> 
> I guess you can only have 512 local references, and there can easily be more
> than 512 things in the stats.

Confession: I was just guessing how this JNI stuff works. Good that you caught
the overflow!

[magjed_webrtc, 2017-04-11 12:25:00]

On 2017/04/10 23:59:33, Taylor Brandstetter wrote:
> magjed: PTAL. Also, do you know if there's any reason to use
> "ScopedGlobalRef<jclass>", when "ClassReferenceHolder" ends up holding a
> reference anyway? I was copying the old getStats implementation, but maybe
it's
> not right.

There is no reason to use ScopedGlobalRef<jclass> if ClassReferenceHolder also
has a global reference.

[magjed_webrtc, 2017-04-11 12:25:32]

magjed@webrtc.org changed reviewers:
+ sakal@webrtc.org

[magjed_webrtc, 2017-04-11 12:25:32]

Sami - please review for webrtc/sdk/android ownership.

[sakal, 2017-04-11 12:50:51]

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
File webrtc/sdk/android/api/org/webrtc/PeerConnection.java (right):

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/PeerConnection.java:269: public boolean
getStats(StatsObserver observer, MediaStreamTrack track) {
Mark with @Deprecated?

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
File webrtc/sdk/android/api/org/webrtc/RTCStats.java (right):

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStats.java:20: * RTCStats dictionary.
nit: Please comment this is inner piece for RTCStatsReport.

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStats.java:36: public double timestampUs()
{
It's common in Java to prefix getters with get. I would prefer this consistency.

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStats.java:64: public SortedMap<String,
Object> members() {
nit: I'd prefer to return Map here. It would give more flexibility in the
future.

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
File webrtc/sdk/android/api/org/webrtc/RTCStatsReport.java (right):

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStatsReport.java:15: /** Java version of
webrtc::RTCStatsReport. */
nit: Please comment is RTCStatsReport contains multiple RTCStats entries. It is
not immediately obvious.

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStatsReport.java:32: public
SortedMap<String, RTCStats> stats() {
nit: I would prefer a Map here also.

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStatsReport.java:40: for (RTCStats stat :
stats.values()) {
We are throwing away the key here?

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/src/jn...
File webrtc/sdk/android/src/jni/peerconnection_jni.cc (right):

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/src/jn...
webrtc/sdk/android/src/jni/peerconnection_jni.cc:842: // Adapter for a Java
RTCStatsCollectorCallback presenting a C++
nit: I'd prefer this be in a new file.

[hbos, 2017-04-11 13:02:37]

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
File webrtc/sdk/android/api/org/webrtc/RTCStats.java (right):

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStats.java:64: public SortedMap<String,
Object> members() {
On 2017/04/11 12:50:50, sakal wrote:
> nit: I'd prefer to return Map here. It would give more flexibility in the
> future.

(Oh yeah, consistent ordering doesn't have to mean sorted. In the c++ layer we
promise consistent ordering but it's not alphabetized, rather it uses the same
order as the spec which is a more logical order.)

[Taylor Brandstetter, 2017-04-13 02:33:15]

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
File webrtc/sdk/android/api/org/webrtc/PeerConnection.java (right):

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/PeerConnection.java:269: public boolean
getStats(StatsObserver observer, MediaStreamTrack track) {
On 2017/04/11 12:50:50, sakal wrote:
> Mark with @Deprecated?

Done.

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
File webrtc/sdk/android/api/org/webrtc/RTCStats.java (right):

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStats.java:20: * RTCStats dictionary.
On 2017/04/11 12:50:50, sakal wrote:
> nit: Please comment this is inner piece for RTCStatsReport.

Done.

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStats.java:36: public double timestampUs()
{
On 2017/04/11 12:50:50, sakal wrote:
> It's common in Java to prefix getters with get. I would prefer this
consistency.

Done.

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStats.java:64: public SortedMap<String,
Object> members() {
On 2017/04/11 13:02:37, hbos wrote:
> On 2017/04/11 12:50:50, sakal wrote:
> > nit: I'd prefer to return Map here. It would give more flexibility in the
> > future.
> 
> (Oh yeah, consistent ordering doesn't have to mean sorted. In the c++ layer we
> promise consistent ordering but it's not alphabetized, rather it uses the same
> order as the spec which is a more logical order.)

I completely goofed here. "Predictable iteration order (that matches C++)" was
my intention, but I should have used Map/LinkedHashMap, not SortedMap/TreeMap.

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
File webrtc/sdk/android/api/org/webrtc/RTCStatsReport.java (right):

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStatsReport.java:15: /** Java version of
webrtc::RTCStatsReport. */
On 2017/04/11 12:50:50, sakal wrote:
> nit: Please comment is RTCStatsReport contains multiple RTCStats entries. It
is
> not immediately obvious.

Done.

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStatsReport.java:32: public
SortedMap<String, RTCStats> stats() {
On 2017/04/11 12:50:50, sakal wrote:
> nit: I would prefer a Map here also.

Done.

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStatsReport.java:40: for (RTCStats stat :
stats.values()) {
On 2017/04/11 12:50:51, sakal wrote:
> We are throwing away the key here?

Each key is just "stat.id()". I'm mainly returning a map as a convenience to
look up stats by ID, but I could also just return an array of RTCStats and add a
"getStatsById" helper method. Would you prefer that?

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/src/jn...
File webrtc/sdk/android/src/jni/peerconnection_jni.cc (right):

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/src/jn...
webrtc/sdk/android/src/jni/peerconnection_jni.cc:842: // Adapter for a Java
RTCStatsCollectorCallback presenting a C++
On 2017/04/11 12:50:51, sakal wrote:
> nit: I'd prefer this be in a new file.

Done.

[magjed_webrtc, 2017-04-13 09:00:04]

Description was changed from

==========
Add Java binding for new getStats implementation.

Very similar to the current interface, but matches the new C++ structure, and
exposes the stats values as Objects which can be downcast to more specific
types (where the previous API only exposed the values as strings).

BUG=webrtc:6871
==========

to

==========
Add Java binding for new getStats implementation.

Very similar to the current interface, but matches the new C++ structure, and
exposes the stats values as Objects which can be downcast to more specific
types (where the previous API only exposed the values as strings).

BUG=webrtc:6871
==========

[magjed_webrtc, 2017-04-13 09:00:04]

magjed@webrtc.org changed reviewers:
- magjed@webrtc.org

[sakal, 2017-04-18 11:10:20]

lgtm

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
File webrtc/sdk/android/api/org/webrtc/RTCStatsReport.java (right):

https://codereview.webrtc.org/2807933003/diff/40001/webrtc/sdk/android/api/or...
webrtc/sdk/android/api/org/webrtc/RTCStatsReport.java:40: for (RTCStats stat :
stats.values()) {
On 2017/04/13 02:33:15, Taylor Brandstetter wrote:
> On 2017/04/11 12:50:51, sakal wrote:
> > We are throwing away the key here?
> 
> Each key is just "stat.id()". I'm mainly returning a map as a convenience to
> look up stats by ID, but I could also just return an array of RTCStats and add
a
> "getStatsById" helper method. Would you prefer that?

This is fine since the id is included in the objects.

[Taylor Brandstetter, 2017-04-18 16:52:53]

The CQ bit was checked by deadbeef@webrtc.org

[Taylor Brandstetter, 2017-04-18 16:52:54]

The patchset sent to the CQ was uploaded after l-g-t-m from hbos@webrtc.org
Link to the patchset: https://codereview.webrtc.org/2807933003/#ps80001 (title:
"Responding to sakal@'s comments")

[commit-bot: I haz the power, 2017-04-18 16:52:55]

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, 2017-04-18 17:27:52]

CQ is committing da patch.

Bot data: {"patchset_id": 80001, "attempt_start_ts": 1492534373891220,
"parent_rev": "0fafb1ac8fa2906669ac30e68fd431600c8bcdc6", "commit_rev":
"82215872f8f75410366cb5cb986e816fe8f77364"}

[commit-bot: I haz the power, 2017-04-18 17:27:55]

Description was changed from

==========
Add Java binding for new getStats implementation.

Very similar to the current interface, but matches the new C++ structure, and
exposes the stats values as Objects which can be downcast to more specific
types (where the previous API only exposed the values as strings).

BUG=webrtc:6871
==========

to

==========
Add Java binding for new getStats implementation.

Very similar to the current interface, but matches the new C++ structure, and
exposes the stats values as Objects which can be downcast to more specific
types (where the previous API only exposed the values as strings).

BUG=webrtc:6871

Review-Url: https://codereview.webrtc.org/2807933003
Cr-Commit-Position: refs/heads/master@{#17746}
Committed:
https://chromium.googlesource.com/external/webrtc/+/82215872f8f75410366cb5cb9...
==========

[commit-bot: I haz the power, 2017-04-18 17:27:56]

Committed patchset #5 (id:80001) as
https://chromium.googlesource.com/external/webrtc/+/82215872f8f75410366cb5cb9...