During the destroy sequence, it happens that the mWebViewClassic was
set to null in the transferMessages function and consequently, the
call to WebCoreThreadWatchdog.unregisterWebView(mWebViewClassic) is
not really removing the view from the watchdog's list; creating a
memory leak.
Change-Id: I2bae7c8d7c473e2af25e62a485699f88269d6658
Author: Jean-Christophe PINCE <jean-christophe.pince@intel.com>
Signed-off-by: Jean-Christophe PINCE <jean-christophe.pince@intel.com>
Signed-off-by: Shuo Gao <shuo.gao@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Author-tracking-BZ: 57869
A recent change altered semantics of getLanguage call to return client
language instead of service language. This solved problems
with interferences between two clients using different lanaguages.
This change created a bug - new TTS client instance have no language set.
Since reading user preferences requires additional permissions I've
added new tts service method - getClientDefaultLanguage that will return
user preferences.
I've also added new client method, getDefaultLanguage, that allow easy
access to this data.
Bug: 7666482
Change-Id: Ieb7d2ba3a99d20c513add97f054874720a1cd82e
* commit 'dc4beb483eb14f1b56154125c67b780802756572':
Make implementation of isEmpty consistent with implementation of getCount in HeaderListViewAdapter
* commit 'e7ec492f13355888c90b3f08fbc66e49dda7ed24':
Make implementation of isEmpty consistent with implementation of getCount in HeaderListViewAdapter
Regression caused by patch a607223f34
If an item click handler results in the ListView becoming detached
from the window, the performClick runnable could be executed twice.
Null out the mTouchModeReset runnable before running the click handler
so that it is not run by the detach handler.
Change-Id: I2fab60232027bb4876f9912088e0ffb9b17d308c
The way that the Gallery was adding views (which it does in layout)
triggered a requestLayout() because of a call to setLayoutParams()
in View.addViewInner(). This tripped up the new logic that makes
layout-in-layout work, causing layout to be called on every frame,
even when the app was not doing anything.
The fix is to call the appropriate version
of requestLayoutInner() to tell it to skip calls to requestLayout().
Issue #7714495 requestLayout in endless loop
Change-Id: Icdcd886d30e4dd972da36bc6e50732c7213530c5
Only plays a tone if the battery level is below 95% which
is the same heuristic used when determining whether to turn
the screen on.
Use new low battery and wireless charging sounds on Mako.
Bug: 7371658
Change-Id: Ia4527ec398d024ee418a4287e1fcbf0ec83bcc24
Fix for Issue ID 18316. Make isEmpty() return false when getCount() returns a non-zero value. So that the list cannot be considered empty when a header or footer is present.
https://code.google.com/p/android/issues/detail?id=18316
Change-Id: Ib69201e9d5ef3efcbb68ea298b8cc8ca6e027246
Signed-off-by: Emma Sajic <esajic@effectivelateralsolutions.co.uk>
This helps reduce the pressure on framework.jar, and makes it clear
that it should only be used by the system_server.
Bug: 7333397
Change-Id: I0858904239535380fbf30562b793e277d8c3f054
jchars is not released correctly if factory is NULL.
In addition, unnecessary string conversion removed.
Change-Id: I3ea58391dfe7a96ea6d6ae61bb0867a2d8d49fb0
Activity.setImmersive(boolean) / android:immersive="bool" are now public.
In addition, if the foreground activity is immersive then an update lock
will be held on its behalf. This lets applications such as movie players
suppress the display of intrusive notifications, OTA-availability dialogs,
and the like while they are displaying content that ought not to be
rudely interrupted.
The update lock aspect of this mode is *advisory*, not binding -- the
update mechanism is not actually constrained; it simply uses this information
in deciding whether/when to prompt the user. It's more a guideline than
a rule.
Bug 7681380
Change-Id: I3c412a84cbf3933e3bf0168f2c71c54a86e4b7e5
