When the same page is loaded, updateRestoreState
will be false when we finish the first layout. As
we are still in the same page, we don't want to
update the current zoom/scroll. But in some cases,
like a site switch from mobile to full site and
keeps the same url, we do want to update the zoom
range as the viewport spec changed. Otherwise, user
can't zoom in the full site as the WebView thought
it is still a mobile non-scalable page.
A refactoring of handleDisconnect instroduced a bug - we were reporting
NO_CONNECTIVITY after any non-primary network (supl, mms, hipri) was lost.
bug:2395006
Change-Id: Ifa9e008872ec646981a35f2c316120cb9685a6a4
The original fix eliminated duplicate wifi connectivity changes stemming from
location provder scan's for APs. These would generate two DISCONNECTED broadcasts every
two minutes and many apps mis-interpreted them.
The fix was to ignore notifications where the major state was the same as the previous one
for each network. Unfortunately the state of per-apn notifications on cellular is hacky
and so the wifi fix was breaking mms (mms when you're on cellular with a common default+mms apn does
not generate a disconnect notification (apn still connected) so subsequent connect notifications
get dropped as duplicates).
This change refines the previous change so that it only applies to wifi networks.
bug:2392061
Change-Id: I05d8a46a4b55f8d28df8af12e05284e5e68bfc02
drno: ryanpc
The problem occurs if the delay between the headset removal and insertion is less than one second.
In this case, as the headset disconnection intent is broadcast with a 1 second delay to allow music to pause
before updating the route, the connection intent is broadcast before and is ignored, leaving the system
in a state where the headset is considered disconnected.
The fix consists in inserting a delay before broadcasting the connection intent if a disconnection
intent is pending broadcast.
- ContactHeaderWidget has cascading async queries, which weren't cancelled if a new query for a different phone number is started.
If the new query fails to find a corresponding contact, the old async queries from the previous number could end up setting the
contact name and photo to the wrong contact.
I tested this by calling
ContactHeaderWidget.bindFromPhoneNumber(number1);
ContactHeaderWidget.bindFromPhoneNumber(number2);
where number1 has a corresponding contact in the databse, and number2 doesn't. At the end of these 2 calls, the ContactHeaderWidget
would display the contact info for number1.
- also found a bug in AsyncQueryHandler.cancelOperation(), which doesn't reliably cancel the previous query. In ContactHeaderWidget's
case, we really depend on the cancelling to work. So work around this bug by resetting mAsyncQueryHandler when we need to do a
new lookup/query. When the old query result is passed back in the callback, discard the result if the QueryHandler is not the same
as mAsyncQueryHandler.
Change-Id: Ice79e77f787af03400e080cbd58162a91838181f
for the width/height on each touch down as orientation
can change.
This should fix the problem where we can't pinch on the
top right corner when device is in landscape mode.
Just scale the canvas instead of changing the real
scale factor during pinch.
Added over limit zoom feedback for pinch in the WebView.
Fix http://b/issue?id=2383539
Sleep for 100us and try to open the input device again if it fails, with a
maximum of 10 attempts.
We need the retry logic because setting permissions on a new input device is
racy. The init process watches for new input device (via uevent) and sets the
permission on them in devices.c:make_device(). However at the same time
EventHub.cpp watches for new input devices from the system_server process, and
immediately tries to open them. I can't see a simple way to avoid this race
condition.
As best as I can tell this race condition has always exisited.
There must have been some timing change that happened recently that causes us
to hit this race condition much more often. See repro notes in referenced bug.
Bug: 2375632
This shouldn't be required, but there seems to be something odd going on
in wifi and it doesn't hurt to try other available options. Makes a
connection failure case work like a disconnected case.
bug: 2378462
