* commit 'e3c754bb1c518c9166ff4275b5ee59f36c999f4c':
Ensure LocationRequest's worksource defaults to null Helps to make sure the service doesn't throw a SecurityException for not having the UPDATE_DEVICE_STATS permission.
In some cases, we end up being called by code that doesn't have a valid
Context. It got away with this historically because it wasn't formatting
times (just dates), so it never went down a path that tried to query the
user's 12/24-hour preference. This patch just ensures that we don't try
to get the preference unless we actually need it.
Bug: 10339015
(cherry picked from commit 8d8ef00c8276200f108433922761401817fd9a50)
Change-Id: If074a67fa52943c0ec7bb5c5bbe5a11f54fb1f97
Also increase the size of the buffer we do need, simplify the code, and
fix some of the error checking.
(cherry-pick of 56968581ce77d3c0ee4286da6b0d5548874934b9.)
Bug: http://code.google.com/p/android/issues/detail?id=36193
Bug: 10363597
Change-Id: Iadd2ee25469a37ddf06c3292b675a4cbcc4ecfa3
Bug #10347089
If an app clears its path cache before stopping background tasks, it could
get into an infinite loop in PathCache::trim().
Change-Id: Ieb865b762e7b00aebaba0c023769c2db286a94f5
When reading from the end of a pipe or socket, there is no way to
tell if the other end has finished successfully, encountered an error,
or outright crashed. To solve this, we create a second socketpair()
as a communication channel between the two ends of a pipe or
socket pair, sending a status code with details about why the
ParcelFileDescriptor was closed.
The writer end of a pipe or socket can closeWithError() to send a
message to the reader end. When the reader encounters EOF, they
call checkError() to detect if any error occured. This also detects
the case where the remote process died without sending a success
message.
This design is also extended to support regular files on disk, using
the communication channel above to detect various remote close events
or crashes, and delivering that event to a supplied OnCloseListener.
Replaces JNI with best-practice Libcore.os calls, and deprecates
some flags to match Context.
Bug: 10330121
Change-Id: I8cfa1e4fb6f57397667c7f785106193e0faccad3
- put am/pm on the left side of hours for hu, zh, ja and ko Locales
- use the hours/minutes separator from the Locale (fi, sr, ...)
- updated layouts (better for Arabic, Farsi and Hebrew)
- support double digits format for 12h and single digit format for
24h (it, ja, vi, ...)
- fix setIs24HourView(boolean) behavior: do not lose the current hour
value when switching from 12h to 24h
Change-Id: If66cb6f802d894f0a2357b43eede6854791f3b67
Helps to make sure the service doesn't throw a
SecurityException for not having the UPDATE_DEVICE_STATS
permission.
Change-Id: I9be0302f1378d2c4441e6b7d5ce472ed0d5fbd80
Previously, a running transition on a scene root would simply
be canceled when a new transition was started. This would result in
abrupt scene changes, especially in generic use cases where apps/widgets
would spawn multiple transitions in successive rendering frames due to
small changes in view properties.
The new approach is to check all running animations against new transitions.
If there are overlapping properties that are being set to different values,
the new animations win and the old ones are canceled. If the end values are the
same, the new animations are noop'd and the old ones are allowed to continue
as-is.
There was also improvement to capturing state while other transitions are
running, necessary in this new world where old transitions are allowed to
continue running. Now, transitions are pause()'d while values are captured,
then resume()'d after capturing is done. This allows the system to see what the
real view properties are, instead of the mid-animation values.
Change-Id: I8e77fb9c1967087a682bb26a45763005f5ca9179
- No longer return null when some bad error happens
- Throws OutOfResourcesException when images need to be closed
- Throws IllegalStateException when an unknown internal error happens
Bug: 10333400
Change-Id: Ia53a5dd33f9ce53abd036e080e6fcc4ded9b251d
Support pending ops by producing badly formed xml.
fixed bug that stopped alarm manager from updating if the
next alarm time is in the past.
Use new AlarmManager API for old AM behaviour - to set
exact alarms.
Change-Id: I57090f9c7155996298be7ec968a88f17ac1938a7
In some cases, we end up being called by code that doesn't have a valid
Context. It got away with this historically because it wasn't formatting
times (just dates), so it never went down a path that tried to query the
user's 12/24-hour preference. This patch just ensures that we don't try
to get the preference unless we actually need it.
Bug: 10339015
Change-Id: I2df466d85cdeba14dbf882498808cbad9bbb57f4
