Add a method for catching low end devices

Add a method for catching low end devices

Add a Java and native method for detecting if a device should be considered low end.

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

[David Trainor- moved to gerrit, 2013-06-18 23:37:08]

ptal

[David Trainor- moved to gerrit, 2013-06-19 00:44:49]

ptal thanks!

klobag@: just a general fyi review
bulach@: base/android/*
darin@: base/*

[darin (slow to review), 2013-06-19 04:32:49]

LGTM for base/*gyp*

[bulach, 2013-06-19 11:32:38]

lgtm, but as you mentioned in the bug, this won't be accessible early in the
java startup if needed.. :(

here's some ideas to ensure both java and native use the same categories:
1) create a simple .h with memory thresholds, something along the lines:

DEFINE_DEVICE_MEMORY_TYPE(LOW_END, 512)
DEFINE_DEVICE_MEMORY_TYPE(TYPICAL, 1024)
DEFINE_DEVICE_MEMORY_TYPE(HIGH_END, 10240)

2) use the ../build/android/java_cpp_template.gypi mechanism to share these
constants across java and c++

3) have a very thin wrapper in each side that would call whatever mechanism is
available to obtain total physical memory (without relying on JNI), and then
bucketize the response..

this way we guarantee a consistent definition of the device-type across the
board, and will also be able to access it directly from whatever enviroment the
caller is, without additional restrictions... wdyt?

[David Trainor- moved to gerrit, 2013-06-19 21:22:29]

On 2013/06/19 11:32:38, bulach wrote:
> lgtm, but as you mentioned in the bug, this won't be accessible early in the
> java startup if needed.. :(
> 
> here's some ideas to ensure both java and native use the same categories:
> 1) create a simple .h with memory thresholds, something along the lines:
> 
> DEFINE_DEVICE_MEMORY_TYPE(LOW_END, 512)
> DEFINE_DEVICE_MEMORY_TYPE(TYPICAL, 1024)
> DEFINE_DEVICE_MEMORY_TYPE(HIGH_END, 10240)
> 
> 2) use the ../build/android/java_cpp_template.gypi mechanism to share these
> constants across java and c++
> 
> 3) have a very thin wrapper in each side that would call whatever mechanism is
> available to obtain total physical memory (without relying on JNI), and then
> bucketize the response..
> 
> this way we guarantee a consistent definition of the device-type across the
> board, and will also be able to access it directly from whatever enviroment
the
> caller is, without additional restrictions... wdyt?

This is needed quickly so I'll land what I have to unblock others then maybe
move to the template if it turns out we need this during start up.  I talked
with some of the people who would be using this and they aren't blocked by the
start up requirement yet.

[commit-bot: I haz the power, 2013-06-20 01:50:51]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/dtrainor@chromium.org/17151011/6001

[commit-bot: I haz the power, 2013-06-20 18:36:10]

Change committed as 207498