Move implementation of wificond to frameworks/base (android.net.wifi)
in prepration for making into a public API (which will be a wrapper
around the AIDL).
Bug: 140062898
Test: atest com.android.server.wifi
Test: atest android.net.wifi
Test: associates, soft AP client information received correctly
Change-Id: I3c5ede95d0421a1e00078e0316e9a2e751156f3e
With the newly added flag for Settings developer options, which is now
used to change the state of FUSE, PROP_FUSE now acts as the snapshot
feature flag for the current boot.
Also, on a reboot PROP_FUSE_SNAPSHOT was always set to PROP_FUSE or
the default value (false) if PROP_FUSE is not set.
Since PROP_FUSE now replaces PROP_FUSE_SNAPSHOT, it always needs to be
set to some value after a reboot. PROP_FUSE is initialised to the default
value (false) only once, after that it takes value from the latest
changed flag.
Bug: 145391093
Test: Manual (adb shell ls /sdcard works)
Test: atest AdoptableHostTest
Change-Id: I3abb8690a50f542b2567c495ef9942a643be457d
Properly define the constant for requesting the use of device individual
attestation certificate and use it in AttestationUtils.
This lets callers to DevicePolicyManager.generateKeyPair request the use
of device-unique attestation certificate, on Keymaster implementations
that support this.
Bug: 140193672
Bug: 136494773
Test: atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testKeyManagement
Change-Id: I74de89e4c121a27b0495dcb99b0775445c3d4eaf
FULL and PROFILE user types now have their default restrictions
delineated in UserTypeFactory. The restrictions for these user types can
be customized in config_user_types, along with the other user type
customization.
Note: even though FULL user types can now be customized, the only
supported customization is user restrictions. Moreover, new FULL user
types cannot be defined.
This cl also has the following repercussions:
-When a user is created (but not yet started), the applied restrictions
are not propagated as an update (prior to this, the restrictions for new
users - other than guest - were set via setUserRestriction, which did
more than just store the data). When the user is started, the
restrictions will still be propagated.
-When a user is created via adb, its default restrictions are applied.
Previously this was not the case except for guest users.
-When an Admin user is created/set, it is now the callers responsibility to
adjust its restrictions. UserManager will no longer automatically remove
the DISALLOW_SMS/DISALLOW_OUTGOING_CALLS restrictions for Admins.
Also note that Restricted Users have additional hardcoded restrictions,
indepent of this cl.
Test: atest UserManagerServiceUserTypeTest
Test: atest UserManagerTest
Bug: 142482943
Bug: 143491938
Change-Id: Idfec610da871aea2bc7109d11d1eb9a957e080a4
The EffectiveProvider wrapper is incorrect. The fact that ComponentResolver
mutates the Provider instance is a required behavior, otherwise the authority
doesn't get propagated.
This causes queries to fail because the EffectiveProvider thinks the authority
should be null. This change reverts to the original behavior pre-refactor,
directly mutating the ParsedProvider instance.
Fixing this mutation will have to wait for a followup, unfortunately.
Bug: 146072648
Test: run test in linked bug that queries content providers
Test: manual verified failing case
Change-Id: Ief960bec3692d60e823a60734c2196ee6caeff7a
Enables SystemUI to create/position its own ui elements.
First of all, this adds, to WM, the concept of a ShellRoot
which represents a piece of the hierarchy that a client shell can
do whatever it needs with. For now, multiple of these roots can
be registered at various "levels" (which correspond to window
types for now). This is needed because not everything will live
in this piece of the hierarchy, so handling z-order will still
be a shared effort between the Shell and WM for a while.
On the SystemUI side, a new Dependency called SystemWindows
provides simplistic window management for these system-ui
windows via WindowlessWindowManagers per-display-per-layer.
The benefit of this is that manipulation of these windows lives
entirely in SystemUI making synchronization easier and making
it possible to move a lot of the special handling code out
of wm (eg. DOCK_DIVIDER). As a result, SystemUI becomes
more customizable and WM becomes simpler.
Early clients of this are going to be display-level IME
handling and Split-screen.
Bug: 133381284
Test: manual test after later CLs
Change-Id: I1602d9b9b69d38b9ff15806e509cc8128c837748
Exposed the @hide constants from BatteryStats used in
BatteryStatsManager as @SystemApi.
Bug: 146009681
Test: Compiles
Change-Id: If1c798181b4c160453c7775bd6bb779b9e81a6ee
Test: boot the system, see log entries like this:
4030 E Binder : Outgoing transactions from this process must be FLAG_ONEWAY
Change-Id: Ie1b3c76ec08aecc706a5edc5a6d2b4b946895ed9
this change waits to apply ui changes after screen off
battery manager sends updates and continuously updates the ui mode
this change also applies external changes to ui configurations when
the mode is actually changed. this resolves some perfromance regression
issues
Fixes: 145694649
Fixes: 145161355
Fixes: 145776479
Test: atest UiModeManagerService
Change-Id: Ib769df4302d1c09166e2dc456b8ced35daa4d0b7
Merged-In: Ib769df4302d1c09166e2dc456b8ced35daa4d0b7
this change waits to apply ui changes after screen off
battery manager sends updates and continuously updates the ui mode
this change also applies external changes to ui configurations when
the mode is actually changed. this resolves some perfromance regression
issues
Fixes: 145694649
Fixes: 145161355
Fixes: 145776479
Test: atest UiModeManagerService
Change-Id: Ib769df4302d1c09166e2dc456b8ced35daa4d0b7
Merged-In: Ib769df4302d1c09166e2dc456b8ced35daa4d0b7
