Add the new Toolbar widget for use in app layouts.
ActionBar can now be used as a point of control for either a
traditional window decor action bar or for a Toolbar that appears
inline in an Activity's layout.
ToolbarActionBar is currently WIP.
Change-Id: I0da093e5645840f4fd032aa34efa0ae5f1825ff2
Rename the related user concept as profiles.
When returning profiles of a user include the
user as a profile of itself.
Change-Id: Id5d4f29017b7ca6844632ce643f10331ad733e1d
The Zygote class is now in com.android.internal.os. It is
responsible for the vast majority of work before and after
the call to fork(). It calls back into the Runtime via
the new dalvik.system.ZygoteHooks class to allow the Runtime
to perform pre fork cleanup and post fork initialization.
The native code in Zygote.cpp is a direct and straightforward
port of the existing code in art. Most differences are
superficial, for example :
- We use C style logging (ALOGE) instead of stream based
logging.
- We call env->FatalError() instead of using LOG(FATAL)
Change-Id: Ia101fb2af12d23894fe57e4134d2bc6d142e5059
* commit 'a780d9323b3ab9d0a06a9b8569164940d23405d4':
Fix bug #13727850 Input values are not visible when setting up the lockscreen... ...security(PIN/Passwor/Pattern).
...security(PIN/Passwor/Pattern).
- remove that hardcoded color
- enable passing a color for the Path lines
Change-Id: Ie40b15bf209f41ea2df16842a3e56ffc2020df65
Adds the TrustManager system service that allows
registering for changes to the trust status and
reporting events that are important to trust agents.
Bug: 13723878
Change-Id: I7d0d2ea86fd755702d31aa5d49cac038a6cd4301
This change reuses KeyguardViewMediator for the new Keyguard
implementation in status bar. KeyguardViewManager is replaced by
StatusBarKeyguardManager which handles adding the view, setting the
state etc. StatusBarWindowManager is introduced to managed the window
of the status bar, which has the logic of both the old Keyguard window
and the old status bar window. In the current implementation, Keyguard
gets displayed like it would be in the bouncer state, but that's likely
to change in the future. Also, setHidden in IKeyguardService is also
renamed to setOccluded, as the word hidden interferes with the
terminology when dismissing the Keyguard.
Bug: 13635952
Change-Id: I1c5d5a49d810d8532089f464cb2efe35e577f517
This change achieves a couple of things:
- Let Keyguard be a library, so we can use it in SystemUI.
- Introduce FLAG_KEYGUARD for windows and deprecate TYPE_KEYGUARD. Make
all the TYPE_KEYGUARD behaviour dependant on the flag.
- Implement a new KeyguardService in SystemUI, and bind that service
from PhoneWindowManager.
- Introduce BaseStatusBar.setKeyguardState and inflate
KeyguardSimpleHostView there and use FLAG_KEYGUARD for the window, such
that the status bar window essentially gets the Keyguard.
Bug: 13635952
Change-Id: I059d80d8b9b9818a778ab685f4672ea2694def63
vold will store password securely until KeyGuard requests it
and hands it on to KeyStore.
This is a revision of
https://googleplex-android-review.git.corp.google.com/#/c/418123/
which was reverted. It had two bugs in LockSettingsService.checkVoldPassword.
1) We were not checking password for null, which caused an exception
2) checkPattern/checkPassword return true if there is no saved pattern or password.
This leads to situations where we get true returned even when the password
doesn't match. Call the correct one based on what is there, not what vold
thinks ought to be there.
Bug: 12990752
Change-Id: I05315753387b1e508de5aa79b5a68ad7315791d4
- Improve wake lock work source updates to also update the current
history tag, in case the new work source gets recorded in the
history.
- Fix bug in recording radio active time that was not distributing
any time to apps.
- No longer hold a wake lock while dispatching data conn active call,
since it comes with its own timestamp.
- Fix issue where the top app was not being cleared while the screen
was off.
- Remove obsolete STATS_LAST stats type.
- Fix bug that was not clearing the total run time when resetting
the stats.
Change-Id: Iabe17a9edf34f762374ae09fcffb8a819cf72e30
Use the uptime while creating the battery stats history to
generate a new event indicating when the CPU is actually running.
We can do this in combination with the new event reporting when
the CPU comes awake, looking at the difference between the
uptime and elapsed time at that point to determine when it last
when to sleep.
Also use this information to generate a new set of aggregated
states, the uptime caused by each wake reason.
Finally use new radio down timestamp to adjust the times we
compute for radio use. Note that this information is not (yet)
being used to adjust how these are recorded in the history.
Change-Id: I723b3b526c8e7d64de0cac9d1193e04132d5a3e4
Migrate existing framework usages of Vibrator.vibrate to use
the new overload with an explicit stream hint. This prevents
them from being blocked by rules targeting the unspecified stream.
For calls that pass the existing appops check in VibrateService,
pass streamHint down to the input device vibrator so we don't lose
the signal, but leave it up to InputManager to decide what to do
with it - currently unused.
Change-Id: I65c944e4010edea29a412bf57d8d7d3b8098b746
Backup/restore now supports app widgets.
An application involved with app widgets, either hosting or publishing,
now has associated data in its backup dataset related to the state of
widget instantiation on the ancestral device. That data is processed
by the OS during restore so that the matching widget instances can be
"automatically" regenerated.
To take advantage of this facility, widget-using apps need to do two
things: first, implement a backup agent and store whatever widget
state they need to properly deal with them post-restore (e.g. the
widget instance size & location, for a host); and second, implement
handlers for new AppWidgetManager broadcasts that describe how to
translate ancestral-dataset widget id numbers to the post-restore
world. Note that a host or provider doesn't technically need to
store *any* data on its own via its agent; it just needs to opt in
to the backup/restore process by publishing an agent. The OS will
then store a small amount of data on behalf of each widget-savvy
app within the backup dataset, and act on that data at restore time.
The broadcasts are AppWidgetManager.ACTION_APPWIDGET_RESTORED and
ACTION_APPWIDGET_HOST_RESTORED, and have three associated extras:
EXTRA_APPWIDGET_OLD_IDS
EXTRA_APPWIDGET_IDS
EXTRA_HOST_ID [for the host-side broadcast]
The first two are same-sized arrays of integer widget IDs. The
_OLD_IDS values are the widget IDs as known to the ancestral device.
The _IDS array holds the corresponding widget IDs in the new post-
restore environment. The app should simply update the stored
widget IDs in its bookkeeping to the new values, and things are
off and running. The HOST_ID extra, as one might expect, is the
app-defined host ID value of the particular host instance which
has just been restored.
The broadcasts are sent following the conclusion of the overall
restore pass. This is because the restore might have occurred in a
tightly restricted lifecycle environment without content providers
or the package's custom Application class. The _RESTORED broadcast,
however, is always delivered into a normal application environment,
so that the app can use its content provider etc as expected.
*All* widget instances that were processed over the course of the
system restore are indicated in the _RESTORED broadcast, even if
the backing provider or host is not yet installed. The widget
participant is responsible for understanding that these are
promises that might be fulfilled later rather than necessarily
reflecting the immediate presentable widget state. (Remember
that following a cloud restore, apps may be installed piecemeal
over a lengthy period of time.) Telling the hosts up front
about all intended widget instances allows them to show placeholder
UI or similarly useful information rather than surprising the user
with piecemeal unexpected appearances.
The AppWidgetProvider helper class has been updated to add a new
callback, onRestored(...), invoked when the _RESTORED broadcast
is received. The call to onRestored() is immediately followed by
an invocation of onUpdate() for the affected widgets because
they will need to have their RemoteViews regenerated under the
new ID values.
Bug 10622506
Bug 10707117
Change-Id: Ie0007cdf809600b880d91989c00c3c3b8a4f988b
- Fix bug I introduced in handling wake lock changes where
we weren't iterating over the new work sources correctly.
- Fix bug in ActiveServices that would wtf too much.
- Prepare to start tracking uptime in the battery history.
Change-Id: Ia94316be51bc6eab7b02f214a5c40c08e99cc3b1
- Add new audio restriction layer to app-ops. Restrictions add
additional constraints to audio operations at a stream-level.
Restrictions do not affect the persistable state, and are purely
additive: that is, they can only impose additional contstraints, not
enable something that has already been disabled. Restrictions
also support a whitelisted set of exempt package names.
- Add new audio stream-level checks to app-ops.
- Implement a provisional OP_PLAY_AUDIO suppression to three
java entry points MediaPlayer, AudioTrack, & SoundPool.
- Enhance vibrator api to take stream information as an optional
hint - the constants correspond to AudioManager stream types.
OP_VIBRATE now supports the stream-level restriction check.
- Simplify Vibrator subclasses by adding default implementations
for two .vibrate calls.
- Migrate NoMan's zen-mode control to use the new app-ops
stream-level restriction mechanism.
Change-Id: Ifae8952647202f728cf1c73e881452660c704678
