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
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
inverse-bar themes
Add the actionBarWidgetTheme theme attribute. This lets a theme
specify a wrapper theme that can be used to create views that will
end up in the action bar so that the rest of the code can ignore
differences in contrast. (e.g. the inverse action bar themes.)
Apps can use ActionBar#getThemedContext() to obtain a Context with a
proper theme for views that will end up in the action
bar. MenuInflaters generated by Activities will automatically use this
to properly theme inflated action views.
Change-Id: Ib28c82bf47c25d446cca2a63f617b8a4a0afa6b2
1. Update the database creation/upgrade code to take care of the new setting
to enable touch exploration.
2. Made the tocuh exploration settings persistent to the cloud.
Change-Id: Ie24e9184b4a21869432d11d207cb6464fadbac3b
Since "restrict background" depends on active networks, separate its
definition from setBackgroundDataSetting().
Bug: 4979025
Change-Id: I12bfe3a2e606375b39c67706270caa7a1bb0214e
onCreateOptionsMenu
Initialize menu presenters early enough to respond to expanding an
action view within onCreateOptionsMenu.
Have SearchView show the IME as an async post to handle attempts to
show it while the UI is still in initial setup.
Change-Id: I77f3a94ed4397737edb5a7a15bf54993b6723f5e
This was added to simplify some logic in the provider and app, as
there are places that can simply compare the concatenation of the
account type and data set.
Also added a DATA_SET extra for contact creation, to allow for this
value to be passed around via intents.
Bug 5077096
Change-Id: Ia0634cfcf4590fd90ccb5cb99360c38c86f08d25
NetworkManagementService is reading stats /proc/ files, which are now
being protected by GID.
Bug: 5087530
Change-Id: I29b35a97ab621999544b6acc8ad4cf72ee053b79
