Adds Build.MANUFACTURER to native BuildInfo wrapper.

Adds Build.MANUFACTURER to native BuildInfo wrapper.

R=yfriedman@chromium.org
BUG=None

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

[Yaron, 2014-09-23 17:10:50]

On 2014/09/23 17:00:14, gunsch wrote:

Will this be used for crash reporting like the other fields? That's generally
what BuildInfo is for, fetching the fields early to avoid allocations when
signal handling. Otherwise you could use Build.MANUFACTURER directly in client
code.

[gunsch, 2014-09-23 17:24:49]

On 2014/09/23 17:10:50, Yaron wrote:
> On 2014/09/23 17:00:14, gunsch wrote:
> 
> Will this be used for crash reporting like the other fields? That's generally
> what BuildInfo is for, fetching the fields early to avoid allocations when
> signal handling. Otherwise you could use Build.MANUFACTURER directly in client
> code.

Hm, the documentation of the class seems otherwise to me: that yes, they're used
for crash dumps, but also just a common place to get that info. Though as I
search through the Chromium code, it does seem to confirm that crash handling is
essentially the only use case.

We'd like to use it for UMA data, so it doesn't necessarily need to be cached in
the same way. Since that's native code, I can write my own JNI wrapper + Java to
get that information, but this seemed like a more conceptually appropriate
location.

Let me know what you think.

[Yaron, 2014-09-23 19:06:20]

On 2014/09/23 17:24:49, gunsch wrote:
> On 2014/09/23 17:10:50, Yaron wrote:
> > On 2014/09/23 17:00:14, gunsch wrote:
> > 
> > Will this be used for crash reporting like the other fields? That's
generally
> > what BuildInfo is for, fetching the fields early to avoid allocations when
> > signal handling. Otherwise you could use Build.MANUFACTURER directly in
client
> > code.
> 
> Hm, the documentation of the class seems otherwise to me: that yes, they're
used
> for crash dumps, but also just a common place to get that info. Though as I
> search through the Chromium code, it does seem to confirm that crash handling
is
> essentially the only use case.
> 
> We'd like to use it for UMA data, so it doesn't necessarily need to be cached
in
> the same way. Since that's native code, I can write my own JNI wrapper + Java
to
> get that information, but this seemed like a more conceptually appropriate
> location.
> 
> Let me know what you think.

lgtm

I suppose it's reasonable and saves another bridge.

[gunsch, 2014-09-23 19:20:06]

The CQ bit was checked by gunsch@chromium.org

[commit-bot: I haz the power, 2014-09-23 20:31:36]

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

[commit-bot: I haz the power, 2014-09-23 21:39:27]

Committed patchset #1 (id:1) as 2c074ee35ee2fc1e46ee8659b645668bf64112cb

[commit-bot: I haz the power, 2014-09-23 21:40:05]

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