Refactor the Java AppBannerManager to be owned by native code.

Refactor the Java AppBannerManager to be owned by native code.

Currently, the native AppBannerManagerAndroid is owned by its Java
counterpart on Android. The Java side is necessary for querying Android
libraries, but the ownership complicates the banner system, which is now
cross-platform.

This CL swaps the ownership semantics, so the native code owns, creates,
and destroys the Android-side code. The AppBannerManagerAndroid is now
a content::WebContentsUserData, and one is created per WebContents. Upon
creation, a Java-side AppBannerManager is instantiated and accessible from
Java using a WebContents object.

The Android code now mirrors the desktop code more closely, consolidating
the C++ layer as the controller for app banners. This CL also prepares for an
upcoming refactor of the banner system, which will separate banner-specific
requirements from general data fetching. The refactor will reduce code
duplication throughout the banner, add to homescreen, and WebAPK systems.

BUG=580392
Committed: https://crrev.com/1912ec8be288682278ba26108f0266468f9f9ea8
Cr-Commit-Position: refs/heads/master@{#405044}

[dominickn, 2016-07-07 08:23:20]

Description was changed from

==========
Refactor the Java AppBannerManager to be owned by native code.

Currently, the native AppBannerManagerAndroid is owned by its Java
counterpart on Android. The Java side is necessary for querying Android
libraries, but the ownership complicates the banner system, which is now
cross-platform.

This CL swaps the ownership semantics, so the native code owns, creates,
and destroys the Android-side code. The AppBannerManagerAndroid is now
a content::WebContentsUserData, and one is created per WebContents. Upon
creation, a Java-side AppBannerManager is instantiated.

This will simplify an upcoming refactor of the banner system, which will
separate banner-specific requirements from general data fetching. The
refactor will reduce code duplication throughout the banner, add to
homescreen, and WebAPK systems.

BUG=580392
==========

to

==========
Refactor the Java AppBannerManager to be owned by native code.

Currently, the native AppBannerManagerAndroid is owned by its Java
counterpart on Android. The Java side is necessary for querying Android
libraries, but the ownership complicates the banner system, which is now
cross-platform.

This CL swaps the ownership semantics, so the native code owns, creates,
and destroys the Android-side code. The AppBannerManagerAndroid is now
a content::WebContentsUserData, and one is created per WebContents. Upon
creation, a Java-side AppBannerManager is instantiated.

This will simplify an upcoming refactor of the banner system, which will
separate banner-specific requirements from general data fetching. The
refactor will reduce code duplication throughout the banner, add to
homescreen, and WebAPK systems.

BUG=580392
==========

[dominickn, 2016-07-07 08:23:21]

dominickn@chromium.org changed reviewers:
+ dfalcantara@chromium.org

[dominickn, 2016-07-07 08:25:36]

Description was changed from

==========
Refactor the Java AppBannerManager to be owned by native code.

Currently, the native AppBannerManagerAndroid is owned by its Java
counterpart on Android. The Java side is necessary for querying Android
libraries, but the ownership complicates the banner system, which is now
cross-platform.

This CL swaps the ownership semantics, so the native code owns, creates,
and destroys the Android-side code. The AppBannerManagerAndroid is now
a content::WebContentsUserData, and one is created per WebContents. Upon
creation, a Java-side AppBannerManager is instantiated.

This will simplify an upcoming refactor of the banner system, which will
separate banner-specific requirements from general data fetching. The
refactor will reduce code duplication throughout the banner, add to
homescreen, and WebAPK systems.

BUG=580392
==========

to

==========
Refactor the Java AppBannerManager to be owned by native code.

Currently, the native AppBannerManagerAndroid is owned by its Java
counterpart on Android. The Java side is necessary for querying Android
libraries, but the ownership complicates the banner system, which is now
cross-platform.

This CL swaps the ownership semantics, so the native code owns, creates,
and destroys the Android-side code. The AppBannerManagerAndroid is now
a content::WebContentsUserData, and one is created per WebContents. Upon
creation, a Java-side AppBannerManager is instantiated.

This changes makes the Android code mirror the desktop code much more
closely, consolidates the native code as the controller for app banners, and
will simplify an upcoming refactor of the banner system. The refactor will
separate banner-specific requirements from general data fetching. The
refactor will reduce code duplication throughout the banner, add to
homescreen, and WebAPK systems.

BUG=580392
==========

[dominickn, 2016-07-07 08:26:09]

Description was changed from

==========
Refactor the Java AppBannerManager to be owned by native code.

Currently, the native AppBannerManagerAndroid is owned by its Java
counterpart on Android. The Java side is necessary for querying Android
libraries, but the ownership complicates the banner system, which is now
cross-platform.

This CL swaps the ownership semantics, so the native code owns, creates,
and destroys the Android-side code. The AppBannerManagerAndroid is now
a content::WebContentsUserData, and one is created per WebContents. Upon
creation, a Java-side AppBannerManager is instantiated.

This changes makes the Android code mirror the desktop code much more
closely, consolidates the native code as the controller for app banners, and
will simplify an upcoming refactor of the banner system. The refactor will
separate banner-specific requirements from general data fetching. The
refactor will reduce code duplication throughout the banner, add to
homescreen, and WebAPK systems.

BUG=580392
==========

to

==========
Refactor the Java AppBannerManager to be owned by native code.

Currently, the native AppBannerManagerAndroid is owned by its Java
counterpart on Android. The Java side is necessary for querying Android
libraries, but the ownership complicates the banner system, which is now
cross-platform.

This CL swaps the ownership semantics, so the native code owns, creates,
and destroys the Android-side code. The AppBannerManagerAndroid is now
a content::WebContentsUserData, and one is created per WebContents. Upon
creation, a Java-side AppBannerManager is instantiated and accessible from
Java using a WebContents object.

This changes makes the Android code mirror the desktop code much more
closely, consolidates the native code as the controller for app banners, and
will simplify an upcoming refactor of the banner system. The refactor will
separate banner-specific requirements from general data fetching. The
refactor will reduce code duplication throughout the banner, add to
homescreen, and WebAPK systems.

BUG=580392
==========

[dominickn, 2016-07-07 08:27:15]

Description was changed from

==========
Refactor the Java AppBannerManager to be owned by native code.

Currently, the native AppBannerManagerAndroid is owned by its Java
counterpart on Android. The Java side is necessary for querying Android
libraries, but the ownership complicates the banner system, which is now
cross-platform.

This CL swaps the ownership semantics, so the native code owns, creates,
and destroys the Android-side code. The AppBannerManagerAndroid is now
a content::WebContentsUserData, and one is created per WebContents. Upon
creation, a Java-side AppBannerManager is instantiated and accessible from
Java using a WebContents object.

This changes makes the Android code mirror the desktop code much more
closely, consolidates the native code as the controller for app banners, and
will simplify an upcoming refactor of the banner system. The refactor will
separate banner-specific requirements from general data fetching. The
refactor will reduce code duplication throughout the banner, add to
homescreen, and WebAPK systems.

BUG=580392
==========

to

==========
Refactor the Java AppBannerManager to be owned by native code.

Currently, the native AppBannerManagerAndroid is owned by its Java
counterpart on Android. The Java side is necessary for querying Android
libraries, but the ownership complicates the banner system, which is now
cross-platform.

This CL swaps the ownership semantics, so the native code owns, creates,
and destroys the Android-side code. The AppBannerManagerAndroid is now
a content::WebContentsUserData, and one is created per WebContents. Upon
creation, a Java-side AppBannerManager is instantiated and accessible from
Java using a WebContents object.

The Android code now mirrors the desktop code more closely, consolidating
the C++ layer as the controller for app banners. This CL also prepares for an
upcoming refactor of the banner system, which will separate banner-specific
requirements from general data fetching. The refactor will reduce code
duplication throughout the banner, add to homescreen, and WebAPK systems.

BUG=580392
==========

[dominickn, 2016-07-07 12:20:02]

PTAL - hopefully I've done this right. I'm open to advice on naming since I
think I was a bit haphazard.

[gone, 2016-07-07 20:41:14]

https://chromiumcodereview.appspot.com/2124243002/diff/1/chrome/android/java/...
File
chrome/android/java/src/org/chromium/chrome/browser/banners/AppBannerManager.java
(right):

https://chromiumcodereview.appspot.com/2124243002/diff/1/chrome/android/java/...
chrome/android/java/src/org/chromium/chrome/browser/banners/AppBannerManager.java:26:
* This Java-side class owns its native-side counterpart, which is basically used
to grab resources
Update this comment.

https://chromiumcodereview.appspot.com/2124243002/diff/1/chrome/android/java/...
chrome/android/java/src/org/chromium/chrome/browser/banners/AppBannerManager.java:68:
public AppBannerManager(long nativePointer) {
Make this private so that no one in Java land makes one

https://chromiumcodereview.appspot.com/2124243002/diff/1/chrome/android/java/...
chrome/android/java/src/org/chromium/chrome/browser/banners/AppBannerManager.java:120:
public static void setIsEnabled(boolean state) {
Changing this to a global toggle is fundamentally broken because of the
different Activities that start up and get swapped out; left a comment below.

https://chromiumcodereview.appspot.com/2124243002/diff/1/chrome/android/java/...
chrome/android/java/src/org/chromium/chrome/browser/banners/AppBannerManager.java:149:
public static AppBannerManager getAppBannerManager(WebContents webContents) {
Make it symmetric:
getAppBannerManagerForWebContents

https://chromiumcodereview.appspot.com/2124243002/diff/1/chrome/android/java/...
File
chrome/android/java/src/org/chromium/chrome/browser/customtabs/CustomTabDelegateFactory.java
(right):

https://chromiumcodereview.appspot.com/2124243002/diff/1/chrome/android/java/...
chrome/android/java/src/org/chromium/chrome/browser/customtabs/CustomTabDelegateFactory.java:198:
public boolean allowAppBanners(Tab tab) {
canShowAppBanners?

https://chromiumcodereview.appspot.com/2124243002/diff/1/chrome/android/java/...
File chrome/android/java/src/org/chromium/chrome/browser/tab/Tab.java (right):

https://chromiumcodereview.appspot.com/2124243002/diff/1/chrome/android/java/...
chrome/android/java/src/org/chromium/chrome/browser/tab/Tab.java:1467:
AppBannerManager.setIsEnabled(mDelegateFactory.allowAppBanners(this));
Eh, why is this here?  The only reason the ugly try/finally block exists is to
handle timestamps.  Also, this breaks banners:
1) Open Chrome as a browser, app banners are globally enabled
2) Open a custom tab via another app, app banners are globally disabled
3) Return to Chrome as a browser, app banners are still globally disabled

[gone, 2016-07-07 20:43:59]

Any reason why you switched away from the per-Delegate check?  The global toggle
was added only for testing, which doesn't have to worry about multiple Activity
types.

The native AppBanner really needs to check both the global testing toggle and
whether the Tab it's being attached to is allowed to support things.  This is
complicated by the fact that Tabs can be reparented from CustomTabActivities to
ChromeTabbedActivities.

[dominickn, 2016-07-08 01:17:53]

On 2016/07/07 20:43:59, dfalcantara wrote:
> Any reason why you switched away from the per-Delegate check?  The global
toggle
> was added only for testing, which doesn't have to worry about multiple
Activity
> types.
> 
> The native AppBanner really needs to check both the global testing toggle and
> whether the Tab it's being attached to is allowed to support things.  This is
> complicated by the fact that Tabs can be reparented from CustomTabActivities
to
> ChromeTabbedActivities.

This was because I wasn't being very smart. Thanks for pointing it out, I've
split this apart into per-tab and global markers. The reparenting method should
also do the per-delegate check and set the per-tab marker accordingly.

https://codereview.chromium.org/2124243002/diff/1/chrome/android/java/src/org...
File
chrome/android/java/src/org/chromium/chrome/browser/banners/AppBannerManager.java
(right):

https://codereview.chromium.org/2124243002/diff/1/chrome/android/java/src/org...
chrome/android/java/src/org/chromium/chrome/browser/banners/AppBannerManager.java:26:
* This Java-side class owns its native-side counterpart, which is basically used
to grab resources
On 2016/07/07 20:41:14, dfalcantara wrote:
> Update this comment.

Done.

https://codereview.chromium.org/2124243002/diff/1/chrome/android/java/src/org...
chrome/android/java/src/org/chromium/chrome/browser/banners/AppBannerManager.java:68:
public AppBannerManager(long nativePointer) {
On 2016/07/07 20:41:14, dfalcantara wrote:
> Make this private so that no one in Java land makes one

Done.

https://codereview.chromium.org/2124243002/diff/1/chrome/android/java/src/org...
chrome/android/java/src/org/chromium/chrome/browser/banners/AppBannerManager.java:120:
public static void setIsEnabled(boolean state) {
On 2016/07/07 20:41:14, dfalcantara wrote:
> Changing this to a global toggle is fundamentally broken because of the
> different Activities that start up and get swapped out; left a comment below.

Acknowledged. I've split the enabled boolean into two to fix this.

https://codereview.chromium.org/2124243002/diff/1/chrome/android/java/src/org...
chrome/android/java/src/org/chromium/chrome/browser/banners/AppBannerManager.java:149:
public static AppBannerManager getAppBannerManager(WebContents webContents) {
On 2016/07/07 20:41:14, dfalcantara wrote:
> Make it symmetric:
> getAppBannerManagerForWebContents

Done.

https://codereview.chromium.org/2124243002/diff/1/chrome/android/java/src/org...
File
chrome/android/java/src/org/chromium/chrome/browser/customtabs/CustomTabDelegateFactory.java
(right):

https://codereview.chromium.org/2124243002/diff/1/chrome/android/java/src/org...
chrome/android/java/src/org/chromium/chrome/browser/customtabs/CustomTabDelegateFactory.java:198:
public boolean allowAppBanners(Tab tab) {
On 2016/07/07 20:41:14, dfalcantara wrote:
> canShowAppBanners?

Done.

https://codereview.chromium.org/2124243002/diff/1/chrome/android/java/src/org...
File chrome/android/java/src/org/chromium/chrome/browser/tab/Tab.java (right):

https://codereview.chromium.org/2124243002/diff/1/chrome/android/java/src/org...
chrome/android/java/src/org/chromium/chrome/browser/tab/Tab.java:1467:
AppBannerManager.setIsEnabled(mDelegateFactory.allowAppBanners(this));
On 2016/07/07 20:41:14, dfalcantara wrote:
> Eh, why is this here?  The only reason the ugly try/finally block exists is to
> handle timestamps.  Also, this breaks banners:
> 1) Open Chrome as a browser, app banners are globally enabled
> 2) Open a custom tab via another app, app banners are globally disabled
> 3) Return to Chrome as a browser, app banners are still globally disabled

Thanks for clarifying. I've split up the enabled check into the static (is
homescreen intent enabled) and per-Manager (per tab)

[gone, 2016-07-11 17:59:36]

lgtm % comments about naming

https://chromiumcodereview.appspot.com/2124243002/diff/20001/chrome/android/j...
File
chrome/android/java/src/org/chromium/chrome/browser/banners/AppBannerManager.java
(right):

https://chromiumcodereview.appspot.com/2124243002/diff/20001/chrome/android/j...
chrome/android/java/src/org/chromium/chrome/browser/banners/AppBannerManager.java:31:
/** Whether add to homescreen is permitted by the system. */
home screen

https://chromiumcodereview.appspot.com/2124243002/diff/20001/chrome/android/j...
chrome/android/java/src/org/chromium/chrome/browser/banners/AppBannerManager.java:35:
private boolean mIsEnabled;
Maybe:

sIsSupported
mIsEnabledForTab

Using isEnabled twice is weird

https://chromiumcodereview.appspot.com/2124243002/diff/20001/chrome/android/j...
chrome/android/java/src/org/chromium/chrome/browser/banners/AppBannerManager.java:127:
public void setIsEnabled(boolean state) {
setIsEnabledForTab

[dominickn, 2016-07-11 23:50:02]

dominickn@chromium.org changed reviewers:
+ avi@chromium.org

[dominickn, 2016-07-11 23:50:03]

Thanks!

+avi: please review tab_helpers.cc.

https://codereview.chromium.org/2124243002/diff/20001/chrome/android/java/src...
File
chrome/android/java/src/org/chromium/chrome/browser/banners/AppBannerManager.java
(right):

https://codereview.chromium.org/2124243002/diff/20001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/banners/AppBannerManager.java:31:
/** Whether add to homescreen is permitted by the system. */
On 2016/07/11 17:59:36, dfalcantara wrote:
> home screen

Done, everywhere in the file.

https://codereview.chromium.org/2124243002/diff/20001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/banners/AppBannerManager.java:35:
private boolean mIsEnabled;
On 2016/07/11 17:59:36, dfalcantara wrote:
> Maybe:
> 
> sIsSupported
> mIsEnabledForTab
> 
> Using isEnabled twice is weird

Done.

https://codereview.chromium.org/2124243002/diff/20001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/banners/AppBannerManager.java:127:
public void setIsEnabled(boolean state) {
On 2016/07/11 17:59:36, dfalcantara wrote:
> setIsEnabledForTab

Done.

[Avi (use Gerrit), 2016-07-12 00:43:26]

tab helpers lgtm

[dominickn, 2016-07-12 00:48:22]

The CQ bit was checked by dominickn@chromium.org

[dominickn, 2016-07-12 00:48:23]

The patchset sent to the CQ was uploaded after l-g-t-m from
dfalcantara@chromium.org
Link to the patchset: https://codereview.chromium.org/2124243002/#ps40001
(title: "Addressing reviewer comments")

[commit-bot: I haz the power, 2016-07-12 00:49:54]

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-07-12 01:36:46]

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

[commit-bot: I haz the power, 2016-07-12 01:36:47]

Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[dominickn, 2016-07-12 02:59:09]

The CQ bit was checked by dominickn@chromium.org

[commit-bot: I haz the power, 2016-07-12 03:00:08]

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-07-12 04:09:37]

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

[commit-bot: I haz the power, 2016-07-12 04:09:38]

Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[dominickn, 2016-07-12 04:16:46]

The CQ bit was checked by dominickn@chromium.org

[commit-bot: I haz the power, 2016-07-12 04:17:37]

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-07-12 04:24:58]

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

[commit-bot: I haz the power, 2016-07-12 04:25:00]

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_...)

[dominickn, 2016-07-12 10:50:39]

The CQ bit was checked by dominickn@chromium.org

[commit-bot: I haz the power, 2016-07-12 10:51:10]

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-07-12 12:14:01]

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

[commit-bot: I haz the power, 2016-07-12 12:14:03]

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_...)

[dominickn, 2016-07-13 02:04:55]

The CQ bit was checked by dominickn@chromium.org

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

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

[pkotwicz, 2016-07-13 02:31:16]

The CQ bit was unchecked by pkotwicz@chromium.org

[pkotwicz, 2016-07-13 02:31:50]

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

[pkotwicz, 2016-07-13 02:31:50]

https://codereview.chromium.org/2124243002/diff/40001/chrome/browser/banners/...
File chrome/browser/banners/app_banner_manager.h (right):

https://codereview.chromium.org/2124243002/diff/40001/chrome/browser/banners/...
chrome/browser/banners/app_banner_manager.h:50: void
ReplaceWebContents(content::WebContents* web_contents);
Drive By! This function seems unused now

[dominickn, 2016-07-13 02:48:10]

On 2016/07/13 02:31:50, pkotwicz wrote:
>
https://codereview.chromium.org/2124243002/diff/40001/chrome/browser/banners/...
> File chrome/browser/banners/app_banner_manager.h (right):
> 
>
https://codereview.chromium.org/2124243002/diff/40001/chrome/browser/banners/...
> chrome/browser/banners/app_banner_manager.h:50: void
> ReplaceWebContents(content::WebContents* web_contents);
> Drive By! This function seems unused now

Thanks for pointing this out; however, I don't think an unused function is cause
to uncheck the commit bit.

[dominickn, 2016-07-13 02:57:16]

The CQ bit was checked by dominickn@chromium.org

[commit-bot: I haz the power, 2016-07-13 02:58:12]

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-07-13 05:23:46]

Description was changed from

==========
Refactor the Java AppBannerManager to be owned by native code.

Currently, the native AppBannerManagerAndroid is owned by its Java
counterpart on Android. The Java side is necessary for querying Android
libraries, but the ownership complicates the banner system, which is now
cross-platform.

This CL swaps the ownership semantics, so the native code owns, creates,
and destroys the Android-side code. The AppBannerManagerAndroid is now
a content::WebContentsUserData, and one is created per WebContents. Upon
creation, a Java-side AppBannerManager is instantiated and accessible from
Java using a WebContents object.

The Android code now mirrors the desktop code more closely, consolidating
the C++ layer as the controller for app banners. This CL also prepares for an
upcoming refactor of the banner system, which will separate banner-specific
requirements from general data fetching. The refactor will reduce code
duplication throughout the banner, add to homescreen, and WebAPK systems.

BUG=580392
==========

to

==========
Refactor the Java AppBannerManager to be owned by native code.

Currently, the native AppBannerManagerAndroid is owned by its Java
counterpart on Android. The Java side is necessary for querying Android
libraries, but the ownership complicates the banner system, which is now
cross-platform.

This CL swaps the ownership semantics, so the native code owns, creates,
and destroys the Android-side code. The AppBannerManagerAndroid is now
a content::WebContentsUserData, and one is created per WebContents. Upon
creation, a Java-side AppBannerManager is instantiated and accessible from
Java using a WebContents object.

The Android code now mirrors the desktop code more closely, consolidating
the C++ layer as the controller for app banners. This CL also prepares for an
upcoming refactor of the banner system, which will separate banner-specific
requirements from general data fetching. The refactor will reduce code
duplication throughout the banner, add to homescreen, and WebAPK systems.

BUG=580392
==========

[commit-bot: I haz the power, 2016-07-13 05:23:47]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-07-13 05:25:05]

Description was changed from

==========
Refactor the Java AppBannerManager to be owned by native code.

Currently, the native AppBannerManagerAndroid is owned by its Java
counterpart on Android. The Java side is necessary for querying Android
libraries, but the ownership complicates the banner system, which is now
cross-platform.

This CL swaps the ownership semantics, so the native code owns, creates,
and destroys the Android-side code. The AppBannerManagerAndroid is now
a content::WebContentsUserData, and one is created per WebContents. Upon
creation, a Java-side AppBannerManager is instantiated and accessible from
Java using a WebContents object.

The Android code now mirrors the desktop code more closely, consolidating
the C++ layer as the controller for app banners. This CL also prepares for an
upcoming refactor of the banner system, which will separate banner-specific
requirements from general data fetching. The refactor will reduce code
duplication throughout the banner, add to homescreen, and WebAPK systems.

BUG=580392
==========

to

==========
Refactor the Java AppBannerManager to be owned by native code.

Currently, the native AppBannerManagerAndroid is owned by its Java
counterpart on Android. The Java side is necessary for querying Android
libraries, but the ownership complicates the banner system, which is now
cross-platform.

This CL swaps the ownership semantics, so the native code owns, creates,
and destroys the Android-side code. The AppBannerManagerAndroid is now
a content::WebContentsUserData, and one is created per WebContents. Upon
creation, a Java-side AppBannerManager is instantiated and accessible from
Java using a WebContents object.

The Android code now mirrors the desktop code more closely, consolidating
the C++ layer as the controller for app banners. This CL also prepares for an
upcoming refactor of the banner system, which will separate banner-specific
requirements from general data fetching. The refactor will reduce code
duplication throughout the banner, add to homescreen, and WebAPK systems.

BUG=580392

Committed: https://crrev.com/1912ec8be288682278ba26108f0266468f9f9ea8
Cr-Commit-Position: refs/heads/master@{#405044}
==========

[commit-bot: I haz the power, 2016-07-13 05:25:06]

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