With this API, the system can determine whether a CA cert was
installed by the user or the user's DO/PO.
Bug: 32692748
Test: unit tests (see DevicePolicyManagerTest.java for invocation)
Test: cts-tradefed run cts-dev --module CtsDevicePolicyManagerTestCases
Change-Id: I3bcae5ac18ec2b110154184fc515df804fd73da6
This will prevent us from unnecessarily redoing calculation work
by loading the last caches on boot and shoving them down to
installd.
Bug: 33965858
Test: Framework services tests
Change-Id: Ie94e269aa72bceb1ebe87911eaa42e2d826c1123
- clear usesByOtherApps flag when the package is updated
- delete secondary dex usage data when the app data is destroyed
Test: runtest -x .../PackageDexUsageTests.java
runtest -x .../DexManagerTests.java
Bug: 32871170
Bug: 35381405
Change-Id: I3a249b9e8680e745fa678c7ce61b4ae764078fb9
mTask was a duplicate reference to the WindowContainer's parent. The
main benefit of this refenrece was type, as its callers require an
instance of type Task.
With the introduction of the method getTask, we can shift away from
this variable and instead directly cast the parent here. If the
window hierarchy changes in the future (such as AppWindowToken parent
types not being Task), we can re-evaluate and adjust how task is
returned.
Test: manual
Change-Id: Idd6bba1121056ed79745911efe838edfa685bbf2
Also defining an extra constant for widget preview which can be used by
developers to provide a snapshot of the widget with the pin request
Bug: 35811129
Test: All exisiting tests passing
for f in 1 2 3 4 5 6 7 8 9 10; do \
adb shell am instrument -e class com.android.server.pm.ShortcutManagerTest$f \
-w com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner; \
done;
adb shell am instrument -e class com.android.server.appwidget.AppWidgetServiceImplTest \
-w com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Change-Id: Id854bd28468a5bf0416ff1a1b19c44d850016f32
Previously it was possible for an AppWindowToken to be removed while
on the closing apps list, used in transition animations. During these
transitions, the visibility of the token is modified. Since
visibility relies on the WindowContainer parent, a
NullPointerException would occur.
This changelist addresses the issue by making sure to remove any
AppWindowToken from this list when its task is set to null.
Change-Id: Id9234822b228f4658f04d42ac0fe7b49ded6f5a1
Fixes: 35352214
Test: manual (primarily code inspection)
Two new attributes for <uses-permission>: android:requiredFeature and
android:requiredNotFeature.
Also update aapt to include this information in badging:
uses-permission: name='android.content.cts.REQUIRED_NOT_FEATURE_UNDEFINED' requiredNotFeature='android.software.cts.undefined'
uses-permission: name='android.content.cts.REQUIRED_MULTI_DENY' requiredFeature='android.software.cts.undefined' requiredNotFeature='android.software.cts'
Test: new PermissionFeatureTest suite.
Change-Id: Icc1f815a4675ae9dd2cb7f61730ab28b5c11228a
This field allows Network Score Services to pass an alternate label for
the scorer.
Bug: 35848510
Test: runtest --path
frameworks/base/services/tests/servicestests/src/com/android/server/NetworkScorerAppManagerTest.java
runtest --path
frameworks/base/services/tests/servicestests/src/com/android/server/NetworkScoreServiceTest.java
Change-Id: Ic28671c1663bd08b2406045d20c150a209d56054
This seq counter is associated with the process state in UidRecord
and will be incremented whenever the uid state is going from
background to foreground or vice versa.
Bug: 27803922
Test: runtest -c com.android.server.am.ActivityManagerServiceTest frameworks-services
Change-Id: I1183d929bc7e0b2c9912de3822eb344d2bb0dcf7
Adapts all notifications used by system services to use channels.
Channels are initialized by SystemServer after the NotificationService
has started.
Test: runtest systemui-notification
Change-Id: I25c45293b786adb57787aeab4c2613c9d7c89dab
Various animation adjustment logic will directly set mAnimLayer
outside of WindowLayerController. If we end up setting this layer
very high, we can end up moving it above the special windows
collected in WindowLayersController.
Bug: 33702491
Bug: 35396882
Test: bit FrameworksServicesTests:com.android.server.wm.WindowTokenTests
Change-Id: I9850529ecd6f0067bc24421515b39b645885a3ec
This replaces some of the threading shenanigans done to get this
working with the regular PackageManager call. By swapping this
out, we can get results faster, using less power, and with a
simpler implementation and testing strategy.
Bug: 35807386
Test: FrameworkServicesTest
Change-Id: Ib94fd7eba838b5e728f8f2615bcb4d9c82f21885
Both inherit from package private BaseParceledListSlice.
This is still bad, but it's not as bad. The existing code that uses
this can just do Foo.bar().getList() now instead of having to marshal
to and from an oddball type at either end as well.
In the longer term ParceledListSlice<> should be eliminated, but it's
not clear how far into the future that is going to happen.
Test: runtest -x services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerTest.java
Test: runtest -x core/tests/coretests/src/android/content/pm/ParceledListSliceTest.java
Change-Id: Ie69b96b5215d6e04990f6d31345772cdfee21d78
Window Manager currently places the IME above the highest window
that can possibly be using the IME. While this method works for
most cases, it does cause some animation jank if the window making
the IME visible is below an other window that could possibly make
the IME visible, but isn't. When this happens the IME is displayed
on-top of which we don't want since the top app isn't making the
IME visible.
We now rely on a strong signal from the input method manager service
WMS.updateInputMethodWindowStatus() to depend which window is actually
using the IME so the window manager can z-order things correctly.
Fixes: 31559891
Test: bit FrameworksServicesTests:com.android.server.wm.DisplayContentTests
Change-Id: I524aa9dbeb764aac15034a13adf9381304c38fa6
Clean up the implementation of boolean constraints so that
they are in a single flags value that gets propagated all of
the way from JobInfo.Builder in to the JobStatus. Much simpler
and easier to add new constraints!
Also introduce some shell commands to make it easier to write
tests against the job scheduler (and other things tied to power).
One of the big things here is that there is a new sequence number
that propagates with battery updates, which we can look for in
the job scheduler to determine when a change the test has made
to battery state has actually gotten applied, to allow it to
safely and minimally wait until executing the condition being
tested.
Test: New BatteryConstraintTest suite added.
Change-Id: I11076d90b80ec25ee604c29b6a6dc2337fd867ce
Decoupled the app idle book-keeping from usage stats lock, by
introducing an mAppIdleLock. This is used for all state related
to app idle. In some cases, the locks will be nested, with
mLock being acquired first and then mAppIdleLock.
This should fix the situation where a rollover, which writes to
disk and could take several seconds when the system is swamped,
like when the device just came out of idle and the screen was
turned on (like this run-on sentence), causes calls from other
services for app-idle status to be blocked. This was resulting
in a long time to turn on the screen.
Also fixed a dump indentation issue.
Bug: 34627115
Bug: 34961340
Test: Manual, force into idle, increased rollover frequency,
and tested screen on time.
Change-Id: Ie8b44e6f07f82d8a31f1b733a403dd9b6dc310f6
These were never part of any public API level, so apps should never
have been using them.
Test: builds, boots
Bug: 31241513
Change-Id: I4fc8f5c325da56694a5db98acc995a22d4947805
High level changes to NetworkScorerAppManager:
* Implemented getAllValidScorers() and removed the old
config-based discovery code.
* Implemented setActiveScorer() to persist its given package
name to Settings if it represents a valid network
recommendation app.
* Added a new method that reverts the setting back to the
configured default if the current setting represents an
invalid app.
High level changes to NetworkScoreService:
* Updated the PackageMonitor to only watch a single package.
* Moved most of the startup logic to onUserUnlocked() so we
don't have to worry about whether or not the device is encrypted
when querying the PackageManager.
* The PackageMonitor is only registered/unregistered when the
package it's watching changes.
Test: runtest frameworks-services -c com.android.server.NetworkScorerAppManagerTest
Test: runtest frameworks-services -c com.android.server.NetworkScoreServiceTest
Bug: 35095406
Change-Id: Ib32aca72dac4b831a64ceb3cd5c31e8fa2f61396
NetworkScorerAppManager is only used internally by the
NetworkScoreService and no longer needs to be part of core.
Extracted its inner class, NetworkScorerAppData, into a top-level
class and left it in android.net as it's used as part of the
NetworkScoreManager API.
Test: runtest frameworks-services -c com.android.server.NetworkScorerAppManagerTest
Test: runtest frameworks-services -c com.android.server.NetworkScoreServiceTest
Bug: 35095406
Change-Id: I201f081e05d0a909b4ae3142b63afc3e21548f77
Hand over ownership of overlays to OverlayManagerService.
Changes to a package's overlays are propagated using the activity life
cycle. Affected activities will be recreated as needed. This provides a
well-defined point to modify an application's assets while the
application is paused.
Consolidate how overlays targeting the system and overlays targeting
regular applications are handled. Previously, system overlays were
handled as a special case. Now, everything is handled identically. As a
side effect, the call to idmap --scan during Zygote boot has become
obsolete and is removed.
Information on what overlays to use is recorded in
ApplicationInfo.resourceDirs. The PackageManagerService is responsible
for the creation of ApplicationInfo objects. The OverlayManagerService
is responsible for informing the PackageManagerService in advance about
what resourceDirs to use.
When launching an application, the ApplicationInfo is already populated
with up-to-date information about overlays.
When enabling or disabling an overlay for a running application, the
OverlayManagerService first notifies the PackageManagerService about the
updated resourceDirs. It then tells the ActivityManagerService to push
the new ApplicationInfo object to the application's ActivityThread.
Finally the application requests its ResourcesManager to create new
ResourcesImpl objects based on the updated paths.
Change-Id: Ib8afa05ccab4e2db558f89ce4423983c086bb61a
Co-authored-by: Martin Wallgren <martin.wallgren@sonymobile.com>
Signed-off-by: Zoran Jovanovic <zoran.jovanovic@sonymobile.com>
Bug: 31052947
Test: run tests from 'OMS: tests for OverlayManagerService'