Add a LocationUtils class to give all Chromium Android code access to location helpers.

Add a components.location.LocationUtils class to give all Chromium Android code access to location helpers.

This class currently helps code check if Chrome has permission to access
location and if location is turned on for the device.

Committed: https://crrev.com/a082f486985a4631ce3db3329874b9834e369e4d
Committed: https://crrev.com/847bd1803edc5cebaf4047fb7c75f55b2c5727ab
Cr-Original-Commit-Position: refs/heads/master@{#402319}
Cr-Commit-Position: refs/heads/master@{#402833}

[Jeffrey Yasskin, 2016-06-04 00:47:40]

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

[commit-bot: I haz the power, 2016-06-04 00:48:40]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2038753004/1

[Jeffrey Yasskin, 2016-06-04 01:31:36]

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

[commit-bot: I haz the power, 2016-06-04 01:32:02]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2038753004/20001

[commit-bot: I haz the power, 2016-06-04 03:16:55]

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

[commit-bot: I haz the power, 2016-06-04 03:16:56]

Dry run: This issue passed the CQ dry run.

[Jeffrey Yasskin, 2016-06-06 15:53:48]

jyasskin@chromium.org changed reviewers:
+ finnur@chromium.org, torne@chromium.org

[Jeffrey Yasskin, 2016-06-06 15:53:48]

I'm using these functions in https://codereview.chromium.org/2032273002/, and to
avoid duplicating the right techniques for dealing with location permissions,
I'd like to pull much of the content of LocationSettings up to base/android.
Does that work for folks? Is there anything else I should include in this class?

https://codereview.chromium.org/2038753004/diff/20001/base/android/java/src/o...
File base/android/java/src/org/chromium/base/LocationUtils.java (right):

https://codereview.chromium.org/2038753004/diff/20001/base/android/java/src/o...
base/android/java/src/org/chromium/base/LocationUtils.java:62: return
(locationManager.isProviderEnabled(LocationManager.NETWORK_PROVIDER)
https://developer.android.com/reference/android/location/LocationManager.html...
says to use Settings.Secure.getInt(LOCATION_MODE) instead, but I've left this
the same as the more commonly used technique in Chrome. Should I change it?

[Torne, 2016-06-07 11:30:43]

Does this really need to go into base? The discussion on the other CL suggests
it'll be less convenient, and it doesn't really seem like this is a good place
for it.

https://codereview.chromium.org/2038753004/diff/20001/base/android/java/src/o...
File base/android/java/src/org/chromium/base/LocationUtils.java (right):

https://codereview.chromium.org/2038753004/diff/20001/base/android/java/src/o...
base/android/java/src/org/chromium/base/LocationUtils.java:62: return
(locationManager.isProviderEnabled(LocationManager.NETWORK_PROVIDER)
On 2016/06/06 15:53:48, Jeffrey Yasskin wrote:
>
https://developer.android.com/reference/android/location/LocationManager.html...
> says to use Settings.Secure.getInt(LOCATION_MODE) instead, but I've left this
> the same as the more commonly used technique in Chrome. Should I change it?

Should probably do what the documentation says.

[Jeffrey Yasskin, 2016-06-07 15:56:11]

https://codereview.chromium.org/2038753004/diff/20001/chrome/android/java/src...
File
chrome/android/java/src/org/chromium/chrome/browser/preferences/LocationSettings.java
(right):

https://codereview.chromium.org/2038753004/diff/20001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/preferences/LocationSettings.java:27:
public class LocationSettings {
Ted, I'm having trouble finding the internal version of this class to see if
you're overriding any of the methods I'm moving out. Can you point me to it?

https://codereview.chromium.org/2038753004/diff/20001/device/bluetooth/androi...
File
device/bluetooth/android/java/src/org/chromium/device/bluetooth/Wrappers.java
(right):

https://codereview.chromium.org/2038753004/diff/20001/device/bluetooth/androi...
device/bluetooth/android/java/src/org/chromium/device/bluetooth/Wrappers.java:166:
return LocationUtils.getInstance().chromiumHasLocationPermission(mContext);
This is the use that pushes LocationUtils toward base/, and I'm extending this
in
https://codereview.chromium.org/2032273002/diff/40001/device/bluetooth/androi...
to use the other method.

Is there somewhere else I can put it that'll still be usable from device/?
Should I just duplicate the code in device/?

[Torne, 2016-06-09 13:19:39]

On 2016/06/07 15:56:11, Jeffrey Yasskin wrote:
>
https://codereview.chromium.org/2038753004/diff/20001/chrome/android/java/src...
> File
>
chrome/android/java/src/org/chromium/chrome/browser/preferences/LocationSettings.java
> (right):
> 
>
https://codereview.chromium.org/2038753004/diff/20001/chrome/android/java/src...
>
chrome/android/java/src/org/chromium/chrome/browser/preferences/LocationSettings.java:27:
> public class LocationSettings {
> Ted, I'm having trouble finding the internal version of this class to see if
> you're overriding any of the methods I'm moving out. Can you point me to it?
> 
>
https://codereview.chromium.org/2038753004/diff/20001/device/bluetooth/androi...
> File
> device/bluetooth/android/java/src/org/chromium/device/bluetooth/Wrappers.java
> (right):
> 
>
https://codereview.chromium.org/2038753004/diff/20001/device/bluetooth/androi...
>
device/bluetooth/android/java/src/org/chromium/device/bluetooth/Wrappers.java:166:
> return LocationUtils.getInstance().chromiumHasLocationPermission(mContext);
> This is the use that pushes LocationUtils toward base/, and I'm extending this
> in
>
https://codereview.chromium.org/2032273002/diff/40001/device/bluetooth/androi...
> to use the other method.

Is device/ used by other embedders (like webview)? Is this logic necessarily
going to be righ tin all cases? Should it maybe be just deferring it to a higher
level? Not suggesting that's right; I haven't really looked in detail and am not
familiar with the expecations around device/

> 
> Is there somewhere else I can put it that'll still be usable from device/?
> Should I just duplicate the code in device/?

Maybe in a component? (is there one that might be appropriate? something
location related?) I'm not sure what the layering expectations for device/ are.
The bar to put things in base is supposed to be pretty high.

[Jeffrey Yasskin, 2016-06-09 15:36:00]

On 2016/06/09 13:19:39, Torne wrote:
> On 2016/06/07 15:56:11, Jeffrey Yasskin wrote:
> >
>
https://codereview.chromium.org/2038753004/diff/20001/chrome/android/java/src...
> > File
> >
>
chrome/android/java/src/org/chromium/chrome/browser/preferences/LocationSettings.java
> > (right):
> > 
> >
>
https://codereview.chromium.org/2038753004/diff/20001/chrome/android/java/src...
> >
>
chrome/android/java/src/org/chromium/chrome/browser/preferences/LocationSettings.java:27:
> > public class LocationSettings {
> > Ted, I'm having trouble finding the internal version of this class to see if
> > you're overriding any of the methods I'm moving out. Can you point me to it?
> > 
> >
>
https://codereview.chromium.org/2038753004/diff/20001/device/bluetooth/androi...
> > File
> >
device/bluetooth/android/java/src/org/chromium/device/bluetooth/Wrappers.java
> > (right):
> > 
> >
>
https://codereview.chromium.org/2038753004/diff/20001/device/bluetooth/androi...
> >
>
device/bluetooth/android/java/src/org/chromium/device/bluetooth/Wrappers.java:166:
> > return LocationUtils.getInstance().chromiumHasLocationPermission(mContext);
> > This is the use that pushes LocationUtils toward base/, and I'm extending
this
> > in
> >
>
https://codereview.chromium.org/2032273002/diff/40001/device/bluetooth/androi...
> > to use the other method.
> 
> Is device/ used by other embedders (like webview)? Is this logic necessarily
> going to be righ tin all cases? Should it maybe be just deferring it to a
higher
> level? Not suggesting that's right; I haven't really looked in detail and am
not
> familiar with the expecations around device/

The logic about how scanning depends on location is fundamental to Android M, so
it won't change in webviews or other embedders. Other embedders may choose to
avoid calling device/bluetooth to scan in the first place, and provide their own
list of devices, in which case this code won't be called. (We haven't
implemented the webview embedding for Web Bluetooth yet, so take that with a
grain of salt, but I don't expect it to change.)

> > Is there somewhere else I can put it that'll still be usable from device/?
> > Should I just duplicate the code in device/?
> 
> Maybe in a component? (is there one that might be appropriate? something
> location related?) I'm not sure what the layering expectations for device/
are.
> The bar to put things in base is supposed to be pretty high.

I don't see an existing component that's location-related, but I could create
components/location/android. I don't think there's any problem with device/
depending on components/. I'll start on this move unless one of you speaks up.

[Torne, 2016-06-09 15:39:00]

On 2016/06/09 15:36:00, Jeffrey Yasskin wrote:
> On 2016/06/09 13:19:39, Torne wrote:
> > On 2016/06/07 15:56:11, Jeffrey Yasskin wrote:
> > >
> >
>
https://codereview.chromium.org/2038753004/diff/20001/chrome/android/java/src...
> > > File
> > >
> >
>
chrome/android/java/src/org/chromium/chrome/browser/preferences/LocationSettings.java
> > > (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/2038753004/diff/20001/chrome/android/java/src...
> > >
> >
>
chrome/android/java/src/org/chromium/chrome/browser/preferences/LocationSettings.java:27:
> > > public class LocationSettings {
> > > Ted, I'm having trouble finding the internal version of this class to see
if
> > > you're overriding any of the methods I'm moving out. Can you point me to
it?
> > > 
> > >
> >
>
https://codereview.chromium.org/2038753004/diff/20001/device/bluetooth/androi...
> > > File
> > >
> device/bluetooth/android/java/src/org/chromium/device/bluetooth/Wrappers.java
> > > (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/2038753004/diff/20001/device/bluetooth/androi...
> > >
> >
>
device/bluetooth/android/java/src/org/chromium/device/bluetooth/Wrappers.java:166:
> > > return
LocationUtils.getInstance().chromiumHasLocationPermission(mContext);
> > > This is the use that pushes LocationUtils toward base/, and I'm extending
> this
> > > in
> > >
> >
>
https://codereview.chromium.org/2032273002/diff/40001/device/bluetooth/androi...
> > > to use the other method.
> > 
> > Is device/ used by other embedders (like webview)? Is this logic necessarily
> > going to be righ tin all cases? Should it maybe be just deferring it to a
> higher
> > level? Not suggesting that's right; I haven't really looked in detail and am
> not
> > familiar with the expecations around device/
> 
> The logic about how scanning depends on location is fundamental to Android M,
so
> it won't change in webviews or other embedders. Other embedders may choose to
> avoid calling device/bluetooth to scan in the first place, and provide their
own
> list of devices, in which case this code won't be called. (We haven't
> implemented the webview embedding for Web Bluetooth yet, so take that with a
> grain of salt, but I don't expect it to change.)
> 
> > > Is there somewhere else I can put it that'll still be usable from device/?
> > > Should I just duplicate the code in device/?
> > 
> > Maybe in a component? (is there one that might be appropriate? something
> > location related?) I'm not sure what the layering expectations for device/
> are.
> > The bar to put things in base is supposed to be pretty high.
> 
> I don't see an existing component that's location-related, but I could create
> components/location/android. I don't think there's any problem with device/
> depending on components/. I'll start on this move unless one of you speaks up.

If it's not too much trouble to make it into a component that'd probably be
preferable. base is supposed to be for things that are very widely used at all
layers.

[Jeffrey Yasskin, 2016-06-09 22:03:10]

Description was changed from

==========
Add a base.LocationUtils class to give all Chromium Android code access to
location helpers.

This class currently helps code check if Chrome has permission to access
location and if location is turned on for the device.
==========

to

==========
Add a base.LocationUtils class to give all Chromium Android code access to
location helpers.

This class currently helps code check if Chrome has permission to access
location and if location is turned on for the device.
==========

[Jeffrey Yasskin, 2016-06-09 22:03:10]

jyasskin@chromium.org changed reviewers:
+ blundell@chromium.org, tedchoc@chromium.org
- torne@chromium.org

[Jeffrey Yasskin, 2016-06-09 22:07:15]

Description was changed from

==========
Add a base.LocationUtils class to give all Chromium Android code access to
location helpers.

This class currently helps code check if Chrome has permission to access
location and if location is turned on for the device.
==========

to

==========
Add a components.location.LocationUtils class to give all Chromium Android code
access to location helpers.

This class currently helps code check if Chrome has permission to access
location and if location is turned on for the device.
==========

[Jeffrey Yasskin, 2016-06-09 22:08:11]

Thanks Torne for suggesting a better place. +blundell@ as a components/ owner,
and Ted to cover chrome/android/*.

https://codereview.chromium.org/2038753004/diff/20001/base/android/java/src/o...
File base/android/java/src/org/chromium/base/LocationUtils.java (right):

https://codereview.chromium.org/2038753004/diff/20001/base/android/java/src/o...
base/android/java/src/org/chromium/base/LocationUtils.java:62: return
(locationManager.isProviderEnabled(LocationManager.NETWORK_PROVIDER)
On 2016/06/07 11:30:43, Torne wrote:
> On 2016/06/06 15:53:48, Jeffrey Yasskin wrote:
> >
>
https://developer.android.com/reference/android/location/LocationManager.html...
> > says to use Settings.Secure.getInt(LOCATION_MODE) instead, but I've left
this
> > the same as the more commonly used technique in Chrome. Should I change it?
> 
> Should probably do what the documentation says.

Done.

https://codereview.chromium.org/2038753004/diff/60001/components/location/OWNERS
File components/location/OWNERS (right):

https://codereview.chromium.org/2038753004/diff/60001/components/location/OWN...
components/location/OWNERS:1: jyasskin@chromium.org
Do you folks know anyone who'd be better to own this component? I don't know
anything special about location, but I can stay in here if there's nobody
better.

[Jeffrey Yasskin, 2016-06-09 22:08:19]

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

[commit-bot: I haz the power, 2016-06-09 22:09:05]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2038753004/60001

[commit-bot: I haz the power, 2016-06-10 00:11:35]

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

[commit-bot: I haz the power, 2016-06-10 00:11:36]

Dry run: Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_TIMED_OUT, no build
URL)
  mac_chromium_gn_rel on tryserver.chromium.mac (JOB_TIMED_OUT, no build URL)
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_TIMED_OUT, no build URL)

[Jeffrey Yasskin, 2016-06-10 00:19:13]

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

[commit-bot: I haz the power, 2016-06-10 00:20:13]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2038753004/80001

[commit-bot: I haz the power, 2016-06-10 02:21:43]

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

[commit-bot: I haz the power, 2016-06-10 02:21:44]

Dry run: Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_TIMED_OUT, no build
URL)
  mac_chromium_gn_rel on tryserver.chromium.mac (JOB_TIMED_OUT, no build URL)
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_TIMED_OUT, no build URL)

[blundell, 2016-06-10 08:38:58]

lgtm

[Ted C, 2016-06-13 19:56:21]

lgtm w/ some naming suggestions

https://codereview.chromium.org/2038753004/diff/120001/components/location/an...
File
components/location/android/java/src/org/chromium/components/location/LocationUtils.java
(right):

https://codereview.chromium.org/2038753004/diff/120001/components/location/an...
components/location/android/java/src/org/chromium/components/location/LocationUtils.java:57:
* Check both chromeHasLocationPermission() and isSystemLocationSettingEnabled()
to determine if
looks like this comment predates the rename to chromium

https://codereview.chromium.org/2038753004/diff/120001/components/location/an...
components/location/android/java/src/org/chromium/components/location/LocationUtils.java:60:
public boolean chromiumHasLocationPermission(Context context) {
personally, I would call this hasLocationAndroidPermission or
hasAndroidLocationPermission.  The chromium leading bit doesn't really help
differentiate anything in my opinion.

https://codereview.chromium.org/2038753004/diff/120001/components/location/an...
components/location/android/java/src/org/chromium/components/location/LocationUtils.java:89:
/** Instantiate this to explain how to create a LocationUtils instance in
move this down a line to avoid the off by one indenting weirdness

[Finnur, 2016-06-16 13:44:44]

You probably don't need my approval, given Ted's green light, but I reviewed
selective files (that relate to my code) and I don't have a problem with this.

LGTM.

https://codereview.chromium.org/2038753004/diff/120001/components/location/an...
File
components/location/android/java/src/org/chromium/components/location/LocationUtils.java
(right):

https://codereview.chromium.org/2038753004/diff/120001/components/location/an...
components/location/android/java/src/org/chromium/components/location/LocationUtils.java:60:
public boolean chromiumHasLocationPermission(Context context) {
FWIW: I'm also uncomfortable with the chromium prefix.

[Jeffrey Yasskin, 2016-06-16 16:02:32]

jyasskin@chromium.org changed reviewers:
+ scheib@chromium.org

[Jeffrey Yasskin, 2016-06-16 16:02:33]

Vince, PTAL at device/bluetooth.

https://codereview.chromium.org/2038753004/diff/120001/components/location/an...
File
components/location/android/java/src/org/chromium/components/location/LocationUtils.java
(right):

https://codereview.chromium.org/2038753004/diff/120001/components/location/an...
components/location/android/java/src/org/chromium/components/location/LocationUtils.java:57:
* Check both chromeHasLocationPermission() and isSystemLocationSettingEnabled()
to determine if
On 2016/06/13 19:56:21, Ted C wrote:
> looks like this comment predates the rename to chromium

Done.

https://codereview.chromium.org/2038753004/diff/120001/components/location/an...
components/location/android/java/src/org/chromium/components/location/LocationUtils.java:60:
public boolean chromiumHasLocationPermission(Context context) {
On 2016/06/13 19:56:21, Ted C wrote:
> personally, I would call this hasLocationAndroidPermission or
> hasAndroidLocationPermission.  The chromium leading bit doesn't really help
> differentiate anything in my opinion.

I was trying to distinguish this from some website having permission, but
omitting it works for me.

https://codereview.chromium.org/2038753004/diff/120001/components/location/an...
components/location/android/java/src/org/chromium/components/location/LocationUtils.java:89:
/** Instantiate this to explain how to create a LocationUtils instance in
On 2016/06/13 19:56:21, Ted C wrote:
> move this down a line to avoid the off by one indenting weirdness

Done.

[Jeffrey Yasskin, 2016-06-16 16:02:43]

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

[commit-bot: I haz the power, 2016-06-16 16:03:11]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2038753004/140001

[commit-bot: I haz the power, 2016-06-16 18:32:36]

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

[commit-bot: I haz the power, 2016-06-16 18:32:37]

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

[Jeffrey Yasskin, 2016-06-17 06:13:46]

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

[commit-bot: I haz the power, 2016-06-17 06:13:57]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2038753004/160001

[Jeffrey Yasskin, 2016-06-17 06:15:29]

FYI, I had to update several DEPS files to depend on /components/location.

[commit-bot: I haz the power, 2016-06-17 07:38:54]

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

[commit-bot: I haz the power, 2016-06-17 07:38:55]

Dry run: This issue passed the CQ dry run.

[scheib, 2016-06-22 19:36:50]

https://codereview.chromium.org/2038753004/diff/160001/device/bluetooth/andro...
File
device/bluetooth/android/java/src/org/chromium/device/bluetooth/Wrappers.java
(right):

https://codereview.chromium.org/2038753004/diff/160001/device/bluetooth/andro...
device/bluetooth/android/java/src/org/chromium/device/bluetooth/Wrappers.java:165:
public boolean hasAndroidLocationPermission() {
The wrappers were designed to be the thinnest practical wrapper around the
Android classes. There are one or two examples of deviation (e.g.
getBluetoothClass_getDeviceClass), but they represent an API call and then
another call on the returned object.

This change adds a new concept to the wrapper that the android class doesn't
have, which I don't like. I see two main options:

1) Access LocationUtils.getInstance() and have test code able to set expected
behavior for it in test executables.

2) Sticking with this wrapper design, reworking as such:

To get virtual abstraction the wrappers need to be via a passed instance of an
object that is constructed elsewhere from code that knows if the executable is
production or test. Right now it is the adapter wrapper that is passed in to
ChromeBluetoothAdapter.java's constructor.

LocationUtils is a concept outside of the Adapter hierarchy, so we need a
wrapper for it passed in somehow.

A solution is to pass to ChromeBluetoothAdapter a new thing we create
'device.Wrappers' instance. That instance would have members for an
BluetoothAdapterWrapper and LocationUtilsWrapper.

[ortuno, 2016-06-27 20:57:42]

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

[commit-bot: I haz the power, 2016-06-27 20:58:29]

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

[ortuno, 2016-06-27 21:05:53]

Seems we can no longer take over someone else's CL... I'll land this and address
the issue in a follow up patch.

lgtm

https://codereview.chromium.org/2038753004/diff/160001/device/bluetooth/andro...
File
device/bluetooth/android/java/src/org/chromium/device/bluetooth/Wrappers.java
(right):

https://codereview.chromium.org/2038753004/diff/160001/device/bluetooth/andro...
device/bluetooth/android/java/src/org/chromium/device/bluetooth/Wrappers.java:165:
public boolean hasAndroidLocationPermission() {
On 2016/06/22 at 19:36:50, scheib wrote:
> The wrappers were designed to be the thinnest practical wrapper around the
Android classes. There are one or two examples of deviation (e.g.
getBluetoothClass_getDeviceClass), but they represent an API call and then
another call on the returned object.
> 
> This change adds a new concept to the wrapper that the android class doesn't
have, which I don't like. I see two main options:
> 
> 1) Access LocationUtils.getInstance() and have test code able to set expected
behavior for it in test executables.
> 
> 2) Sticking with this wrapper design, reworking as such:
> 
> To get virtual abstraction the wrappers need to be via a passed instance of an
object that is constructed elsewhere from code that knows if the executable is
production or test. Right now it is the adapter wrapper that is passed in to
ChromeBluetoothAdapter.java's constructor.
> 
> LocationUtils is a concept outside of the Adapter hierarchy, so we need a
wrapper for it passed in somehow.
> 
> A solution is to pass to ChromeBluetoothAdapter a new thing we create
'device.Wrappers' instance. That instance would have members for an
BluetoothAdapterWrapper and LocationUtilsWrapper.

Follow up patch here: http://crrev.com/2100313003

Adds a new test function that uses LocationUtils.setFactory to control
LocationUtils from tests. LocationUtils still requires a Context. For that, the
patch removes ContextWrapper from Wrappers and modifies FakeContext to extend
MockContext. We can then pass the mock context directly to LocationUtils.

[commit-bot: I haz the power, 2016-06-27 22:35:33]

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

[commit-bot: I haz the power, 2016-06-27 22:35:34]

Dry run: This issue passed the CQ dry run.

[ortuno, 2016-06-27 22:37:23]

The CQ bit was checked by ortuno@chromium.org

[ortuno, 2016-06-27 22:37:24]

The patchset sent to the CQ was uploaded after l-g-t-m from
blundell@chromium.org, tedchoc@chromium.org, finnur@chromium.org
Link to the patchset: https://codereview.chromium.org/2038753004/#ps160001
(title: "Adjust DEPS.")

[commit-bot: I haz the power, 2016-06-27 22:38:35]

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-06-27 22:51:46]

Description was changed from

==========
Add a components.location.LocationUtils class to give all Chromium Android code
access to location helpers.

This class currently helps code check if Chrome has permission to access
location and if location is turned on for the device.
==========

to

==========
Add a components.location.LocationUtils class to give all Chromium Android code
access to location helpers.

This class currently helps code check if Chrome has permission to access
location and if location is turned on for the device.
==========

[commit-bot: I haz the power, 2016-06-27 22:51:48]

Committed patchset #9 (id:160001)

[commit-bot: I haz the power, 2016-06-27 22:54:40]

Description was changed from

==========
Add a components.location.LocationUtils class to give all Chromium Android code
access to location helpers.

This class currently helps code check if Chrome has permission to access
location and if location is turned on for the device.
==========

to

==========
Add a components.location.LocationUtils class to give all Chromium Android code
access to location helpers.

This class currently helps code check if Chrome has permission to access
location and if location is turned on for the device.

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

[commit-bot: I haz the power, 2016-06-27 22:54:41]

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

[Khushal, 2016-06-28 00:34:27]

A revert of this CL (patchset #9 id:160001) has been created in
https://codereview.chromium.org/2105573002/ by khushalsagar@chromium.org.

The reason for reverting is: Breaks the downstream bots..

[ortuno, 2016-06-29 14:41:02]

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

[commit-bot: I haz the power, 2016-06-29 14:41:22]

Dry run: 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-06-29 16:09:03]

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

[commit-bot: I haz the power, 2016-06-29 16:09:04]

Dry run: This issue passed the CQ dry run.

[ortuno, 2016-06-29 16:13:39]

The CQ bit was checked by ortuno@chromium.org

[commit-bot: I haz the power, 2016-06-29 16:14: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-06-29 16:19:24]

Committed patchset #9 (id:160001)

[commit-bot: I haz the power, 2016-06-29 16:19:28]

CQ bit was unchecked.

[commit-bot: I haz the power, 2016-06-29 16:22:34]

Description was changed from

==========
Add a components.location.LocationUtils class to give all Chromium Android code
access to location helpers.

This class currently helps code check if Chrome has permission to access
location and if location is turned on for the device.

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

to

==========
Add a components.location.LocationUtils class to give all Chromium Android code
access to location helpers.

This class currently helps code check if Chrome has permission to access
location and if location is turned on for the device.

Committed: https://crrev.com/a082f486985a4631ce3db3329874b9834e369e4d
Committed: https://crrev.com/847bd1803edc5cebaf4047fb7c75f55b2c5727ab
Cr-Original-Commit-Position: refs/heads/master@{#402319}
Cr-Commit-Position: refs/heads/master@{#402833}
==========

[commit-bot: I haz the power, 2016-06-29 16:22:36]

Patchset 9 (id:??) landed as
https://crrev.com/847bd1803edc5cebaf4047fb7c75f55b2c5727ab
Cr-Commit-Position: refs/heads/master@{#402833}