<The design image was changed to the full size>
From "U+FF10 fullwidth zero" to "U+FF19 fullwidth nine"
<Following characters were added>
"U+203C double exclamation poin","U+2047 double question mark","U+2048 question exclamation point"
"U+2049 exclamation question mark","U+261A Black left pointing index","U+261B Black right pointing index"
"U+261C White left pointing index","U+261D White up pointing index","U+261E White right pointing index"
"U+261F White down pointing index"
Change-Id: I1641926c13ce8e11fde794f5584119ad44607374
If an invalid input string ends with a backslash inside a comment
or quoted string, the returned index would be past the end of the
string. In one case this would lead to a runtime exception being
thrown from MultiAutoCompleteTextView.performValidation.
Change-Id: If629372b429716c25cdc25764f088e95d4812d57
A race condition when mounting a container in PackageHelper may cause
the system_server to crash (uncaught exception). Calling methods are
prepared to handle null, so return null instead.
Change-Id: I852ee21a2d847e37d81c1b900c27ddf94ef24fcb
Writes to Bluetooth sockets are handled by writeNative() in
android_bluetooth_BluetoothSocket.cpp. This calls asocket_write()
which is implemented in abort_socket.c.
This latter function sleeps until poll() indicates that the socket is
writeable, then calls write() once, returning the number of bytes
written. However writeNative() just returns this byte count to the
caller; it's eventually ignored in BluetoothOutputStream.java. This
doesn't match the semantics of a Java OutputStream, which is required
to block until all bytes have been written.
This fix adds a loop to writeNative() that repeatedly calls the lower
level write function until all the data has been written (or an error
occurred in which case we should exit the loop early). With this
change it is possible to write large amounts of data to a Bluetooth
socket without experiencing data loss.
Change-Id: I0b464382817e15adec32ba0e3cb37e7d1cccc730
eglMakeCurrent() would only deref the previous surfaces if the old and
new contexts were the same. eglTerminate() should not touch TLS.
eglReleaseThread() needs to unbind the current context.
Change-Id: I7f4c090a287ee1e29e4708ae10679fb9d7d8c8c5
Related-Bug: 2964479
A cache control header containing both no-cache and max-age attribute does not
behave as expected.
Cache-Control: no-cache, max-age=200000
Will set expired to 20000ms seconds, ignoring the no-cache header. My
interpretation is that the no-cache header should not be ignored in
this case.
Change-Id: Iadd1900e4d2c6c0dacc6bb3e7b944cf78ca9b266
Added handling of OutOfMemoryError handling to createImageThumbnail
method in ThumbnailUtils.java. During mediascanner run it would run
out of memory when trying to decode very large images. Now it handles
this error and returns null which is handled by the media scanner.
Change-Id: Ie68722dfa1cedd3c0847bf483baa40c4827ad5a8
When creating new vibration pattern, a callback is registered
in case binding to caller goes away, by linkToDeath().
Need to unregister this callback when we throw away the vibration.
Change-Id: Ibdf0bd415a539054ac7a66f49b33a864f729c546
Since String.replaceFirst uses regex and since SIP user names are
allowed to include regex charaters such as '+', the code must
fist convert the string to a literal pattern String before using
replaceFirst method.
Change-Id: I25eac852bd620724ca1c5b2befc023af9dae3c1a
Adding files outside $(LOCAL_PATH) is a bad idea. It generates output files
to an unexpected directory. In this case, it's
out/target/external/skia/src/images/SkImageDecoder_libjpeg.o
It's not in $(PRODUCT_OUT), which is not correct.
Worse, it makes the build system be unable to build different
architectures (arm and x86) simultaneously, since the output files
conflcit.
Seems we can just remove SkImageDecoder_libjpeg.cpp since it's
already in libskia.
Change-Id: I3e7533126ef60fe2fd424fdc777760e73c93489b
This is tricky: entry.getMessageBox() returns int, so it is
by default boxed to Integer. Map.get() however accepts Objects,
so it ignores the difference, but nothing is find during lookup,
just because Long and Integer objects are compared using equals(),
which has to lead to 'false' result. So, explicit boxning to Long
is unnecessary here.
Change-Id: I967a7829a8926410a00274c6b5e312e1af567299
* commit 'dff6b8e71dda9f5d841fa26408714aec2aef1505':
GpsLocationProvider: Clean up HAL initialization/cleanup sequence
Fixed GSM encoded network initiated position request
Ensuring thread-safe usage of DateFormat.
Fixing infinite loop for zero duration.
Fix for an infinite loop while scrolling lists.
WAPPushManager, WAP Push over SMS message handler
Add --non-constant-id to aapt.
DigitalClock could sometimes leak when the keylock was recreated.
This happened because onDetachedFromWindow() was called BEFORE
onAttachedFromWindow().
This is the flow that causes the memory leak:
1) The LockPatternKeyGuardView is created and added. This will start
a loop dispatching onAttachedToWindow() to all views involved.
2) PatternUnlockScreen.onAttachedToWindow() is called
3) If the configuration has changed since creation, recreateMe() in
LockPatternKeyguardView.java is called.
4) recreateScreens() is called
5) PatternUnlockScreen is removed (to be re-added later) in
LockPatternKeyguardView.recreateUnlockScreen()
6) Since DigitalClock is a part of PatternUnlockScreen, its
onDetachedFromWindow() will be called.
7) The loop started in 1) will continue to dispatch
onAttachedToWindow() - and will eventually call
DigitalClock.onAttachedToWindow()
8) DigitalClock.onAttachedToWindow() registers a receiver that is
normally unregistered in onDetachedFromWindow(). But since
onDetachedFromWindow was already called in 6), it will not be called
again.
9) The receiver has leaked, and it has a reference to DigitalClock,
so that will leak as well, together with its parents e.g.
PatternUnlockScreen and LockPatternKeyguardView
The fix is to wait with the recreation of the screens (in 4) until
the loop (in 1) is finished. This is done by posting this as an event
instead of calling recreateScreens() immediately.
It is possible that this a fix for the root cause mentioned in
"Fix 3106227: use WeakReferences for receivers in DigitalClock class"
8b886fab5496b0b1f5193f21855220176deddc37 by Jim Miller
<jaggies@google.com>.
Change-Id: I6a5f6f49a565d459bf4e285f34f053cc1022286f
