> There are variables that are not part of the Android build service as
> we have now (an example MONKEY_RUNNER):
> https://wiki.linaro.org/Platform/Android/LinaroAndroidBuildService
> Those should be environment variable used at some stage of the build.
> Where: I have no idea.
"As explained above, you may use other options/variables as supported by Android makefiles (they will be exported to the environment)."
I.e. it's explicitly documented that *arbitrary* variables can be used in android-build.linaro.org , it's just the case that some of variables have well-defined semantics (as documented in https://wiki.linaro.org/Platform/Android/LinaroAndroidBuildService), while the rest is just "allowed". So yes, presence of "user_defined_values" is understood, and it's not that easy to map legacy build into new structured build (for that, you should know all strictly defined fields, and parse them out).
> There are variables that are not part of the Android build service as /wiki.linaro. org/Platform/ Android/ LinaroAndroidBu ildService
> we have now (an example MONKEY_RUNNER):
> https:/
> Those should be environment variable used at some stage of the build.
> Where: I have no idea.
If you look at https:/ /wiki.linaro. org/Platform/ Android/ LinaroAndroidBu ildService it has
"As explained above, you may use other options/variables as supported by Android makefiles (they will be exported to the environment)."
I.e. it's explicitly documented that *arbitrary* variables can be used in android- build.linaro. org , it's just the case that some of variables have well-defined semantics (as documented in https:/ /wiki.linaro. org/Platform/ Android/ LinaroAndroidBu ildService), while the rest is just "allowed". So yes, presence of "user_defined_ values" is understood, and it's not that easy to map legacy build into new structured build (for that, you should know all strictly defined fields, and parse them out).