Previously DMAgent would apply these lockdowns before/
after setting the matching user restrictions.
Bug: 16701642
Bug: 16945830
Bug: 16944983
Change-Id: Ib4f7145055687f12408d6ccacd8e6380406a32b2
If an unlock handler already exists, we need to try
to update the tech mask for it. Don't permit unlock
handlers with no tech mask.
Bug: 17054331
Change-Id: I54a885d28bdd8ce41d8646d968621c7d6abc9387
- Persist the entire exit condition instead of only the id.
- Make downtime a proper condition provider (similar to the
existing countdown provider for time-based conditions)
- Move all downtime-related items out of ZenModeHelper and
into the new condition provider.
- Reevaluate downtime more often, when any of its inputs change.
- Make sure downtime appears as an available condition in the
condition panel when applicable.
Bug:16296125
Bug:16211189
Bug:17031767
Change-Id: I1d8269a4e6fe170ce776bf932dbbdfb29dd25dd7
This reverts commit 87efe74e092236c372d3b6909009641123aa416a.
This should be fine now with all the dependency CLs +2-ed
Change-Id: I96ad14ad5ff81e6b5391035cb6c5a62339c6cc40
We set the system_server classpath in the environment
(like we do with BOOTCLASSPATH). After the zygote forks
the system_server, we dexopt the classpath (if needed)
and then launch the system server with the correct
PathClassLoader. This needed several small / medium
refactorings :
- The logic for connecting to installd is now in a separate
class and belongs in the system_server.
- SystemService / SystemServiceManager have now moved to
classes.jar. They are only used from there, and since they
use Class.forName, we want them to be loaded by the
system_server classloader, and not the bootclassloader.
- BootReceiver now moves to frameworks.jar, because it is
used by ActivityThread and friends.
bug: 16555230
Change-Id: Ic84f0b2baf611eeedff6d123cb7191bb0259e600
Move API to KeyguardManager.
Fixes bug 17006280
This reverts commit 2e7beadedeb7d41d8c2d1cc62956bdd9f5081d26.
Change-Id: I7b58bb4d9db828028c1021f17b01745c5ec2161e
Conflicts:
core/java/android/content/Intent.java
Add system trace events for several interesting points during the
loading of the WebView APK so we can measure how much each part
contributes to startup time.
Bug: 16870075
Change-Id: Iadfd1881faea0377fa01313dddabb1d030962c5f
This addresses a TODO and also makes it possible to create
routes to destinations that are not valid LinkAddresses, such as
multicast addresses.
Bug: 16875580
Change-Id: Id4c77b00dc3064bf27d78cdcbbe035e645748cfe
If an app is installed with an ABI override (adb install -r --abi)
we should remember this so that we don't revert to the scan derived
ABI on the next reboot.
bug: 16476618
Change-Id: I6085bc0099eb613dd9d3b07113c7c13859780697
Warnings of redundant calls of #updateCursorAnchorInfo should be
suppressed at least until such redundant calls from
android.widget.Editor are addressed.
BUG: 16996008
Change-Id: I62b6acdab06178520473bd53e56e2cfb62fb17be
Bug 16959262
Views that hadn't animated in during the enter transition were
being stripped from the exit transition. This caused them to
blink in as the enter transition was canceled.
This pauses the entering transition so that the view positions
are properly captured for the exit transition and aren't stripped.
Change-Id: I39cc94ed3bf92a51f8c5fe741f0aa5456b704bf0
This addresses b/16486549.
This change updates public documentation to specify the behavior of
LeadingMarginSpan2s. This change specifies what happens when a
LeadingMarginSpan2 is combined with other LeadingMarginSpans. This
behavior was not previously documented.
LeadingMarginSpan2s specify the number of lines used for the leading
margin. When laying out and rendering, for all LeadingMarginSpans, the
first line margin is applied for the number of lines specified by the
LeadingMarginSpan2.
Previously, this behavior was slightly buggy -- the LeadingMarginSpan2
affected all LeadingMarginSpans when laying out text, but not when
rendering.
This change is designed to cause the least amount of breakage in
existing code while achieving consistency with the way
LeadingMarginSpan2 is handled in layout and drawing.
For the most common use of LeadingMarginSpan2 -- getting a multi-line
first margin in the first paragraph of text in a layout -- this should
cause no change in behavior. For any other uses, the old (buggy)
implementation most likely did not exhibit correct behavior to begin
with, so developers were most likely not relying on that functionality.
Change-Id: I6f69df09c0130e703458e65bf3eaac4a905df56e
