Optimize drawBitmapMesh using TRIANGLE_STRIP

Draw BitmapMesh using STRIP instead of TRIANGLES.
Depending on where the bottleneck is located in the pipeline,
there is a potential for saving two-thirds of the time spent rendering.
The speedup is due to avoiding redundant operations,
i.e., mapping each vertex four times to texture and color attribute,
sending each vertex twice to the GPU, vertex processing of GPU ...

In this patch:
1. Refactoring mesh using Strip.
2. Batch triangles by adding degenerate triangles.
3. Optimize computing positions of texture and color attribute.

Benchmark: Drawing Bitmap(1152x768 px) with 200x200 meshes
Performance is doubled (from 26.4 fps to 53 fps, Nexus10).
Memory footprint: only 17% of original method.
(from 240000 to 40401 vertices with xy, uv, rgba data.)

Change-Id: I08c5c20d981d88528ce7b02012feefae468d6ec4
Signed-off-by: kui.zheng <kui.zheng@arm.com>
DocumentsUI: Workaround for aapt warnings

* Now we should be completely free of aapt warnings

Change-Id: I8e6886f9ac93adb19c80887a1b7329ae9b942125
Bypass the lockscreen when the hardware keyboard is slid out and security mode is 'none'

Change-Id: Ie40bb33ea46b7e68bad9916a0073cdf07a42ff93
ProximitySensor: check for correct MaxRange value

Use TYPICAL_PROXIMITY_THRESHOLD for devices that returns incorrect mProximitySensor.getMaximumRange() value;

Presto's proximity sensor returns values: 0.0f(near) or 5.0f(far).
mProximitySensor.getMaximumRange() must return proximity sensor's availible range, but it always return 0, so mProximityThreshold is also 0.

So boolean positive = distance >= 0.0f && distance < mProximityThreshold;  positive will never be
true.
The cause of this problem is proprietary sensor.msm8660.so, it must set proper Range and Resolution for proximity sensor.

Change-Id: I0cf81fd20f210115cbd6db10c0070b12f1c57336