[Custom Tabs]Add API for updating action button as ContentProvider

[Custom Tabs]Add API for updating action button as ContentProvider

This CL adds a ContentProvider, CustomTabUpdater, to android chrome, with a
custom call method that updates the active custom tab with new action button
icon.

Note a valid service connection is still required to be able to let chrome
verify that the caller owns the active custom tab.

BUG=510256

[Ian Wen, 2015-08-31 22:35:32]

ianwen@chromium.org changed reviewers:
+ klobag@chromium.org, lizeb@chromium.org, tedchoc@chromium.org,
yusufo@google.com

[Ian Wen, 2015-08-31 22:35:33]

This CL shows how the same API could be implemented using ContentProvider.

My major concern is that I could not think of a way to verify the caller's
ownership of the active custom tab, without the help of the service.

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

https://codereview.chromium.org/1305253006/diff/1/chrome/android/java/src/org...
chrome/android/java/src/org/chromium/chrome/browser/customtabs/CustomTabUpdater.java:46:
CustomTabsIntent.EXTRA_SESSION);
Here an alternative approach is to call Binder.getCallingUid(), and in
CustomTabContentHandler, we store the uid along side with the IBinder to match
it.

Yet what worries me is that one of Grace's original thoughts was not implemented
in this CL: the client still must have a service connection anyway, because
either the uid or the IBinder are recorded by the time the service creates the
activity. If the custom tab was initiated by a pure View intent, then there is
no way we could grab any information about the client app.

[Benoit L, 2015-09-01 16:45:10]

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

https://codereview.chromium.org/1305253006/diff/1/chrome/android/java/src/org...
chrome/android/java/src/org/chromium/chrome/browser/customtabs/CustomTabUpdater.java:46:
CustomTabsIntent.EXTRA_SESSION);
On 2015/08/31 22:35:33, Ian Wen wrote:
> Here an alternative approach is to call Binder.getCallingUid(), and in
> CustomTabContentHandler, we store the uid along side with the IBinder to match
> it.
> 

Novice question: are we sure that Binder.getCallingUid() returns something
meaningful here? AFAIK, it only returns something else than your own UID inside
a Binder transaction. Is is the case here?

> Yet what worries me is that one of Grace's original thoughts was not
implemented
> in this CL: the client still must have a service connection anyway, because
> either the uid or the IBinder are recorded by the time the service creates the
> activity. If the custom tab was initiated by a pure View intent, then there is
> no way we could grab any information about the client app.