This capability (a subset of FULL) indicates that a camera device
can capture high-rate (>= 20fps) bursts of images at full device
resolution, in at least the YUV_420_888 format.
It also guarantees that the synchronization latency for a device is
relatively small, so that fixed-setting bursts can be captured quickly.
Bug: 18281970
Change-Id: Ifc8fc43252a77097d804429d1c9f6fa71a95aa4f
This helps us in majority of the scenarios where the sound model doesn't
change across start/stop calls.
Bug: 17954633
Change-Id: Ibff817bb69bc69d2bb3a2603460fed596688b892
When PowerManager.boostScreenBrightness() is called, the screen
brightness is set to maximum for 5 seconds. This action is
also considered to be user activity.
Bug: 17934954
Change-Id: I1cb4a03a60705c6c1c5cc9ff84b1c5dbd2932fcd
- Change 'protected' to 'package private'.
- Change '@hide' to '{@hide}' for methods which should be still hidden
for linting.
- Rename addVendorCommandListener to setVendorCommandListener and make sure to be called once.
- Fix the implementation of removeHotplugEventListener().
Bug: 18063669
Change-Id: I5c032736f17bab9518f21596f7adeac2f88ba4c1
- removed unregisterContentObserver() to reactivate the service later.
- added the parameter destAddress to onReceived() callback to
distinguish whether the message is broadcast or not.
Bug: 17962624
Change-Id: I552d14661583f63bb66b07866092f972b259b15a
Returns the list of all the connected CEC device information. This is
different from getInputDevices() which returns devices of source type only.
For this, turned the local device address list to unmodifiable so that it can
be used by any threads.
Now respects the device type info passed through <Report Physical Address>
rather than always defaulting to the one from HdmiUtil.getTypeFromAddress().
This ensures future compatibility when a device of reserved logical address
comes with a specific type.
Bug: 18046603
Change-Id: I5f7d5e31706efba1ad5dcf4bcfd4ffc918d1d940
- Add entries for units and range into javadoc
- Fix up existing units entries and add new ones
- Fix up range entries to be consistent for enums
- Add range entries where it makes sense
- Minor fix to javadoc gen to allow for code indentation
- Lots of edits for consistency, especially to
available* entries.
Bug: 16525650
Change-Id: Id09663d897ec98122073e6e13719731ec0de4dad
The motivation is an API change: FloatMath is going to be
deprecated and/or removed. Performance is not the goal of
this change.
That said...
Math is faster than FloatMath with AOT compilation.
While making the change, occurances of:
{Float}Math.sqrt(x * x + y * y) and
{Float}Math.sqrt({Float}Math.pow(x, 2) + {Float}Math.pow(y, 2))
have been replaced with:
{(float)} Math.hypot(x, y)
Right now there is no runtime intrinsic for hypot so is not faster
in all cases for AOT compilation:
Math.sqrt(x * x + y * y) is faster than Math.hypot(x, y) with
AOT, but all other combinations of FloatMath, use of pow() etc.
are slower than hypot().
hypot() has the advantage of being self documenting and
could be optimized in future. None of the behavior differences
around NaN and rounding appear to be important for the cases
looked at: they all assume results and arguments are in range
and usually the results are cast to float.
Different implementations measured on hammerhead / L:
AOT compiled:
[FloatMath.hypot(x, y)]
benchmark=Hypot_FloatMathHypot} 633.85 ns; σ=0.32 ns @ 3 trials
[FloatMath.sqrt(x*x + y*y)]
benchmark=Hypot_FloatMathSqrtMult} 684.17 ns; σ=4.83 ns @ 3 trials
[FloatMath.sqrt(FloatMath.pow(x, 2) + FloatMath.pow(y, 2))]
benchmark=Hypot_FloatMathSqrtPow} 1270.65 ns; σ=12.20 ns @ 6 trials
[(float) Math.hypot(x, y)]
benchmark=Hypot_MathHypot} 96.80 ns; σ=0.05 ns @ 3 trials
[(float) Math.sqrt(x*x + y*y)]
benchmark=Hypot_MathSqrtMult} 23.97 ns; σ=0.01 ns @ 3 trials
[(float) Math.sqrt(Math.pow(x, 2) + Math.pow(y, 2))]
benchmark=Hypot_MathSqrtPow} 156.19 ns; σ=0.12 ns @ 3 trials
Interpreter:
benchmark=Hypot_FloatMathHypot} 1180.54 ns; σ=5.13 ns @ 3 trials
benchmark=Hypot_FloatMathSqrtMult} 1121.05 ns; σ=3.80 ns @ 3 trials
benchmark=Hypot_FloatMathSqrtPow} 3327.14 ns; σ=7.33 ns @ 3 trials
benchmark=Hypot_MathHypot} 856.57 ns; σ=1.41 ns @ 3 trials
benchmark=Hypot_MathSqrtMult} 1028.92 ns; σ=9.11 ns @ 3 trials
benchmark=Hypot_MathSqrtPow} 2539.47 ns; σ=24.44 ns @ 3 trials
Bug: https://code.google.com/p/android/issues/detail?id=36199
Change-Id: I06c91f682095e627cb547d60d936ef87941be692
Generally, JPEGs are better with thumbnails, and the default parameters
typically set a basic thumbnail size. In legacy, include a default size in the
templates.
This also works around issues with some devices not producing valid images with no
thumbnail.
Bug: 17724701
Change-Id: I2ad1449fc8c6d1fdec609af55f53db7491abbb92
Bug: 17675571
- Check for JPEG footer in correct location from ImageReader
when using the RGBA override.
- Add additional error checks in produceFrame method.
- Avoid allocating extra space for jpeg buffers due to
incorrect width calculations.
Change-Id: I926f37e8b3e5c4bad24c16dcee48d52adb1706dd
It's possible for the device to have close() called on it
during the session close sequence such that the session still
tries to do a stream reconfiguration on the closed device.
Handle the exception thrown by this attempt.
Bug: 17661765
Change-Id: Iee63c5c559405abe5c044ae251ad56edd1fb3e79
Fixes an illegal state exception that sometimes occurs during
configuration. Fixes a deadlock during unconfiguration. Fixes
the idle handler never being run during configuration.
Bug: 17628736
Change-Id: Id2c5e416f96fcbac9c718fca3cc2cf21734bc6a4
Otherwise, stale IDs for old streams will be left around, causing
JPEGs to be sent to the wrong consumers.
Bug: 17659125
Change-Id: I98e1a1d389147631bc80eaeb10d57f74a6256f32
When the camera service dies, the getParameters call is often the first
to fail, and on legacy mode, this frequently happens in a background thread.
Catch the runtime exceptions and convert to device errors, instead of killing
the process.
Bug: 17587496
Change-Id: I6757961e7c0387defd368a13cb7c343950602400
