We let the user know when he turns off Wi-Fi that scans will continue to
be available.
User has the option to turn off the dialog and not receive this in the future.
Bug: 8141918
Change-Id: I115ce2ac57125b8ffbb34245dc25effd4b3bebb0
Adds the ability for apps to export some restrictions. The restrictions
are presented in Settings based on the restriction type. The user's
selections are stored by UserManagerService and provided to the
target user's application as a list of RestrictionEntry objects which
contain the key, value(s).
Also introduce a manifest entry for system apps to request that the
app be automatically installed in all users, so that they cannot be
deselected by the owner user.
Shared account filtering for non-whitelisted apps.
Change-Id: I15b741e3c0f3448883cb364c130783f1f6ea7ce6
The HeartbeatHandler for the System Server Watchdog has been running
on the wrong thread due to a race condition in initialization. It's
designed to run on ServerThread, so that it can catch lockups in the
main looper of the System Server. It has been running on
ActivityManagerThread instead, so it does not detect lockups on the
ServerThread as it should.
ActivityManagerService is calling Watchdog.getInstance() before
ServerThread calls Watchdog.getInstance().init(), so the handler is
being bound to the ActivityManagerThread instead of the ServerThread.
Explicitly bind HeartbeatHandler to ServerThread, so that the Watchdog
catches lockups on this critical thread.
Change-Id: Iccb184ac3adb817feb86ed4ee0e50e443bf74636
Don't automatically grant all normal/dangerous permissions. Instead,
check the value of requestedPermissionsRequired to see if it's required.
If the permission is not required, then only grant it if the permission
was previously granted to the application.
Change-Id: I86b1fae530c006d353f9fa22137598bc88253805
The root cause is:
There is a defect in window manager service: When a new
activity that can be ime target is added into window manager
but the Z order of input method window don't need to be
changed, then the target app token of input method window
would not be updated to new one. This defect may cause that
the layer of input method window is calculated incorrectly.
The solution:
Correct the target app token for input method window.
Change-Id: I008311e3c9b1cf5fc320b614d8675c183c506d50
Currently, NetworkManagementService only catches RemoteExceptions
when calling the BaseNetworkObserver notification methods (e.g.,
interfaceStatusChanged). However, if the observer is in the same
process, unchecked exceptions can occur as well.
When this happens, finishBroadcast does not get called, and no
further notifications can be sent, because any attempt to do so
fails with a "beginBroadcast() called while already in a
broadcast" exception.
Fix this by catching RuntimeException as well.
Bug: 8397534
Bug: 8276725
Change-Id: Icd6f32128707244978943c48a9ea3a2b952a2957
- Create new classes for Stacks on WindowManager.
- Stop using DisplayContent methods and members:
addAppToken(),
removeAppToken(),
setAppTaskId(),
removeTask(),
mTaskIdToDisplayContents,
mTaskIdToTask.
- Start using WindowManagerService.createTask().
- Establish hierarchy of references: AppWindowToken=>Task=>
TaskStack=>StackBox=>DisplayContent.
- Clean up StackBox, TaskStack, and Task.
Change-Id: I798990aa7966784d22f4a43822087d8bb0404dd6
BadTokenException is a normal consequence of swapping IMEs while there
is a DO_SHOW_SOFT_INPUT message in the IIMethodWrapper queue. This
race condition cannot be avoided without an unacceptable lock down of
InputMethodManagerService.
Fixes bug 8387663.
Fixes bug 8263462.
Change-Id: I2c21573cf972145ab08e66604cdb9344139a3f31
1. Add a Nat464Xlat service that ConnectivityService can use
to start and stop clat. When clat is started, the service
waits for the clat interface to come up and then calls
ConnectivityService to add the appropriate routes.
2. Make ConnectivityService start clat when an IPv6-only mobile
interface is connected. We only support clat on mobile for
now.
3. Make tethering use the interface that has the IPv4 default
route insted of using the base interface of the
LinkProperties. This allows us to tether to a stacked
interface, which is needed for tethering with 464xlat.
Bug: 8276725
Change-Id: I24480af69ee280f504399062638af0836a56268e
Currently, ConnectivityService adds and removes routes to/from
the routing table only based on the LinkProperties's routes.
Make it update routes based on the stacked links as well.
Bug: 8276725
Change-Id: I9a2adf537af5a04de0aaab3780afbcc3bb5c6acb
