a bug in maintaining the cache caused these warnings. when the cache
is full, caching code in SQLiteDatabase dropped an entry from the cache
to accommodate the new one. and if the just-dropped one is not in use
that object got GC'ed and caused a finalizer warning. Calendar is one app
that didn't use ? for bindargs (sometimes) and noticed this bug in that app
Fix is to not add the new enry to cache if the cache is already full.
that will cause the app's close() to release the entry.
another common case where this finalizer warning occurs is when unittests run.
if the test does not close the database in tearDown(), it will cause
database object and the compiled sql statement cache within the database
obj get GC'ed which cause finalizer warnings.
This permits implementing interfaces which are faster than using
remote Cursors. It then uses it for Settings & SettingProvider, which
together account for ~50% of total ContentProvider event loop stalls
across Froyo dogfooders.
For fetching Settings this looks like it should reduce average
Settings lookup from 10 ms to 0.4 ms on Sholes, once the
SettingsProvider serves most gets from in-memory cache. Currently it
brings the Sholes average down from 10ms to 2.5 ms while still using
SQLite queries on each get.
Extract all UI behavior from dock observer and ACTION_DOCK_EVENT.
Also introduce a desk type to go along with the car type all through
the resource system, since we now need to have corresponding high-level
broadcasts for desk dock mode. As part of that I also reworked some
of the logic for switching modes to all funnel through a single
update() call that looks all of the current state to decide what to
do next, and fixed various locking issues.
In addition I found there were bugs in the configuration change
handling causing us to only switch into the car mode config and
then never get out of it. Unfortunately now that we are actually
changing the configuration for each mode change, the transitions
between them are really crummy as we restart all kinds of
activities. :(
completed before we've successfully syncd the webview dimensions from Java to
native and in this case, we end up syncing a height of 0 to WebKit. This causes
hit detection to fail, as WebKit thinks we have a 0-height visible area. This
patch fixes this scenario by syncing the height of the webview back to WebKit
in the case that the first layout comes back before we've sent our dimensions.
Fix for b/2449863
Change-Id: Id72c37b17411f3409edc7104d83ca5ffd17ab09b
commit 35ade1c72b5fe34c177712108ccbc070eab11a87
Author: Shimeng (Simon) Wang <swang@google.com>
Date: Thu Mar 4 16:29:01 2010 -0800
Alternative way to fix the history picture drawing issue.
Disable zoom part for history picture mode.
Bug: 2462039
commit 1a27acaa36c60546e5e6b2e1caf4ce5488dad14b
Author: Shimeng (Simon) Wang <swang@google.com>
Date: Thu Mar 4 16:06:41 2010 -0800
Use the screen width to derive the desired scale.
This is to fix the history picture draw issue. Since the mActualScale
will be changed in some other places.
Bug: 2462039
Bug #2489288
Prior to this change, changing the display's orientation would not send an offset
change, which could cause live wallpapers relying on pixel offsets to display the
wrong position.
Bug #2376231: Apps lose window focus (and back key causes ANR) if the
lock screen is dismissed while the phone is in landscape mode
This is another case where we weren't recomputing the focused window
after changing the visibility policy.
bug #2479958: Investigate source of "Resources don't contain package
for resource number 0x7f0a0000"
Um, okay, so it turns out there were bugs all over the place where
we would load an XML resource from a another application, but not
use the Resources for that application to retrieve its resources...!
I think the only reason any of this stuff was working at all was
because it typically only cared about retrieving the resource
identifiers of the items (it would look up the values later).
Bug #2401082: Passion ERE26 monkey crash - InputMethodManagerService
Add some null checks.
All direct calls to mConnector in ExpandableListView should convert group/child flat positions
to/from absolute flat positions (that take header count into account).
Two conversion methods were added to do that.
If a search provider returns an extra in the cursor with the key
SearchManager.CURSOR_EXTRA_KEY_IN_PROGRESS, and the value true, then
the spinny in the search dialog will not stop, but the cursor
contents will still be used to update the results. This way, partial
search results can be sent while the user is informed that the search
is still in progress.