Android: Remove unneeded RegisterNatives() calls

Android: Remove unneeded RegisterNatives() calls

Removes the remainder of the calls for where there
are no (Java-to-)native methods, which is possible after
https://codereview.chromium.org/2204623002/
which marks empty NOP RegisterNatives() functions
with the 'unused' attribute.

As a follow-up the JNI generator can be changed to
not even emit the unneeded functions:
https://codereview.chromium.org/2199973003/

BUG=603936
Committed: https://crrev.com/7264b763e7fc5da2d733c07a24c69303cb73a8f5
Cr-Commit-Position: refs/heads/master@{#409599}

[no sievers, 2016-07-13 01:46:47]

Description was changed from

==========
Android: Don't require RegisterNatives if there are none

A lot of native code only calls up into Java.
And JNI being a legit object boundary it's actually a good pattern
to not mix interfaces with different directions.
When there are no native methods have the JNI generator not
emit an empty RegisterNatives() function and remove all the
code that was essentially calling NOP methods.

BUG=617313,617324
==========

to

==========
Android: Don't require RegisterNatives if there are none

A lot of native code only calls up into Java.
And JNI being a legit object boundary it's actually a good pattern
to not mix interfaces with different directions.
When there are no native methods have the JNI generator not
emit an empty RegisterNatives() function and remove all the
code that was essentially calling NOP methods.

BUG=617313,617324
==========

[no sievers, 2016-07-13 01:46:48]

sievers@chromium.org changed reviewers:
+ torne@chromium.org

[no sievers, 2016-07-13 01:47:26]

Description was changed from

==========
Android: Don't require RegisterNatives if there are none

A lot of native code only calls up into Java.
And JNI being a legit object boundary it's actually a good pattern
to not mix interfaces with different directions.
When there are no native methods have the JNI generator not
emit an empty RegisterNatives() function and remove all the
code that was essentially calling NOP methods.

BUG=617313,617324
==========

to

==========
Android: Don't require RegisterNatives if there are none

A lot of native code only calls up into Java.
And JNI being a legit object boundary it's actually a good pattern
to not mix interfaces with different directions
(i.e. often it's just delegating something up or calling
into an SDK API etc.)

When there are no native methods have the JNI generator not
emit an empty RegisterNatives() function and remove all the
code that was essentially calling NOP methods.

BUG=617313,617324
==========

[no sievers, 2016-07-13 01:47:47]

ptal

https://codereview.chromium.org/2146753002/diff/1/base/android/jni_generator/...
File base/android/jni_generator/jni_generator.py (right):

https://codereview.chromium.org/2146753002/diff/1/base/android/jni_generator/...
base/android/jni_generator/jni_generator.py:819: """Returns the implementation
of the array of native methods."""
maybe this should also have an early-out? can i check 'not self.natives' or so?

[no sievers, 2016-07-13 01:54:53]

Description was changed from

==========
Android: Don't require RegisterNatives if there are none

A lot of native code only calls up into Java.
And JNI being a legit object boundary it's actually a good pattern
to not mix interfaces with different directions
(i.e. often it's just delegating something up or calling
into an SDK API etc.)

When there are no native methods have the JNI generator not
emit an empty RegisterNatives() function and remove all the
code that was essentially calling NOP methods.

BUG=617313,617324
==========

to

==========
Android: Don't require RegisterNatives if there are none

A lot of native code only calls up into Java.
And JNI being a legit object boundary it's actually a good pattern
to not mix interfaces with different directions
(Java->native and native->Java i.e. a lot of these are
delegate interfaces or calls into the SDK).

When there are no native methods have the JNI generator not
emit an empty RegisterNatives() function and remove all the
code that was essentially calling NOP methods.

BUG=617313,617324
==========

[Torne, 2016-07-13 11:04:01]

So there's a bug specifically for this and I had a go at it previously (though
didn't upload a CL as I got distracted):
https://bugs.chromium.org/p/chromium/issues/detail?id=603936

There's a couple of problems with what you're doing here:

1) It breaks the JNI generator tests because you didn't rebaseline them (they
run at compile time, which is why the android bot failed with a compile error) -
did you not build "all"?

2) This will actually cause runtime crashes for any code compiled with
--native_exports disabled, because when native exports aren't used, we don't
lazy-initialise the class reference, and rely on it being done at startup by
RegisterNatives, even for classes which have no natives.

Probably what we want to do is actually remove the --native_exports flag
entirely and behave as if it's always enabled. The eager registration only mode
is never used when compiling chromium. I started looking at this when removing
other unused features previously, but didn't get that far. The tests currently
are written for the non-native case, though, and only a couple of tests bother
to run it with native exports enabled; they probably need looking at and
rearranging so that they actually cover all the things we care about.


So there's a couple of options here:

1) Only skip generating RegisterNatives if in native exports mode. This will
make the JNI generator still work consistently, but won't allow Chromium to
actually switch between the two modes since it'd require other changes to the
code (patching all the rest of your changes here in/out).

2) Make it always run in native exports mode and fix up the tests to be
sensible.

3) Ask if I can do 2) for you since I was intending to do this anyway, and just
haven't gotten around to it. ;)

[no sievers, 2016-07-13 17:14:40]

Description was changed from

==========
Android: Don't require RegisterNatives if there are none

A lot of native code only calls up into Java.
And JNI being a legit object boundary it's actually a good pattern
to not mix interfaces with different directions
(Java->native and native->Java i.e. a lot of these are
delegate interfaces or calls into the SDK).

When there are no native methods have the JNI generator not
emit an empty RegisterNatives() function and remove all the
code that was essentially calling NOP methods.

BUG=617313,617324
==========

to

==========
Android: Don't require RegisterNatives if there are none

A lot of native code only calls up into Java.
And JNI being a legit object boundary it's actually a good pattern
to not mix interfaces with different directions
(Java->native and native->Java i.e. a lot of these are
delegate interfaces or calls into the SDK).

When there are no native methods have the JNI generator not
emit an empty RegisterNatives() function and remove all the
code that was essentially calling NOP methods.

BUG=603936,617313,617324
==========

[no sievers, 2016-07-13 17:18:36]

On 2016/07/13 11:04:01, Torne wrote:
> So there's a bug specifically for this and I had a go at it previously (though
> didn't upload a CL as I got distracted):
> https://bugs.chromium.org/p/chromium/issues/detail?id=603936
> 

Ah good, I figured there must be :)

I just happened to come across it yesterday and it nagged me so I had a go at
it.

> 
> 2) Make it always run in native exports mode and fix up the tests to be
> sensible.
> 
> 3) Ask if I can do 2) for you since I was intending to do this anyway, and
just
> haven't gotten around to it. ;)

2) and 3) sound good to me. Now that I discovered there are so many call sites
that call empty functions, it'd be nice to get rid of them and it would also be
slightly easier to add bindings to Java upcalls only without having to do this
registration dance (otherwise you get the unused function linker error).

[no sievers, 2016-07-13 17:20:05]

On 2016/07/13 17:18:36, sievers wrote:
> On 2016/07/13 11:04:01, Torne wrote:
> > So there's a bug specifically for this and I had a go at it previously
(though
> > didn't upload a CL as I got distracted):
> > https://bugs.chromium.org/p/chromium/issues/detail?id=603936
> > 
> 
> Ah good, I figured there must be :)
> 
> I just happened to come across it yesterday and it nagged me so I had a go at
> it.
> 
> > 
> > 2) Make it always run in native exports mode and fix up the tests to be
> > sensible.
> > 
> > 3) Ask if I can do 2) for you since I was intending to do this anyway, and
> just
> > haven't gotten around to it. ;)
> 
> 2) and 3) sound good to me. Now that I discovered there are so many call sites
> that call empty functions, it'd be nice to get rid of them and it would also
be
> slightly easier to add bindings to Java upcalls only without having to do this
> registration dance (otherwise you get the unused function linker error).

I guess this could also be a separate patch that converts the tests and then
this could land on top of it?

[Torne, 2016-07-14 12:45:32]

On 2016/07/13 17:20:05, sievers wrote:
> On 2016/07/13 17:18:36, sievers wrote:
> > On 2016/07/13 11:04:01, Torne wrote:
> > > So there's a bug specifically for this and I had a go at it previously
> (though
> > > didn't upload a CL as I got distracted):
> > > https://bugs.chromium.org/p/chromium/issues/detail?id=603936
> > > 
> > 
> > Ah good, I figured there must be :)
> > 
> > I just happened to come across it yesterday and it nagged me so I had a go
at
> > it.
> > 
> > > 
> > > 2) Make it always run in native exports mode and fix up the tests to be
> > > sensible.
> > > 
> > > 3) Ask if I can do 2) for you since I was intending to do this anyway, and
> > just
> > > haven't gotten around to it. ;)
> > 
> > 2) and 3) sound good to me. Now that I discovered there are so many call
sites
> > that call empty functions, it'd be nice to get rid of them and it would also
> be
> > slightly easier to add bindings to Java upcalls only without having to do
this
> > registration dance (otherwise you get the unused function linker error).
> 
> I guess this could also be a separate patch that converts the tests and then
> this could land on top of it?

Yeah, probably easier to remove the option and fix up the tests separately and
then land this afterward.

[Torne, 2016-07-18 14:16:28]

On 2016/07/14 12:45:32, Torne wrote:
> On 2016/07/13 17:20:05, sievers wrote:
> > On 2016/07/13 17:18:36, sievers wrote:
> > > On 2016/07/13 11:04:01, Torne wrote:
> > > > So there's a bug specifically for this and I had a go at it previously
> > (though
> > > > didn't upload a CL as I got distracted):
> > > > https://bugs.chromium.org/p/chromium/issues/detail?id=603936
> > > > 
> > > 
> > > Ah good, I figured there must be :)
> > > 
> > > I just happened to come across it yesterday and it nagged me so I had a go
> at
> > > it.
> > > 
> > > > 
> > > > 2) Make it always run in native exports mode and fix up the tests to be
> > > > sensible.
> > > > 
> > > > 3) Ask if I can do 2) for you since I was intending to do this anyway,
and
> > > just
> > > > haven't gotten around to it. ;)
> > > 
> > > 2) and 3) sound good to me. Now that I discovered there are so many call
> sites
> > > that call empty functions, it'd be nice to get rid of them and it would
also
> > be
> > > slightly easier to add bindings to Java upcalls only without having to do
> this
> > > registration dance (otherwise you get the unused function linker error).
> > 
> > I guess this could also be a separate patch that converts the tests and then
> > this could land on top of it?
> 
> Yeah, probably easier to remove the option and fix up the tests separately and
> then land this afterward.

I started removing the native_exports option and think I've found a bug in the
generator in the process, so that's nice. Will sort that out ;)

[Torne, 2016-07-25 11:32:47]

On 2016/07/18 14:16:28, Torne wrote:
> On 2016/07/14 12:45:32, Torne wrote:
> > On 2016/07/13 17:20:05, sievers wrote:
> > > On 2016/07/13 17:18:36, sievers wrote:
> > > > On 2016/07/13 11:04:01, Torne wrote:
> > > > > So there's a bug specifically for this and I had a go at it previously
> > > (though
> > > > > didn't upload a CL as I got distracted):
> > > > > https://bugs.chromium.org/p/chromium/issues/detail?id=603936
> > > > > 
> > > > 
> > > > Ah good, I figured there must be :)
> > > > 
> > > > I just happened to come across it yesterday and it nagged me so I had a
go
> > at
> > > > it.
> > > > 
> > > > > 
> > > > > 2) Make it always run in native exports mode and fix up the tests to
be
> > > > > sensible.
> > > > > 
> > > > > 3) Ask if I can do 2) for you since I was intending to do this anyway,
> and
> > > > just
> > > > > haven't gotten around to it. ;)
> > > > 
> > > > 2) and 3) sound good to me. Now that I discovered there are so many call
> > sites
> > > > that call empty functions, it'd be nice to get rid of them and it would
> also
> > > be
> > > > slightly easier to add bindings to Java upcalls only without having to
do
> > this
> > > > registration dance (otherwise you get the unused function linker error).
> > > 
> > > I guess this could also be a separate patch that converts the tests and
then
> > > this could land on top of it?
> > 
> > Yeah, probably easier to remove the option and fix up the tests separately
and
> > then land this afterward.
> 
> I started removing the native_exports option and think I've found a bug in the
> generator in the process, so that's nice. Will sort that out ;)

I removed the option and updated the tests. Do you want to rebase and land this
now? Make sure to rebaseline the JNI generator tests in the new CL :)

[no sievers, 2016-07-26 00:54:47]

On 2016/07/25 11:32:47, Torne wrote:
> On 2016/07/18 14:16:28, Torne wrote:
> > On 2016/07/14 12:45:32, Torne wrote:
> > > On 2016/07/13 17:20:05, sievers wrote:
> > > > On 2016/07/13 17:18:36, sievers wrote:
> > > > > On 2016/07/13 11:04:01, Torne wrote:
> > > > > > So there's a bug specifically for this and I had a go at it
previously
> > > > (though
> > > > > > didn't upload a CL as I got distracted):
> > > > > > https://bugs.chromium.org/p/chromium/issues/detail?id=603936
> > > > > > 
> > > > > 
> > > > > Ah good, I figured there must be :)
> > > > > 
> > > > > I just happened to come across it yesterday and it nagged me so I had
a
> go
> > > at
> > > > > it.
> > > > > 
> > > > > > 
> > > > > > 2) Make it always run in native exports mode and fix up the tests to
> be
> > > > > > sensible.
> > > > > > 
> > > > > > 3) Ask if I can do 2) for you since I was intending to do this
anyway,
> > and
> > > > > just
> > > > > > haven't gotten around to it. ;)
> > > > > 
> > > > > 2) and 3) sound good to me. Now that I discovered there are so many
call
> > > sites
> > > > > that call empty functions, it'd be nice to get rid of them and it
would
> > also
> > > > be
> > > > > slightly easier to add bindings to Java upcalls only without having to
> do
> > > this
> > > > > registration dance (otherwise you get the unused function linker
error).
> > > > 
> > > > I guess this could also be a separate patch that converts the tests and
> then
> > > > this could land on top of it?
> > > 
> > > Yeah, probably easier to remove the option and fix up the tests separately
> and
> > > then land this afterward.
> > 
> > I started removing the native_exports option and think I've found a bug in
the
> > generator in the process, so that's nice. Will sort that out ;)
> 
> I removed the option and updated the tests. Do you want to rebase and land
this
> now? Make sure to rebaseline the JNI generator tests in the new CL :)

Thanks that's great! Yes I'll take a look and rebase this.

Let me know if you want me to do anything more fancy in the generator script or
add some checks to make sure this is all consistent.

[no sievers, 2016-07-29 23:20:59]

ok, rebased

99.9% compiling.. feel free to wait until I can get this through a CQ dry run
successfully.

 checking owners took a long time: 107541ms :-)

[Torne, 2016-08-01 11:51:41]

https://codereview.chromium.org/2146753002/diff/40001/base/android/jni_genera...
File base/android/jni_generator/jni_generator.py (left):

https://codereview.chromium.org/2146753002/diff/40001/base/android/jni_genera...
base/android/jni_generator/jni_generator.py:743: // Step 3: RegisterNatives.
I don't think you should remove this comment - it makes files where "step 3" is
actually present look weird :)

https://codereview.chromium.org/2146753002/diff/40001/base/android/jni_genera...
base/android/jni_generator/jni_generator.py:1104: /* Must call
RegisterNativesImpl()  */
While it does make sense to remove this comment, can you do that in a followup
CL so that the changes to the golden test file are only the "functional" bits
and it's easy to see what actually changed about the code generation?

[Torne, 2016-08-01 11:54:00]

Oh, also, if this is proving too difficult to rebase and land, there's a way to
do this incrementally: instead of omitting RegisterNatives when it's empty, just
mark it with attribute unused so that the compiler allows it to not be called
(only if there are no natives, of course).

That way, you can submit an "incomplete" change that only removes some of the
calls, and have a couple of (increasingly small) rounds of cleanup before
landing the final change that removes the method entirely.

Don't have to do this, just an idea if the logistics are challenging.

[no sievers, 2016-08-01 22:47:29]

Description was changed from

==========
Android: Don't require RegisterNatives if there are none

A lot of native code only calls up into Java.
And JNI being a legit object boundary it's actually a good pattern
to not mix interfaces with different directions
(Java->native and native->Java i.e. a lot of these are
delegate interfaces or calls into the SDK).

When there are no native methods have the JNI generator not
emit an empty RegisterNatives() function and remove all the
code that was essentially calling NOP methods.

BUG=603936,617313,617324
==========

to

==========
Android: Remove unneeded RegisterNatives() calls

Removes the remainder of the calls.
See https://codereview.chromium.org/2204623002/

BUG=603936
==========

[no sievers, 2016-08-01 22:51:53]

Done. I've split this up as follows and then uploaded the remainder (where it
got trickier to split) into this issue (ps4), so ptal here also.

Mark with attrib unused: https://codereview.chromium.org/2204623002/

android_webview: https://codereview.chromium.org/2202783002/

base: https://codereview.chromium.org/2202793002

blimp: https://codereview.chromium.org/2194403003/

media: https://codereview.chromium.org/2199913003/#

ui: https://codereview.chromium.org/2202033002/

[Torne, 2016-08-02 12:34:49]

lgtm

[no sievers, 2016-08-02 21:45:40]

The CQ bit was checked by sievers@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-02 21:46:13]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[no sievers, 2016-08-02 21:52:55]

sievers@chromium.org changed reviewers:
+ dtrainor@chromium.org, jochen@chromium.org, rockot@chromium.org,,
rsleevi@chromium.org, wez@chromium.org

[no sievers, 2016-08-02 21:54:31]

Adding some OWNERS:

dtrainor@ for chrome/ android

jochen@ for components/

rockot@ for device/

wez@ for remoting/

rsleevi@ for net/

[no sievers, 2016-08-02 22:01:44]

Description was changed from

==========
Android: Remove unneeded RegisterNatives() calls

Removes the remainder of the calls.
See https://codereview.chromium.org/2204623002/

BUG=603936
==========

to

==========
Android: Remove unneeded RegisterNatives() calls

Removes the remainder of the calls for where there
are no native methods, see https://codereview.chromium.org/2204623002/

BUG=603936
==========

[commit-bot: I haz the power, 2016-08-02 22:10:13]

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

[commit-bot: I haz the power, 2016-08-02 22:10:15]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)

[Ryan Sleevi, 2016-08-02 22:10:26]

LGTM for net/

This CL alone was a bit hard to understand, and the bug itself wasn't
immediately clear, but the commit descriptions on other patches helped me
understand :)

[no sievers, 2016-08-02 22:26:12]

Description was changed from

==========
Android: Remove unneeded RegisterNatives() calls

Removes the remainder of the calls for where there
are no native methods, see https://codereview.chromium.org/2204623002/

BUG=603936
==========

to

==========
Android: Remove unneeded RegisterNatives() calls

Removes the remainder of the calls for where there
are no native methods, which is possible after
https://codereview.chromium.org/2204623002/
which marks empty NOP RegisterNative() functions
with the 'unused' attribute.

As a follow-up the JNI generator can be changed to
not even emit the unneeded functions:
https://codereview.chromium.org/2199973003/

BUG=603936
==========

[no sievers, 2016-08-02 22:26:34]

Description was changed from

==========
Android: Remove unneeded RegisterNatives() calls

Removes the remainder of the calls for where there
are no native methods, which is possible after
https://codereview.chromium.org/2204623002/
which marks empty NOP RegisterNative() functions
with the 'unused' attribute.

As a follow-up the JNI generator can be changed to
not even emit the unneeded functions:
https://codereview.chromium.org/2199973003/

BUG=603936
==========

to

==========
Android: Remove unneeded RegisterNatives() calls

Removes the remainder of the calls for where there
are no native methods, which is possible after
https://codereview.chromium.org/2204623002/
which marks empty NOP RegisterNatives() functions
with the 'unused' attribute.

As a follow-up the JNI generator can be changed to
not even emit the unneeded functions:
https://codereview.chromium.org/2199973003/

BUG=603936
==========

[no sievers, 2016-08-02 22:26:57]

On 2016/08/02 22:10:26, Ryan Sleevi (slow) wrote:
> LGTM for net/
> 
> This CL alone was a bit hard to understand, and the bug itself wasn't
> immediately clear, but the commit descriptions on other patches helped me
> understand :)

thanks, I've updated the description a bit.

[Ryan Sleevi, 2016-08-02 22:28:58]

On 2016/08/02 22:26:57, sievers wrote:
> On 2016/08/02 22:10:26, Ryan Sleevi (slow) wrote:
> > LGTM for net/
> > 
> > This CL alone was a bit hard to understand, and the bug itself wasn't
> > immediately clear, but the commit descriptions on other patches helped me
> > understand :)
> 
> thanks, I've updated the description a bit.

Awesome, thanks :) That covers what I understood the goal to be :)

[no sievers, 2016-08-02 22:35:27]

The CQ bit was checked by sievers@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-02 22:36:13]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Wez, 2016-08-02 22:40:52]

wez@chromium.org changed reviewers:
+ sergeyu@chromium.org
- wez@chromium.org

[Wez, 2016-08-02 22:40:54]

wez -> sergeyu

[Ken Rockot(use gerrit already), 2016-08-02 22:52:28]

rockot@chromium.org changed reviewers:
+ rockot@chromium.org
- rockot@chromium.org,

[Ken Rockot(use gerrit already), 2016-08-02 22:52:29]

lgtm

[Sergey Ulanov, 2016-08-02 22:52:30]

sergeyu@chromium.org changed reviewers:
+ rockot@chromium.org,
- rockot@chromium.org

[Sergey Ulanov, 2016-08-02 22:52:32]

lgtm

[commit-bot: I haz the power, 2016-08-03 00:14:55]

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

[commit-bot: I haz the power, 2016-08-03 00:14:57]

Dry run: This issue passed the CQ dry run.

[jochen (gone - plz use gerrit), 2016-08-03 15:24:35]

jochen@chromium.org changed reviewers:
+ rockot@chromium.org
- rockot@chromium.org,

[jochen (gone - plz use gerrit), 2016-08-03 15:24:37]

lgtm with comment addressed

https://codereview.chromium.org/2146753002/diff/120001/content/browser/mojo/s...
File content/browser/mojo/service_registrar_android.h (right):

https://codereview.chromium.org/2146753002/diff/120001/content/browser/mojo/s...
content/browser/mojo/service_registrar_android.h:16: class
ServiceRegistrarAndroid {
please make this a namespace:
https://google.github.io/styleguide/cppguide.html#Nonmember,_Static_Member,_a...

[David Trainor- moved to gerrit, 2016-08-03 15:53:42]

chrome/*/android lgtm thanks!

[no sievers, 2016-08-03 18:23:02]

https://codereview.chromium.org/2146753002/diff/120001/content/browser/mojo/s...
File content/browser/mojo/service_registrar_android.h (right):

https://codereview.chromium.org/2146753002/diff/120001/content/browser/mojo/s...
content/browser/mojo/service_registrar_android.h:16: class
ServiceRegistrarAndroid {
On 2016/08/03 15:24:37, jochen wrote:
> please make this a namespace:
>
https://google.github.io/styleguide/cppguide.html#Nonmember,_Static_Member,_a...

oops, this is actually a bad rebase. this file was deleted. fixed.

[no sievers, 2016-08-03 18:23:25]

Description was changed from

==========
Android: Remove unneeded RegisterNatives() calls

Removes the remainder of the calls for where there
are no native methods, which is possible after
https://codereview.chromium.org/2204623002/
which marks empty NOP RegisterNatives() functions
with the 'unused' attribute.

As a follow-up the JNI generator can be changed to
not even emit the unneeded functions:
https://codereview.chromium.org/2199973003/

BUG=603936
==========

to

==========
Android: Remove unneeded RegisterNatives() calls

Removes the remainder of the calls for where there
are no (Java-to-)native methods, which is possible after
https://codereview.chromium.org/2204623002/
which marks empty NOP RegisterNatives() functions
with the 'unused' attribute.

As a follow-up the JNI generator can be changed to
not even emit the unneeded functions:
https://codereview.chromium.org/2199973003/

BUG=603936
==========

[no sievers, 2016-08-03 18:23:36]

The CQ bit was checked by sievers@chromium.org

[no sievers, 2016-08-03 18:23:37]

The patchset sent to the CQ was uploaded after l-g-t-m from torne@chromium.org,
rsleevi@chromium.org, rockot@chromium.org, dtrainor@chromium.org,
jochen@chromium.org, sergeyu@chromium.org
Link to the patchset: https://codereview.chromium.org/2146753002/#ps140001
(title: "Android: Don't require RegisterNatives if there are none")

[commit-bot: I haz the power, 2016-08-03 18:24:15]

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

[commit-bot: I haz the power, 2016-08-03 19:54:05]

Description was changed from

==========
Android: Remove unneeded RegisterNatives() calls

Removes the remainder of the calls for where there
are no (Java-to-)native methods, which is possible after
https://codereview.chromium.org/2204623002/
which marks empty NOP RegisterNatives() functions
with the 'unused' attribute.

As a follow-up the JNI generator can be changed to
not even emit the unneeded functions:
https://codereview.chromium.org/2199973003/

BUG=603936
==========

to

==========
Android: Remove unneeded RegisterNatives() calls

Removes the remainder of the calls for where there
are no (Java-to-)native methods, which is possible after
https://codereview.chromium.org/2204623002/
which marks empty NOP RegisterNatives() functions
with the 'unused' attribute.

As a follow-up the JNI generator can be changed to
not even emit the unneeded functions:
https://codereview.chromium.org/2199973003/

BUG=603936
==========

[commit-bot: I haz the power, 2016-08-03 19:54:08]

Committed patchset #8 (id:140001)

[commit-bot: I haz the power, 2016-08-03 19:57:04]

Description was changed from

==========
Android: Remove unneeded RegisterNatives() calls

Removes the remainder of the calls for where there
are no (Java-to-)native methods, which is possible after
https://codereview.chromium.org/2204623002/
which marks empty NOP RegisterNatives() functions
with the 'unused' attribute.

As a follow-up the JNI generator can be changed to
not even emit the unneeded functions:
https://codereview.chromium.org/2199973003/

BUG=603936
==========

to

==========
Android: Remove unneeded RegisterNatives() calls

Removes the remainder of the calls for where there
are no (Java-to-)native methods, which is possible after
https://codereview.chromium.org/2204623002/
which marks empty NOP RegisterNatives() functions
with the 'unused' attribute.

As a follow-up the JNI generator can be changed to
not even emit the unneeded functions:
https://codereview.chromium.org/2199973003/

BUG=603936

Committed: https://crrev.com/7264b763e7fc5da2d733c07a24c69303cb73a8f5
Cr-Commit-Position: refs/heads/master@{#409599}
==========

[commit-bot: I haz the power, 2016-08-03 19:57:07]

Patchset 8 (id:??) landed as
https://crrev.com/7264b763e7fc5da2d733c07a24c69303cb73a8f5
Cr-Commit-Position: refs/heads/master@{#409599}

[pauljensen, 2017-04-13 11:26:55]

pauljensen@chromium.org changed reviewers:
+ pauljensen@chromium.org

[pauljensen, 2017-04-13 11:26:58]

It looks like this CL left a number of #includes unused.  I looked over the net/
directory and found three.

https://codereview.chromium.org/2146753002/diff/140001/net/android/cellular_s...
File net/android/cellular_signal_strength.h (right):

https://codereview.chromium.org/2146753002/diff/140001/net/android/cellular_s...
net/android/cellular_signal_strength.h:8: #include <jni.h>
This is unused now.

https://codereview.chromium.org/2146753002/diff/140001/net/android/network_li...
File net/android/network_library.h (right):

https://codereview.chromium.org/2146753002/diff/140001/net/android/network_li...
net/android/network_library.h:8: #include <jni.h>
This looks unused now.

https://codereview.chromium.org/2146753002/diff/140001/net/android/traffic_st...
File net/android/traffic_stats.h (right):

https://codereview.chromium.org/2146753002/diff/140001/net/android/traffic_st...
net/android/traffic_stats.h:11: #include <jni.h>
This is unused now.