When Wi-fi connects at L2 layer, the beacons reach and the device
can maintain a connection to the access point, but the application
connectivity can be flaky (due to bigger packet size exchange).
We now use Watchdog to monitor the quality of the last hop on
Wi-Fi using signal strength and ARP connectivity as indicators
to decide if the link is good enough to switch to Wi-Fi as the uplink.
ARP pings are useful for link validation but can still get through
when the application traffic fails to go through and thus not best indicator
real packet loss since they are tiny packets (28 bytes) and have
much low chance of packet corruption than the regular data
packets.
Signal strength and ARP used together ends up working well in tests.
The goal is to switch to Wi-Fi after validating ARP transfer
and RSSI and then switching out of Wi-Fi when we hit a low
signal strength threshold and waiting until the signal strength
improves and validating ARP transfer.
Change-Id: Ica593291ec7772da892f03cf45b649635b730c47
Combine the code for opening readable and writable databases.
This improves the handling of the case where a database cannot
be opened because it cannot be upgraded. Previously we would
open the database twice: first read-write, then read-only, each
time failing due to the version check. Now only open it once.
Removed the goofy locking logic related to upgrading a read-only
database to read-write. We now do it in place by reopening the
necessary connections in the connection pool.
Change-Id: I6deca3fb90e43f4ccb944d4715307fd6fc3e1383
When you swipe to dismiss a recent item on a
tablet, fade the item to 0 alpha
Also, create common interface for Recents-specific
methods for Recents[Horizontal/Vertical]ScrollView
Bug: 5953654
Change-Id: I0a72b49b3cfae0607b42dbf8f6d4da9898d7e491
This is a problem only when using TextView's internal scroll.
Since there was no bug report about this obvious problem, it
looks like most EditText are single ine or located inside of
a ScrollView.
Change-Id: I699ad0078c9df64c70d10c64f0293b404485e05f
Continued work on making the copies of threadLoop more similar:
- Remove alias for mActiveTracks in MixerThread and DuplicatingThread.
- Pull in declaration of activeTrack in DirectOutputThread.
- Remove redundant parameter of prepareTracks_l().
- Comment prepareTracks_l().
Change-Id: If1087c1902b454acec01ddfdd9f055f0ca7abf04
An "UpdateLock" works similarly to a wake lock in API: the caller is
providing a hint to the OS that now is not a good time to interrupt
the user/device in order to do intrusive work like applying OTAs.
This is particularly important for headless or kiosk-like products
where ordinarily the update process will be automatically scheduled
and proceed without user or administrator intervention.
UpdateLocks require that the caller hold the new signatureOrSystem
permission android.permission.UPDATE_LOCK. acquire() and release()
will throw security exceptions if this is not the case.
The "is now convenient?" state is expressed to interested parties
by way of a sticky broadcast sent only to registered listeners. The
broadcast is protected; only the system can send it, so listeners
can trust it to be accurate. The broadcast intent also includes a
timestamp (System.currentTimeMillis()) to help inform listeners that
wish to implement scheduling policies based on when the device became
idle.
The API change here is a tiny one: a dump(PrintWriter) method has been
added to the TokenWatcher class to facilitate getting information out
of it for dumpsys purposes. UpdateLock itself is still @hide.
Bug 5543442
Change-Id: I3709c831fc1883d7cb753cd2d3ee8e10a61e7e48
Most of these comments will be removed after the threadLoop merge.
Note: the trivial change in assignments to mixBufferSize, and the
comments about "tracks to remove" is to make them all identical.
Change-Id: I3b1a33a7f2cd12ad557a1986bb71f6171161974a
