"startPos + addedRows < requiredPos" could miss a row in boundary position.
Because of the fluctuating row size, "startPos + addedRows < requiredPos" expression could miss a row in boundary position.
For example, simply speaking,
if window capacity = 120 and requiredPos = 120,
"fillWindow" needs to be newly called and "starPos" is 80 for the window.
Unfortunately 120th row is bigger than the rest size of the window,
the row for requiredPos is not in the window.
Then, startPos has to be newly set and the 120th row has to be included in the window.
But by the expression above "startPos + addedRows < requiredPos",
the row for requiredPos is regarded as included in the window.
In that case, by "mCurrentRowID = Long.valueOf(getLong(mRowIdColumnIndex));" statment in AbstractCursor,
IllegalStateException is thrown.
This patch contains modification of the expression as "startPos + addedRows <= requiredPos".
Change-Id: Iaee75241e495949b0a624b836843da18d0bcb98d
Wi-Fi should be in active state during the entire DHCP process, and
shouldn't go to IEEE 802.11 power save mode. If the framework requests
scan during the DHCP process, the Wi-Fi chip has to start scanning
on channels different from the current one, and going to power save
mode is a prerequisite for scan. The result directly impacts user
experience: DHCP process takes longer, and even can fail.
Change-Id: I8171388bb70072e4c42cb3c074dd955da84e494b
The color of timer and backgroud in MediaController
are too closer to distinguish.
Change-Id: Id60ecbc26233857c7ef291ef891c9d4720309dfa
Signed-off-by: Roger Chen <cxr514033970@gmail.com>
This speeds up certain workloads considerably, particularly
those involved in buildling apps via the SDK. Windows-based
use should particularly benefit from the change.
Change-Id: I29f4b3a77400b201ee219729cc28a5e359c0c5e8
Devices setting persistent_reconnect to 0 in wpa_supplicant returns "information is currently unable" error.
In that case, the connection establishment was always failed when the other device does NOT handle the invitation request.
So, try go-negotiation for interoperability.
Change-Id: Ia30a1c63d1bb4acc186a71248fb0aa5ea7edc627
Signed-off-by: Yoshihiko Ikenaga <yoshihiko.ikenaga@jp.sony.com>
Previously, cache textures were updated whenever mCurrentCacheTexuture was changed.
Since updating cache textures needs glTexSubImage2D call, frequent changing
of mCurrentCacheTexture (which can easily happen when an app uses lots of unique glyphs
even with precaching) caused many glTexSubImage2D calls and bad framerates.
This patch optimized isssueDrawCommand function. Consequently, changing mCurrentCacheTexture doesn't
cause glTexSubImage2D call any more and it will improve font rendering performance.
Change-Id: Id19d959fa0e69eeb2a39f83a57e311d7394586b2
Signed-off-by: Sangkyu Lee <geteuid@gmail.com>
The usage instructions of the content shell command were missing some
excape charecters which caused the examples not to work. As a result
of the incorrect instructions users are prone to constructing incorrect
commands.
bug:7526252
Change-Id: I2fcc4dd1fd05806fe951245651b97e40a4786d24
FindBugs description:
There is an apparent recursive loop at IntProperty.java
in method set(Object, Integer)
This method unconditionally invokes itself. This would seem
to indicate an infinite recursive loop that will result in a stack overflow.
Change-Id: I2f52dd3689198cb948925aa65dd9c95be7888fe7
This reverted change was adjusting the min and max values for the NumberPicker
which is not desirable since it changes behavior and it will be possible for
an app that works on the current platform to crash on an older one. Also the
adjustment was not implemented correctly.
Updated the documentation to clarify the reltionship between the min value,
max value, and the displayed values array.
Bug:7518172
This reverts commit a1410e6789ce72bc423793315a51aea8b6bad6c7
Change-Id: I109f1b1f54c1e609941243cabab9241871b6b12b
- When notifications vibrate as a fallback (that is,
because they want to play a sound but the device is in
vibrate mode), this no longer requires the VIBRATE
permission.
- As a bonus, if your notifications use DEFAULT_VIBRATE,
you don't need the VIBRATE permission either.
- If you specify a custom vibration pattern, you'll still
need the VIBRATE permission for that.
- Notifications vibrating in fallback mode use same
vibration pattern but can be changed easily in future.
- The DEFAULT_VIBRATE and fallback vibrate patterns are now
specified in config.xml.
Bug: 7531442
Change-Id: I7a2d8413d1becc53b9d31f0d1abbc2acc3f650c6
