Remove dom_distiller core dependency on content

Remove dom_distiller core dependency on content

This change removes the top level android directory from dom_distiller
and splits it into content/browser/android and core/android. The two
directories now each have their own JNI registrar that allows them to
depend on appropriate parts of the component.

BUG=562769
TBR=yfriedman@chromium.org

Committed: https://crrev.com/fd194b338274f4a2eba70021f739c3b93e07be99
Cr-Commit-Position: refs/heads/master@{#415400}

[mdjones, 2016-08-18 01:07:14]

mdjones@chromium.org changed reviewers:
+ nyquist@chromium.org

[mdjones, 2016-08-18 01:07:14]

ptal

[nyquist, 2016-08-24 00:09:33]

lgtm

https://codereview.chromium.org/2252963004/diff/1/components/dom_distiller/co...
File components/dom_distiller/content/browser/android/component_jni_registrar.h
(right):

https://codereview.chromium.org/2252963004/diff/1/components/dom_distiller/co...
components/dom_distiller/content/browser/android/component_jni_registrar.h:5:
#ifndef
COMPONENTS_DOM_DISTILLER_CONTENT_BROWSER_ANDROID_COMPONENT_JNI_REGISTRAR_H_
How about content_jni_registrar?

https://codereview.chromium.org/2252963004/diff/1/components/dom_distiller/co...
File components/dom_distiller/core/android/component_jni_registrar.h (right):

https://codereview.chromium.org/2252963004/diff/1/components/dom_distiller/co...
components/dom_distiller/core/android/component_jni_registrar.h:5: #ifndef
COMPONENTS_DOM_DISTILLER_CORE_ANDROID_COMPONENT_JNI_REGISTRAR_H_
How about core_jni_registrar?

[mdjones, 2016-08-24 00:54:47]

https://codereview.chromium.org/2252963004/diff/1/components/dom_distiller/co...
File components/dom_distiller/content/browser/android/component_jni_registrar.h
(right):

https://codereview.chromium.org/2252963004/diff/1/components/dom_distiller/co...
components/dom_distiller/content/browser/android/component_jni_registrar.h:5:
#ifndef
COMPONENTS_DOM_DISTILLER_CONTENT_BROWSER_ANDROID_COMPONENT_JNI_REGISTRAR_H_
On 2016/08/24 00:09:32, nyquist wrote:
> How about content_jni_registrar?

Done.

https://codereview.chromium.org/2252963004/diff/1/components/dom_distiller/co...
File components/dom_distiller/core/android/component_jni_registrar.h (right):

https://codereview.chromium.org/2252963004/diff/1/components/dom_distiller/co...
components/dom_distiller/core/android/component_jni_registrar.h:5: #ifndef
COMPONENTS_DOM_DISTILLER_CORE_ANDROID_COMPONENT_JNI_REGISTRAR_H_
On 2016/08/24 00:09:32, nyquist wrote:
> How about core_jni_registrar?

Done.

[mdjones, 2016-08-24 00:55:08]

The CQ bit was checked by mdjones@chromium.org

[mdjones, 2016-08-24 00:55:08]

The patchset sent to the CQ was uploaded after l-g-t-m from nyquist@chromium.org
Link to the patchset: https://codereview.chromium.org/2252963004/#ps20001
(title: "address comments")

[commit-bot: I haz the power, 2016-08-24 00:56:05]

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-24 01:05:21]

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

[commit-bot: I haz the power, 2016-08-24 01:05:22]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[blundell, 2016-08-24 08:24:54]

On 2016/08/24 01:05:22, commit-bot: I haz the power wrote:
> Try jobs failed on following builders:
>   chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

Please don't land this until the following question is resolved:

Why have //components/dom_distiller/core/android? (Looking at the bug didn't
shed insight on the split that you're making here). The core/ subdirectory of a
component is by definition for code shared on multiple platforms, so having
platform-specific code in there is suspicious.

Remember that it's fine (and expected) for a content/ subdirectory of a
component to depend on the corresponding core/ subdirectory; it's just the other
way around that's conceptually wrong.

[blundell, 2016-08-24 08:33:03]

On 2016/08/24 08:24:54, blundell wrote:
> On 2016/08/24 01:05:22, commit-bot: I haz the power wrote:
> > Try jobs failed on following builders:
> >   chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
> >
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
> 
> Please don't land this until the following question is resolved:
> 
> Why have //components/dom_distiller/core/android? (Looking at the bug didn't
> shed insight on the split that you're making here). The core/ subdirectory of
a
> component is by definition for code shared on multiple platforms, so having
> platform-specific code in there is suspicious.
> 
> Remember that it's fine (and expected) for a content/ subdirectory of a
> component to depend on the corresponding core/ subdirectory; it's just the
other
> way around that's conceptually wrong.

OK, I understand the reason now: dom_distiller_service_android.* depends on the
JNI bindings for DomDistillerService.java (I assumed that the reason was
something like this but was initially confused because there weren't any include
path changes in this CL; I then saw that they weren't needed due to include dir
magic). I think it would be better to just move dom_distiller_service_android.*
to //components/dom_distiller/content/browser/android and keep all the android
stuff grouped together. That way you (1) avoid splitting the Android-specific
files between core/ and content/, and (2) allow dom_distiller_service_android.*
free access to any //content-specific stuff it might need in the future.

[blundell, 2016-08-24 08:34:02]

Description was changed from

==========
Remove dom_distiller core dependency on content

This change removes the top level android directory from dom_distiller
and splits it into content/browser/android and core/android. The two
directories now each have their own JNI registrar that allows them to
depend on appropriate parts of the component.

BUG=562769
==========

to

==========
Remove dom_distiller core dependency on content

This change removes the top level android directory from dom_distiller
and splits it into content/browser/android and core/android. The two
directories now each have their own JNI registrar that allows them to
depend on appropriate parts of the component.

BUG=562769
==========

[blundell, 2016-08-24 08:34:03]

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

[nyquist, 2016-08-24 21:20:55]

On 2016/08/24 08:33:03, blundell wrote:
> On 2016/08/24 08:24:54, blundell wrote:
> > On 2016/08/24 01:05:22, commit-bot: I haz the power wrote:
> > > Try jobs failed on following builders:
> > >   chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
> > >
> >
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
> > 
> > Please don't land this until the following question is resolved:
> > 
> > Why have //components/dom_distiller/core/android? (Looking at the bug didn't
> > shed insight on the split that you're making here). The core/ subdirectory
of
> a
> > component is by definition for code shared on multiple platforms, so having
> > platform-specific code in there is suspicious.
> > 
> > Remember that it's fine (and expected) for a content/ subdirectory of a
> > component to depend on the corresponding core/ subdirectory; it's just the
> other
> > way around that's conceptually wrong.
> 
> OK, I understand the reason now: dom_distiller_service_android.* depends on
the
> JNI bindings for DomDistillerService.java (I assumed that the reason was
> something like this but was initially confused because there weren't any
include
> path changes in this CL; I then saw that they weren't needed due to include
dir
> magic). I think it would be better to just move
dom_distiller_service_android.*
> to //components/dom_distiller/content/browser/android and keep all the android
> stuff grouped together. That way you (1) avoid splitting the Android-specific
> files between core/ and content/, and (2) allow
dom_distiller_service_android.*
> free access to any //content-specific stuff it might need in the future.

So, from when I read the docs about layered components a while ago, I was under
the impression that the point was to split out dependencies on //content, not
per-platform. Not all of Android necessarily is able to depend on //content
either.

[blundell, 2016-08-25 06:47:07]

On 2016/08/24 21:20:55, nyquist wrote:
> On 2016/08/24 08:33:03, blundell wrote:
> > On 2016/08/24 08:24:54, blundell wrote:
> > > On 2016/08/24 01:05:22, commit-bot: I haz the power wrote:
> > > > Try jobs failed on following builders:
> > > >   chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
> > > >
> > >
> >
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
> > > 
> > > Please don't land this until the following question is resolved:
> > > 
> > > Why have //components/dom_distiller/core/android? (Looking at the bug
didn't
> > > shed insight on the split that you're making here). The core/ subdirectory
> of
> > a
> > > component is by definition for code shared on multiple platforms, so
having
> > > platform-specific code in there is suspicious.
> > > 
> > > Remember that it's fine (and expected) for a content/ subdirectory of a
> > > component to depend on the corresponding core/ subdirectory; it's just the
> > other
> > > way around that's conceptually wrong.
> > 
> > OK, I understand the reason now: dom_distiller_service_android.* depends on
> the
> > JNI bindings for DomDistillerService.java (I assumed that the reason was
> > something like this but was initially confused because there weren't any
> include
> > path changes in this CL; I then saw that they weren't needed due to include
> dir
> > magic). I think it would be better to just move
> dom_distiller_service_android.*
> > to //components/dom_distiller/content/browser/android and keep all the
android
> > stuff grouped together. That way you (1) avoid splitting the
Android-specific
> > files between core/ and content/, and (2) allow
> dom_distiller_service_android.*
> > free access to any //content-specific stuff it might need in the future.
> 
> So, from when I read the docs about layered components a while ago, I was
under
> the impression that the point was to split out dependencies on //content, not
> per-platform. Not all of Android necessarily is able to depend on //content
> either.

You're correct; the relationship to "per-platform" comes from the fact that the
most prominent reason to make a layered component is to share code with iOS, so
when I see code in .../core that is clearly not shared with iOS, it's
surprising. Would there be something preventing dom_distiller_service_android.*
from depending on //content? If not, I don't see a reason for it to live in
.../core and require splitting up the Java files as a result.

[nyquist, 2016-08-26 19:11:35]

On 2016/08/25 06:47:07, blundell wrote:
> On 2016/08/24 21:20:55, nyquist wrote:
> > On 2016/08/24 08:33:03, blundell wrote:
> > > On 2016/08/24 08:24:54, blundell wrote:
> > > > On 2016/08/24 01:05:22, commit-bot: I haz the power wrote:
> > > > > Try jobs failed on following builders:
> > > > >   chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
> > > > >
> > > >
> > >
> >
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
> > > > 
> > > > Please don't land this until the following question is resolved:
> > > > 
> > > > Why have //components/dom_distiller/core/android? (Looking at the bug
> didn't
> > > > shed insight on the split that you're making here). The core/
subdirectory
> > of
> > > a
> > > > component is by definition for code shared on multiple platforms, so
> having
> > > > platform-specific code in there is suspicious.
> > > > 
> > > > Remember that it's fine (and expected) for a content/ subdirectory of a
> > > > component to depend on the corresponding core/ subdirectory; it's just
the
> > > other
> > > > way around that's conceptually wrong.
> > > 
> > > OK, I understand the reason now: dom_distiller_service_android.* depends
on
> > the
> > > JNI bindings for DomDistillerService.java (I assumed that the reason was
> > > something like this but was initially confused because there weren't any
> > include
> > > path changes in this CL; I then saw that they weren't needed due to
include
> > dir
> > > magic). I think it would be better to just move
> > dom_distiller_service_android.*
> > > to //components/dom_distiller/content/browser/android and keep all the
> android
> > > stuff grouped together. That way you (1) avoid splitting the
> Android-specific
> > > files between core/ and content/, and (2) allow
> > dom_distiller_service_android.*
> > > free access to any //content-specific stuff it might need in the future.
> > 
> > So, from when I read the docs about layered components a while ago, I was
> under
> > the impression that the point was to split out dependencies on //content,
not
> > per-platform. Not all of Android necessarily is able to depend on //content
> > either.
> 
> You're correct; the relationship to "per-platform" comes from the fact that
the
> most prominent reason to make a layered component is to share code with iOS,
so
> when I see code in .../core that is clearly not shared with iOS, it's
> surprising. Would there be something preventing
dom_distiller_service_android.*
> from depending on //content? If not, I don't see a reason for it to live in
> .../core and require splitting up the Java files as a result.

dom_distiller_service_android.* is the JNI-bridge for dom_distiller_service.*,
which means it also uses the file DomDistillerService.java.

So, conceptually it's the DomDistillerService on the Android platform exposed to
Java. Since dom_distiller_service.* is something that is most certainly part of
//core, I was thinking that the Android hookup to Java should live at the same
place.

Thoughts?

[blundell, 2016-08-29 07:11:36]

On 2016/08/26 19:11:35, nyquist wrote:
> On 2016/08/25 06:47:07, blundell wrote:
> > On 2016/08/24 21:20:55, nyquist wrote:
> > > On 2016/08/24 08:33:03, blundell wrote:
> > > > On 2016/08/24 08:24:54, blundell wrote:
> > > > > On 2016/08/24 01:05:22, commit-bot: I haz the power wrote:
> > > > > > Try jobs failed on following builders:
> > > > > >   chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
> > > > > >
> > > > >
> > > >
> > >
> >
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
> > > > > 
> > > > > Please don't land this until the following question is resolved:
> > > > > 
> > > > > Why have //components/dom_distiller/core/android? (Looking at the bug
> > didn't
> > > > > shed insight on the split that you're making here). The core/
> subdirectory
> > > of
> > > > a
> > > > > component is by definition for code shared on multiple platforms, so
> > having
> > > > > platform-specific code in there is suspicious.
> > > > > 
> > > > > Remember that it's fine (and expected) for a content/ subdirectory of
a
> > > > > component to depend on the corresponding core/ subdirectory; it's just
> the
> > > > other
> > > > > way around that's conceptually wrong.
> > > > 
> > > > OK, I understand the reason now: dom_distiller_service_android.* depends
> on
> > > the
> > > > JNI bindings for DomDistillerService.java (I assumed that the reason was
> > > > something like this but was initially confused because there weren't any
> > > include
> > > > path changes in this CL; I then saw that they weren't needed due to
> include
> > > dir
> > > > magic). I think it would be better to just move
> > > dom_distiller_service_android.*
> > > > to //components/dom_distiller/content/browser/android and keep all the
> > android
> > > > stuff grouped together. That way you (1) avoid splitting the
> > Android-specific
> > > > files between core/ and content/, and (2) allow
> > > dom_distiller_service_android.*
> > > > free access to any //content-specific stuff it might need in the future.
> > > 
> > > So, from when I read the docs about layered components a while ago, I was
> > under
> > > the impression that the point was to split out dependencies on //content,
> not
> > > per-platform. Not all of Android necessarily is able to depend on
//content
> > > either.
> > 
> > You're correct; the relationship to "per-platform" comes from the fact that
> the
> > most prominent reason to make a layered component is to share code with iOS,
> so
> > when I see code in .../core that is clearly not shared with iOS, it's
> > surprising. Would there be something preventing
> dom_distiller_service_android.*
> > from depending on //content? If not, I don't see a reason for it to live in
> > .../core and require splitting up the Java files as a result.
> 
> dom_distiller_service_android.* is the JNI-bridge for dom_distiller_service.*,
> which means it also uses the file DomDistillerService.java.
> 
> So, conceptually it's the DomDistillerService on the Android platform exposed
to
> Java. Since dom_distiller_service.* is something that is most certainly part
of
> //core, I was thinking that the Android hookup to Java should live at the same
> place.
> 
> Thoughts?

OK, so:

//components/dom_distiller/core/android exposes //components/dom_distiller/core
to Java on Android.
//components/dom_distiller/content/android exposes
//components/dom_distiller/content to Java on Android.

So it would be unexpected to have DomDistillerService.java (and the accompanying
native-side hookup) live in //components/dom_distiller/content/android when
they're conceptually just the Java-side exposure of cross-platform code in
.../core. Similarly, there shouldn't be any reason for that Java-side exposure
to grow a //content dependency when the underlying cross-platform code being
exposed to Java has no such dependency.

That seems reasonable to me. Thanks for explaining this. Consider my objection
removed :).

[nyquist, 2016-08-29 18:05:35]

On 2016/08/29 07:11:36, blundell wrote:
> On 2016/08/26 19:11:35, nyquist wrote:
> > On 2016/08/25 06:47:07, blundell wrote:
> > > On 2016/08/24 21:20:55, nyquist wrote:
> > > > On 2016/08/24 08:33:03, blundell wrote:
> > > > > On 2016/08/24 08:24:54, blundell wrote:
> > > > > > On 2016/08/24 01:05:22, commit-bot: I haz the power wrote:
> > > > > > > Try jobs failed on following builders:
> > > > > > >   chromium_presubmit on master.tryserver.chromium.linux
(JOB_FAILED,
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
> > > > > > 
> > > > > > Please don't land this until the following question is resolved:
> > > > > > 
> > > > > > Why have //components/dom_distiller/core/android? (Looking at the
bug
> > > didn't
> > > > > > shed insight on the split that you're making here). The core/
> > subdirectory
> > > > of
> > > > > a
> > > > > > component is by definition for code shared on multiple platforms, so
> > > having
> > > > > > platform-specific code in there is suspicious.
> > > > > > 
> > > > > > Remember that it's fine (and expected) for a content/ subdirectory
of
> a
> > > > > > component to depend on the corresponding core/ subdirectory; it's
just
> > the
> > > > > other
> > > > > > way around that's conceptually wrong.
> > > > > 
> > > > > OK, I understand the reason now: dom_distiller_service_android.*
depends
> > on
> > > > the
> > > > > JNI bindings for DomDistillerService.java (I assumed that the reason
was
> > > > > something like this but was initially confused because there weren't
any
> > > > include
> > > > > path changes in this CL; I then saw that they weren't needed due to
> > include
> > > > dir
> > > > > magic). I think it would be better to just move
> > > > dom_distiller_service_android.*
> > > > > to //components/dom_distiller/content/browser/android and keep all the
> > > android
> > > > > stuff grouped together. That way you (1) avoid splitting the
> > > Android-specific
> > > > > files between core/ and content/, and (2) allow
> > > > dom_distiller_service_android.*
> > > > > free access to any //content-specific stuff it might need in the
future.
> > > > 
> > > > So, from when I read the docs about layered components a while ago, I
was
> > > under
> > > > the impression that the point was to split out dependencies on
//content,
> > not
> > > > per-platform. Not all of Android necessarily is able to depend on
> //content
> > > > either.
> > > 
> > > You're correct; the relationship to "per-platform" comes from the fact
that
> > the
> > > most prominent reason to make a layered component is to share code with
iOS,
> > so
> > > when I see code in .../core that is clearly not shared with iOS, it's
> > > surprising. Would there be something preventing
> > dom_distiller_service_android.*
> > > from depending on //content? If not, I don't see a reason for it to live
in
> > > .../core and require splitting up the Java files as a result.
> > 
> > dom_distiller_service_android.* is the JNI-bridge for
dom_distiller_service.*,
> > which means it also uses the file DomDistillerService.java.
> > 
> > So, conceptually it's the DomDistillerService on the Android platform
exposed
> to
> > Java. Since dom_distiller_service.* is something that is most certainly part
> of
> > //core, I was thinking that the Android hookup to Java should live at the
same
> > place.
> > 
> > Thoughts?
> 
> OK, so:
> 
> //components/dom_distiller/core/android exposes
//components/dom_distiller/core
> to Java on Android.
> //components/dom_distiller/content/android exposes
> //components/dom_distiller/content to Java on Android.
> 
> So it would be unexpected to have DomDistillerService.java (and the
accompanying
> native-side hookup) live in //components/dom_distiller/content/android when
> they're conceptually just the Java-side exposure of cross-platform code in
> .../core. Similarly, there shouldn't be any reason for that Java-side exposure
> to grow a //content dependency when the underlying cross-platform code being
> exposed to Java has no such dependency.
> 
> That seems reasonable to me. Thanks for explaining this. Consider my objection
> removed :).

Wow, you said that way more clearly than me. But yeah, that's exactly what I
meant.

[mdjones, 2016-08-29 21:22:46]

Description was changed from

==========
Remove dom_distiller core dependency on content

This change removes the top level android directory from dom_distiller
and splits it into content/browser/android and core/android. The two
directories now each have their own JNI registrar that allows them to
depend on appropriate parts of the component.

BUG=562769
==========

to

==========
Remove dom_distiller core dependency on content

This change removes the top level android directory from dom_distiller
and splits it into content/browser/android and core/android. The two
directories now each have their own JNI registrar that allows them to
depend on appropriate parts of the component.

BUG=562769
TBR=yfriedman@chromium.org
==========

[mdjones, 2016-08-29 21:22:56]

The CQ bit was checked by mdjones@chromium.org

[commit-bot: I haz the power, 2016-08-29 21:45:21]

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-30 03:20:57]

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

[commit-bot: I haz the power, 2016-08-30 03:20:58]

Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[mdjones, 2016-08-30 17:36:08]

The CQ bit was checked by mdjones@chromium.org

[mdjones, 2016-08-30 17:36:08]

The patchset sent to the CQ was uploaded after l-g-t-m from nyquist@chromium.org
Link to the patchset: https://codereview.chromium.org/2252963004/#ps40001
(title: "fix deps issue")

[commit-bot: I haz the power, 2016-08-30 17:36:52]

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-30 18:27:56]

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

[commit-bot: I haz the power, 2016-08-30 18:27:57]

Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[mdjones, 2016-08-30 18:32:36]

The CQ bit was checked by mdjones@chromium.org

[mdjones, 2016-08-30 18:32:37]

The patchset sent to the CQ was uploaded after l-g-t-m from nyquist@chromium.org
Link to the patchset: https://codereview.chromium.org/2252963004/#ps60001
(title: "fix test deps")

[commit-bot: I haz the power, 2016-08-30 18:33:04]

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-30 19:50:09]

Description was changed from

==========
Remove dom_distiller core dependency on content

This change removes the top level android directory from dom_distiller
and splits it into content/browser/android and core/android. The two
directories now each have their own JNI registrar that allows them to
depend on appropriate parts of the component.

BUG=562769
TBR=yfriedman@chromium.org
==========

to

==========
Remove dom_distiller core dependency on content

This change removes the top level android directory from dom_distiller
and splits it into content/browser/android and core/android. The two
directories now each have their own JNI registrar that allows them to
depend on appropriate parts of the component.

BUG=562769
TBR=yfriedman@chromium.org
==========

[commit-bot: I haz the power, 2016-08-30 19:50:10]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-08-30 19:51:33]

Description was changed from

==========
Remove dom_distiller core dependency on content

This change removes the top level android directory from dom_distiller
and splits it into content/browser/android and core/android. The two
directories now each have their own JNI registrar that allows them to
depend on appropriate parts of the component.

BUG=562769
TBR=yfriedman@chromium.org
==========

to

==========
Remove dom_distiller core dependency on content

This change removes the top level android directory from dom_distiller
and splits it into content/browser/android and core/android. The two
directories now each have their own JNI registrar that allows them to
depend on appropriate parts of the component.

BUG=562769
TBR=yfriedman@chromium.org

Committed: https://crrev.com/fd194b338274f4a2eba70021f739c3b93e07be99
Cr-Commit-Position: refs/heads/master@{#415400}
==========

[commit-bot: I haz the power, 2016-08-30 19:51:34]

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