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

Revert of Add a LocationUtils class to give all Chromium Android code access to location helpers. (patchset #9 id:160001 of https://codereview.chromium.org/2038753004/ )

Reason for revert:
Breaks the downstream bots.

Original issue's description:
> 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}

TBR=ortuno@chromium.org,blundell@chromium.org,finnur@chromium.org,scheib@chromium.org,tedchoc@chromium.org,jyasskin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

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

The CQ bit was checked by khushalsagar@chromium.org

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

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

[commit-bot: I haz the power, 2016-06-28 00:35:31]

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-28 00:37:53]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-06-28 00:39:11]

Description was changed from

==========
Revert of Add a LocationUtils class to give all Chromium Android code access to
location helpers. (patchset #9 id:160001 of
https://codereview.chromium.org/2038753004/ )

Reason for revert:
Breaks the downstream bots.

Original issue's description:
> 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}

TBR=ortuno@chromium.org,blundell@chromium.org,finnur@chromium.org,scheib@chro...
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
==========

to

==========
Revert of Add a LocationUtils class to give all Chromium Android code access to
location helpers. (patchset #9 id:160001 of
https://codereview.chromium.org/2038753004/ )

Reason for revert:
Breaks the downstream bots.

Original issue's description:
> 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}

TBR=ortuno@chromium.org,blundell@chromium.org,finnur@chromium.org,scheib@chro...
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

[commit-bot: I haz the power, 2016-06-28 00:39:12]

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

[ortuno, 2016-06-28 00:50:23]

On 2016/06/28 at 00:39:12, commit-bot wrote:
> Patchset 1 (id:??) landed as
https://crrev.com/e3c66d54cbcd9a7fd73bc2222dcb859741cc121d
> Cr-Commit-Position: refs/heads/master@{#402344}

Could you add more information or a stack trace? It's hard to fix the issue if
we have no information...

[Khushal, 2016-06-28 01:04:49]

On 2016/06/28 00:50:23, ortuno wrote:
> On 2016/06/28 at 00:39:12, commit-bot wrote:
> > Patchset 1 (id:??) landed as
> https://crrev.com/e3c66d54cbcd9a7fd73bc2222dcb859741cc121d
> > Cr-Commit-Position: refs/heads/master@{#402344}
> 
> Could you add more information or a stack trace? It's hard to fix the issue if
> we have no information...

https://uberchromegw.corp.google.com/i/internal.client.clank_tot/builders/cla...

This has the logs for the build that broke. Basically LocationSettingsInternal
still uses isSystemLocationSettingEnabled and getSystemLocationSettingsIntent
that were removed in this patch.

[Jeffrey Yasskin (google), 2016-06-28 07:07:23]

On 2016/06/28 01:04:49, Khushal wrote:
> On 2016/06/28 00:50:23, ortuno wrote:
> > On 2016/06/28 at 00:39:12, commit-bot wrote:
> > > Patchset 1 (id:??) landed as
> > https://crrev.com/e3c66d54cbcd9a7fd73bc2222dcb859741cc121d
> > > Cr-Commit-Position: refs/heads/master@{#402344}
> > 
> > Could you add more information or a stack trace? It's hard to fix the issue
if
> > we have no information...
> 
>
https://uberchromegw.corp.google.com/i/internal.client.clank_tot/builders/cla...
> 
> This has the logs for the build that broke. Basically LocationSettingsInternal
> still uses isSystemLocationSettingEnabled and getSystemLocationSettingsIntent
> that were removed in this patch.

Gah. I missed Ted's comment on
https://chrome-internal-review.googlesource.com/#/c/264185/. I don't think
there's any way to commit these patches independently because of Java's
@Override enforcement.

[Khushal, 2016-06-28 15:31:37]

On 2016/06/28 07:07:23, Jeffrey Yasskin (google) wrote:
> On 2016/06/28 01:04:49, Khushal wrote:
> > On 2016/06/28 00:50:23, ortuno wrote:
> > > On 2016/06/28 at 00:39:12, commit-bot wrote:
> > > > Patchset 1 (id:??) landed as
> > > https://crrev.com/e3c66d54cbcd9a7fd73bc2222dcb859741cc121d
> > > > Cr-Commit-Position: refs/heads/master@{#402344}
> > > 
> > > Could you add more information or a stack trace? It's hard to fix the
issue
> if
> > > we have no information...
> > 
> >
>
https://uberchromegw.corp.google.com/i/internal.client.clank_tot/builders/cla...
> > 
> > This has the logs for the build that broke. Basically
LocationSettingsInternal
> > still uses isSystemLocationSettingEnabled and
getSystemLocationSettingsIntent
> > that were removed in this patch.
> 
> Gah. I missed Ted's comment on
> https://chrome-internal-review.googlesource.com/#/c/264185/. I don't think
> there's any way to commit these patches independently because of Java's
> @Override enforcement.

Ah yeah, these changes can be tough. Usually you'd land the upstream change and
then immediately follow up with the downstream change that updates the chromium
revision to the one with your upstream change.

In this case though, I was wondering if you could start with deleting the
downstream code that depended on LocationSettings, disabling any tests it might
break. Land the upstream change and immediately  follow up with a downstream
change that uses the new APIs and enables the tests. I don't know if this will
be more preferred or it would just be an overkill.

Either way, if you do the former, just give the sheriff a heads up. :)

[Ted C, 2016-06-28 16:32:57]

On 2016/06/28 07:07:23, Jeffrey Yasskin (google) wrote:
> On 2016/06/28 01:04:49, Khushal wrote:
> > On 2016/06/28 00:50:23, ortuno wrote:
> > > On 2016/06/28 at 00:39:12, commit-bot wrote:
> > > > Patchset 1 (id:??) landed as
> > > https://crrev.com/e3c66d54cbcd9a7fd73bc2222dcb859741cc121d
> > > > Cr-Commit-Position: refs/heads/master@{#402344}
> > > 
> > > Could you add more information or a stack trace? It's hard to fix the
issue
> if
> > > we have no information...
> > 
> >
>
https://uberchromegw.corp.google.com/i/internal.client.clank_tot/builders/cla...
> > 
> > This has the logs for the build that broke. Basically
LocationSettingsInternal
> > still uses isSystemLocationSettingEnabled and
getSystemLocationSettingsIntent
> > that were removed in this patch.
> 
> Gah. I missed Ted's comment on
> https://chrome-internal-review.googlesource.com/#/c/264185/. I don't think
> there's any way to commit these patches independently because of Java's
> @Override enforcement.

A dirty/completely-legal workaround is to first have a small change downstream
that removes all the necessary @Override(s).  It won't affect anything at
runtime and allows you to do these types of changes.

Granted, it is dangerous if you forget, etc.., etc..., so it really should
only be used for these quick refactorings.