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
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
Teach NetworkPolicy limits to "snooze" when requested by user, and
notify with both dialog and notification. Register for network alerts
through NMS to trigger updates immediately instead of waiting for
next stats update.
Enforce that all NetworkPolicy are unique on a template basis, and
move SCREEN_ON/OFF broadcasts to background thread. Launch SystemUI
and Settings directly instead of using actions, and include full
NetworkTemplate in extras.
Tests to verify notification and snooze behavior.
Bug: 5057979, 5023579, 4723336, 5045721
Change-Id: I03724beff94a7c0547cb5220431ba8d4cd44d077
Otherwise the value would be left at zero since we are inserting
the database record before writing the file
Bug: 5064246
Change-Id: I54be6ff14a7f170994aaf586aaddb06c5b746e89
Signed-off-by: Mike Lockwood <lockwood@android.com>
The built-in ZipFile class was quite a long time to find an unpack
libraries. Move everything to using the libutils ZipFileRO class that
goes quite a bit faster. Initial measurements are 6 times faster than
the Java code.
Also, read files off the disk and compare their CRC against the APK's
CRC to see if we need to write the new file to disk. This also cuts down
the bootup time by up to a second per APK that has native files.
Change-Id: Ic464a7969a17368fb6a6b81d026888c4136c7603
That is, only play it when the device is running on battery
and the remaining charge level descends into a new
low-battery regime:
* when the device hits the first threshold, for example 15%
(the dialog is first shown at this time)
* when the device hits the second threshold, e.g. 4% (the
dialog will be redisplayed if necessary)
* when the device has been charging but AC power is removed,
returning the device to a low-battery regime (the dialog
will be redisplayed if necessary)
The sound will no longer be replayed as the battery level
descends within these regimes (say, 4% --> 3%).
Bug: 4981280
Change-Id: I049d60f39ae556241a23f8664e61be3d70d937e5
The signal strength, network type & flow indicator, and
battery have all been moved out of the policy and into the
status bar implementation itself, mirroring the change on
tablets. This means that they no longer use status bar icon
slots but instead are bespoke layouts and views.
GPS has also been removed and will return as a notification
(again, as was done in the Honeycomb tablet UI).
Bug: 4691638
Change-Id: I60df4871209b64209bfc5b3bf398651cc2e77b24
The input reader needs this information so that it knows how to
interpolate touches on an external touch screen.
Changed Display so that it asks the WindowManager what the real
display size is (as opposed to the raw display size). This means
it now takes into the forced display size set by
adb shell am display-size.
Replaced all calls to getRealWidth() / getRealHeight() /
getRealMetrics() in the WindowManager and replaced them with direct
usages of the mCurDisplayWidth / mCurDisplayHeight so that the WM
doesn't end up making a reentrant Binder call into itself.
Fixed the table status bar HeightReceiver so that it updates the
height on all configuration changes since it is possible that the
display size changed independently of an external HDMI display
being plugged / unplugged.
Improved the Display class documentation to make the distinctions
betweeen the various sizes clearer.
Change-Id: I3f75de559d3ebffed532ab46c4ae52c5e7f1da2b
The scroll view was grabbing the gesture as soon as its dy
crossed the scroller's own slop threshold. Once we detect a
horizontal swipe-to-clear we request that the scroller no
longer activate until the gesture is over.
Bug: 4998677
Change-Id: If916fc00d155516e0e4bfe8c2df19827a2f16fe6
1. Added content description to pretty much all animals
in the zoo including buttons in the navigation bar,
notifications and status icons for battery, signal,
data, etc.
2. Rectored to avoid ovelaying views since they block
touch exploratino. In general overlaying views
cause trouble for touch exploration and accessibility
in general.
3. Avoid sending accessibility events in case the user is
touching outside of the StatauBAr panels to avoid
confusion.
4. Added records to accessibility events in the places where
this would help the presentation. So the event comes from
a given "leaf" view and its predecessor is adding a record
to the event for itself to provide more cotext. It is up
to the accessiiblity service to choose how to present that.
bug:4686943
Change-Id: I1c1bd123d828fb10911bca92130e9a05c1f020b3
There's always going to be some amount of visual noise when
notifications change order, and this can happen any time a
notification changes its "when" field (as is the case for
download progress bars). But in HC we added an optimization
that will reuse the current row if the download is the last
item in the list (so a fresher "when" will still put it at
the end), and that optimization is re-applied here.
Now, if you have multiple notifications all competing for
the top spot, I can't help you. But we had that problem
before (it just wasn't as egregious because we didn't have
the shiny animations).
Bug: 4971404
Change-Id: I5bcc905bdb19a8eb5b4494a6ba9825b4d5373caa
Implemented different silent mode behaviors for tablets and phones.
The behavior inherited from Honeycomb was for tablets only and
was muting music in silent mode.
Change-Id: Ib053e7b70ca02190debc87648ab8a163f9d39577
When items were removed from the Recents list, the removeViewInLayout()
method was being called instead of removeView(). This avoided proper
layout and invalidation from occurring, which sometimes resulted in
detritus on the screen since the framework wasn't updating the area
last occupied by the item.
Change-Id: I43132d06df1714f00c399d34908e4d6dd0a8d5c6
Adds selection overlay to recents to comply with UX design.
Adds longpress popup for removal and inspection of items.
Change-Id: Ic23c3f135b6ed107cc5156505d8f163daa94c52e
