If connect() fails with EALREADY, then retry.
Unfortunately we also need to switch to a new FD. This is currently
safe, but its a little fragile to changes in the code (especially
if we ever expose the fd to applications) so it would be great to
fix this issue properly in the kernel sometime and revert this
commit.
Change-Id: I12fb6b7f2b8ca40f425f66b504754048c9460329
Refactored all lockscreen notifications to go through new KeyguardStatusViewManager.
This is required to intercept messages originally intended for separate TextViews that
are now shown in a single view when showing the transport control view.
Refactor EmergencyCallButton to be handled by common code in KeyguardStatusViewManager.
First pass at LockScreenWidgetCallback for LockScreen "widgets" to send events back to LockScreen.
First pass at LockScreenWidgetInterface, which will be required of Views that want to be rendered on
LockScreen.
Added place-holder TransportControlView until the real one is ready and integrated it into GridLayouts.
Ensured emergencyCallButton is in all views, even if not shown since some devices may lock the user
out if certain criteria isn't met (missing SIM, etc).
Refactored layouts and removed keyguard_screen_status*.xml since layouts are all over the map and
no longer make good use of a shared layout for this.
Minor tweak to MultiWaveView to fix layout issues when placed in GridLayout where the measurement
was being calculated improperly.
Moved EmergencyCallButton to bottom of view where we can.
Removed unused Alpha keyboards from tablet password unlock layouts.
Removed unused views (status2, emergencyCallText screenLocked) from layouts and made common views have common names.
Fixed bug with MultiWave layout in landscape where array was shown in wrong orientation.
Separated clock colors for phones/tablets since they're now different.
Converted remaining phone layouts to use GridLayout.
Start routing audiomanager events to lockscreen views.
Move emergency call button handling to KeyguardStatusViewManager.
Change-Id: I480b0346cfe19aad316fea0c0aaabf8862693636
Used to grab immutables but now will copy the data so the result
is mutable and we don't get crashes.
bug:5051667
Change-Id: I0878bf8c58069055f528121541d1911f404cbe49
if activity handles orientation change
Make sure that bar content height and sizing/layout parameters are
properly updated after a configuration change.
Change-Id: I886df5cd9a655ba1bd34fab2b48e8b5be67fcc32
If the user has supplied a backup password in Settings, that password
is validated during the full backup process and is used as an encryption
key for encoding the backed-up data itself. This is the fundamental
mechanism whereby users can secure their data even against malicious
parties getting physical unlocked access to their device.
Technically the user-supplied password is not used as the encryption
key for the backed-up data itself. What is actually done is that a
random key is generated to use as the raw encryption key. THAT key,
in turn, is encrypted with the user-supplied password (after random
salting and key expansion with PBKDF2). The encrypted master key
and a checksum are stored in the backup header. At restore time,
the user supplies their password, which allows the system to decrypt
the master key, which in turn allows the decryption of the backup
data itself.
The checksum is part of the archive in order to permit validation
of the user-supplied password. The checksum is the result of running
the user-supplied password through PBKDF2 with a randomly selected
salt. At restore time, the proposed password is run through PBKDF2
with the salt described by the archive header. If the result does
not match the archive's stated checksum, then the user has supplied
the wrong decryption password.
Also, suppress backup consideration for a few packages whose
data is either nonexistent or inapplicable across devices or
factory reset operations.
Bug 4901637
Change-Id: Id0cc9d0fdfc046602b129f273d48e23b7a14df36
BluetoothDevice setName overwrite the locally cached remote name.
The changed name is saved in the local storage so that the change
is preserved over power cycle.
bug 5081605
Change-Id: I486966033828d153bfb1076a99e274c8a7f41636
bug:5008210
Redraw the WebTextView when the page swaps (and thus the background is updated)
That way it updates at (approximately) the same time as the page. In software
rendering, do as before.
Depends on following external/webkit change:
https://android-git.corp.google.com/g/#change,124606
Change-Id: I59d7266a49d0ba734efdb88fef5fafe68aecfbce
