* commit 'c9cd2387b6938a6fbefc731d2177902266f2a130':
Fix a race that could cause GL commands to be executed from the wrong thread.
RefBase subclasses can now decide how they want to be destroyed.
Fix a race in SurfaceFlinger that could cause layers to be leaked forever.
Fix a race-condtion in SurfaceFlinger that could lead to a crash.
* changes:
Fix a race that could cause GL commands to be executed from the wrong thread.
RefBase subclasses can now decide how they want to be destroyed.
Fix a race in SurfaceFlinger that could cause layers to be leaked forever.
Fix a race-condtion in SurfaceFlinger that could lead to a crash.
LayoutLib: custom styles override the default style instead of replacing it.
Intead of reading either the custom or the default style for a widget, we
read both and use the values from the custom style if it exists, or
from the default style otherwise.
Change-Id: Ibcec2e9b1e8a95295ab26ede145c287ff2f30be4
This adds a destroy() virtual on RefBase which
sublasses can implement. destroy() is called
in lieu of the destructor whenthe last strong
ref goes away.
Bug: 4483050
Change-Id: I8cbf6044a6fd3f01043a45592b5a60fa1e5fade2
The transaction flags were atomically read-and-cleared to determine if
a transaction was needed, in the later case, mStateLock was taken to
keep the current state still during the transaction. This left a small
window open, where a layer could be removed after the transaction flags
were checked but before the transaction was started holding the lock.
In that situation eTraversalNeeded would be set but only seen during the
next transaction cycle; however, because we're handling this transaction
(because of another flag) it will be commited, "loosing" the information
about the layer being removed -- so when the next transaction cycle due
to eTraversalNeeded starts, it won't notice that layers have been removed
and won't populated the ditchedLayers array.
Bug: 4483049
Change-Id: Ibb5989312f871339928ee1aa3f9567770d72969b
Client::mLayers could be accessed from different threads.
On one side from Client::attachLayer() which is currently
called from a binder thread; on the other side from
Client::detachLayer() which is always called from the main
thread.
This could lead to a corruption of Client::mLayers.
We fix this issue by adding an internal lock to Client.
Bug: 4483046
Change-Id: I5262bf1124d9a65ec6f8ffd8e367356fc33a7536
When sending an SMS to an international number in the format
+401234567890, the "+" should be converted to the International
Dialing Prefix (in the US, 011). However, the device drops this
"+" altogether in the outbound data burst message causing the message
to fail or be sent to the wrong address.
Change-Id: If25c092d283f1703b49cf52d0379efa54639f093
Signed-off-by: Soojung Shin <sj46.shin@samsung.com>
- Signal level updates should be updated whenever a signal change
broadcast is received but it is failing to do so.
- Only when state change broadcast is received, signal level was
updated. (Ex: State: Idle -> State: Connected)
Change-Id: I71d86782143b3440a042164a87af64c7bee97ae2
Signed-off-by: TK MUN <tk.mun@samsung.com>
All the reads/updates methods are synchronous calls that rely
on an unique lock object in order to wait for the asynchronous
simcard operations to complete and return appropriate results
Concurent calls to these methods will cause errors when one
completed operation will unlock all waiting calls generating
inconsistent results on some of the method calls.
Change-Id: I8b87004ac039bcb971b8369f7640281f1bf9eb35
Signed-off-by: David Sobreira Marques <dpsmarques@gmail.com>
LayoutLib: Fix issue where <include> with no layout params wouldn't display.
The issue is that the layout params from the root element of the included
layout should be used but this failed because loading the layout params
from the <include> tag didn't throw a RuntimeException in our modified
code (BridgeTypedArray).
Because we don't want to throw exception in general we only throw it
when reading the layout params of an include node which is pretty crappy,
but works for now.
Change-Id: I83ccf956e8b476f34dfc9a70aebae2288d53746e
* commit '4b41df613db19c5fe1d8c0d05ef314326fd3f95b':
Use proper type for oob variable in register_agent. Without this change the BluetoothEventLoop crashes on my armv5 arch board.
When data less than max packet size in length is sent into the write
method the data will only be added to the internal buffer. If several
calls to write is performed by the application continueOperation will
not be called at all. The solution to the problem is to always check
the internal buffer size and to call continueOperation every time
maxPacketSize bytes is in the internal buffer.
Change-Id: I5ebfa3c26db2c1aefe1a115d7782d8ceaa760937
