Instead of using layout_margin for widget margins, the recommendation is to
now use padding. Additionally, update all docs to mention an example default
padding of 8dp instead of 15 or 16dp.
Change-Id: I330aedc56986dbb31a70260279ad2f6668c67c92
Korean characters show up as gabage characters in Music player.
Reason : MTP service does not set the locale for the MediaScanner
Solution : Set locale when MtpDatabase creates MediaScanner.
Bug ID : 5567433
Signed-off-by: dujin.cha <dujin.cha@samsung.com>
Change-Id: I4bfe5f603c113170d45bd57a8709c21c665e260b
http://b/issue?id=5629901
Change on state validation:
- When network state is broadcast in other network information,
the test activity will record the state change which cause false
alarm in the test.
Change-Id: I8bd1e8c04ab97116f3a02ccc5543f34a7e651cda
Added section for action provider, new APIs for handsets such as
split action bar, more information and diagrams for up navigation,
guidelines for picking action items, revised sample code and discussion
for tabs, add expandible action view info,
and expanded discussion for customizing action bar styles
bug:4726917
Change-Id: If61a5f2aad5ed21b0b23b3fc14309a50617f86ce
Donnot make the bluetoothservice.getUuids call if the bluetooth
is not on. Also get rid of all the necessary locks on BluetoothService
for get property call. It had a lock on BluetoothAdapterProperty.
bug5472114
Change-Id: I383472ae6006fc1f0129c960c8a44ed0df027a43
Fix a NullPointerException when sending a single-part SMS containing
characters in one of the enabled national language tables.
Also added a few log messages for several error cases to help with
debugging any future problems in the SMS dispatcher.
Bug: 5553544
Change-Id: I61c1cbe297b2e222027f0db7c833df6a03c2974a
Showing a congratulations screen after choosing face unlock backup lock
Once a backup lock has been chosen, it sends an intent to show a
congratulations screen. The moveTempGallery function has been moved
inside this new activity so it is no longer needed in LockPatternUtils.
Change-Id: I66868e6e3391b8b740f618fe633047ce388f55ca
We were not passing the length of the UTF-16 string to
String16::setTo. As a result, it was copying the contents of
the text up to the first null it found.
First problem, these strings are not typically null terminated!
Second problem, if the string contained a null character, then
we might truncate it. However, we only truncated the string
when the copy constructor was invoked (say, when we called
get() on the cache) but not in internalTextCopy() (before
adding the key to the cache).
As a result of the second problem, we would first search
the cache for a key that matched a partially copied truncated
string (potentially reading uninitialized memory that followed it).
Finding none, we would add the entry to the cache using
the correct key.
If the cache already had a value associated with the correct key,
then the put would fail, returning false. Charging ever onwards,
we would add the size of the entry to the cache size.
Proceeding in this manner, it was possible for the cache to
believe it had less remaining space than it really did. At that
point, it was possible for the cache to evict all entries and
yet still not think it had room to add a new one, so it would
continue trying to make space indefinitely.
Bug: 5576812
Change-Id: I05251594f6b2da0a5dc09f7200f04fe9100ec766
We were not passing the length of the UTF-16 string to
String16::setTo. As a result, it was copying the contents of
the text up to the first null it found.
First problem, these strings are not typically null terminated!
Second problem, if the string contained a null character, then
we might truncate it. However, we only truncated the string
when the copy constructor was invoked (say, when we called
get() on the cache) but not in internalTextCopy() (before
adding the key to the cache).
As a result of the second problem, we would first search
the cache for a key that matched a partially copied truncated
string (potentially reading uninitialized memory that followed it).
Finding none, we would add the entry to the cache using
the correct key.
If the cache already had a value associated with the correct key,
then the put would fail, returning false. Charging ever onwards,
we would add the size of the entry to the cache size.
Proceeding in this manner, it was possible for the cache to
believe it had less remaining space than it really did. At that
point, it was possible for the cache to evict all entries and
yet still not think it had room to add a new one, so it would
continue trying to make space indefinitely.
Bug: 5576812
Change-Id: I05251594f6b2da0a5dc09f7200f04fe9100ec766
