android envsetup: Use gyp defines instead of env vars for sdk root and sdk tools.

android envsetup: Use gyp defines instead of env vars for sdk root and sdk tools.

If ANDROID_SDK_ROOT is set, it's still added to the path for now, but it's
no longer passed to gyp. If you want to set a custom sdk root, call gyp like
"build/gyp_chromium -Dandroid_sdk_root=path".

If ANDROID_SDK_ROOT is not set, it's still getting exported with a default
value that's identical to the default value of gyp's android_sdk_root variable.

ANDROID_SDK_TOOLS and ANDROID_SDK_BUILD_TOOLS_VERSION are now
completely ignored. Set the android_sdk_tools or android_sdk_build_tools_version
gyp defines instead if you need to change either. If they are not set,
envsetup no longer sets them.

(Dependent on an internal that changes a bot to set these gyp defines in
addition to the env vars.)

BUG=330631
NOTRY=true

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=251904

[Torne, 2014-02-17 12:14:19]

https://codereview.chromium.org/164193010/diff/60001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/164193010/diff/60001/build/common.gypi#newcod...
build/common.gypi:1404: 'android_sdk_tools%':
'<(android_sdk_root)/build-tools/<(android_sdk_version).0.0',
I don't think this is correct; I think the current sdk tools version being
19.0.0 is only a coincidence and this isn't necessarily the same as
android_sdk_version. The tools are updated independently of the API level.

[Nico, 2014-02-17 16:20:20]

https://codereview.chromium.org/164193010/diff/60001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/164193010/diff/60001/build/common.gypi#newcod...
build/common.gypi:1404: 'android_sdk_tools%':
'<(android_sdk_root)/build-tools/<(android_sdk_version).0.0',
On 2014/02/17 12:14:19, Torne wrote:
> I don't think this is correct; I think the current sdk tools version being
> 19.0.0 is only a coincidence and this isn't necessarily the same as
> android_sdk_version. The tools are updated independently of the API level.

Are you sure? They were updated at the same time the last time:
https://codereview.chromium.org/63153014

frankf thought a similar patch was ok (
https://codereview.chromium.org/download/issue167643002_200001.diff )

(I'm aware that in 18, the sdk tools folder was in 18.0.1 and not 18.0.0 – but
under the assumption that when one upgrades the sdk one wants to upgrade the sdk
tools too, having one reference the other still seems better as this makes it
impossible to forget about one of them. And if ".0.0" is wrong in some version,
one will get a try error when upgrading the version variable but forgetting
about ".0.0".)

[Torne, 2014-02-17 16:46:21]

On 2014/02/17 16:20:20, Nico (away Feb 11 - Feb 17) wrote:
> https://codereview.chromium.org/164193010/diff/60001/build/common.gypi
> File build/common.gypi (right):
> 
>
https://codereview.chromium.org/164193010/diff/60001/build/common.gypi#newcod...
> build/common.gypi:1404: 'android_sdk_tools%':
> '<(android_sdk_root)/build-tools/<(android_sdk_version).0.0',
> On 2014/02/17 12:14:19, Torne wrote:
> > I don't think this is correct; I think the current sdk tools version being
> > 19.0.0 is only a coincidence and this isn't necessarily the same as
> > android_sdk_version. The tools are updated independently of the API level.
> 
> Are you sure? They were updated at the same time the last time:
> https://codereview.chromium.org/63153014
> 
> frankf thought a similar patch was ok (
> https://codereview.chromium.org/download/issue167643002_200001.diff )
> 
> (I'm aware that in 18, the sdk tools folder was in 18.0.1 and not 18.0.0
–&nbsp;but
> under the assumption that when one upgrades the sdk one wants to upgrade the
sdk
> tools too, having one reference the other still seems better as this makes it
> impossible to forget about one of them. And if ".0.0" is wrong in some
version,
> one will get a try error when upgrading the version variable but forgetting
> about ".0.0".)

I'll happily defer to someone who has any involvement in updating the sdk for
the regular android build; I haven't used the SDK much lately so I might just be
remembering this wrong...

[Nico, 2014-02-17 16:57:27]

Yaron, do you know if an android sdk version upgrade always implies an android
sdk tools version upgrade?

[Yaron, 2014-02-18 18:55:51]

https://codereview.chromium.org/164193010/diff/60001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/164193010/diff/60001/build/common.gypi#newcod...
build/common.gypi:1404: 'android_sdk_tools%':
'<(android_sdk_root)/build-tools/<(android_sdk_version).0.0',
On 2014/02/17 16:20:21, Nico wrote:
> On 2014/02/17 12:14:19, Torne wrote:
> > I don't think this is correct; I think the current sdk tools version being
> > 19.0.0 is only a coincidence and this isn't necessarily the same as
> > android_sdk_version. The tools are updated independently of the API level.
> 
> Are you sure? They were updated at the same time the last time:
> https://codereview.chromium.org/63153014
> 
> frankf thought a similar patch was ok (
> https://codereview.chromium.org/download/issue167643002_200001.diff )
> 
> (I'm aware that in 18, the sdk tools folder was in 18.0.1 and not 18.0.0
–&nbsp;but
> under the assumption that when one upgrades the sdk one wants to upgrade the
sdk
> tools too, having one reference the other still seems better as this makes it
> impossible to forget about one of them. And if ".0.0" is wrong in some
version,
> one will get a try error when upgrading the version variable but forgetting
> about ".0.0".)

Two things come to mind:
1) When we first getting the SDK tools to work, we had to rely on a specific
revision of SDK tools so Torne's point of them being revved independently is
true, however, we did rely more heavily on the SDK-provided tooling at the time.
2) The android build for third party apps are switching from ant to gradle.
However, since we have gyp, we've tried to fit best within that and so we've
minimized usage of android-provided build tools (not the binaries themselves
necessarily, but more how they're used). I could imagine them deprecating
support for old tools and we may want to keep our old ones limping along for a
time since we really don't use much.
 
Anyway, long story short, I agree it's coincidence and can maintain a separate
define in gyp.

[Nico, 2014-02-18 19:57:37]

Ok, changed the code and update the CL description. PTAL :-)

[Yaron, 2014-02-18 23:02:13]

On 2014/02/18 19:57:37, Nico wrote:
> Ok, changed the code and update the CL description. PTAL :-)

lgtm

[Nico, 2014-02-18 23:27:00]

The CQ bit was checked by thakis@chromium.org

[commit-bot: I haz the power, 2014-02-18 23:28:35]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/thakis@chromium.org/164193010/270001

[commit-bot: I haz the power, 2014-02-19 00:46:45]

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

[commit-bot: I haz the power, 2014-02-19 00:46:45]

Retried try job too often on win_rel for step(s) browser_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[Nico, 2014-02-19 00:47:48]

The CQ bit was checked by thakis@chromium.org

[commit-bot: I haz the power, 2014-02-19 00:50:21]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/thakis@chromium.org/164193010/270001

[commit-bot: I haz the power, 2014-02-19 00:52:54]

Change committed as 251904