The native side of the tracing code latches a copy of the tags from a
system property on first use. The Java-side tracing code latches a
copy of the native's copy during class init. The tracing code is
preloaded by the zygote, which means we get the flags during zygote
init and don't update them when we launch a new app.
This changes the Java sources to also defer initialization until
first use, so that newly-launched apps will use the current value
of the system property.
Bug 7323431
Change-Id: I7db048ec54345ae9565088a35c2e2b4c82f993fd
Define external storage as being isolated for each user, with the
caveat for shared OBB files. Also mention external storage
permissions.
Bug: 7384941
Change-Id: Ib156b5874c5587749d7bc066791e9e88d931b174
With FileInputStream, using assumption of bytes read (as
returned by read function) not matching buffer size as EOF is
not correct, we hit this when reading from /proc in some cases.
BufferedInputStream's behavior matches that assumption due to
its implementation.
Bug: 7342759
Change-Id: Ibb06dbe1fbe33f6f880524f7555ff5542889ea50
On some devices, vsync is delivered from the kernel to userspace
over a netlink socket via UEvent. The result is that a thread wakes
up, reads a message, creates a new String then searches it for matches
against a pattern on every single frame.
Reduce the overhead by performing the initial pattern matching in
native code.
Bug: 7326329
Change-Id: Icb22db1c38330694207bec1153840e0c06f502d6
...running as the foreground user
Add UserManager.isUserRunning() which is the public version of the
existing method on ActivityManager.
Also add UserManager.isUserRunningOrStopping() since that seems like
it will be useful.
And fix the internal function that returns the array of currently
running users to not include stopped users.
Change-Id: I84672fa8748fc027fd402729586b5603f640e498
7267494 Calendar is not syncing
Check for whether a content provider is dead before returning
it. This is kind-of a band-aid, but probably the right thing
to do; I'm just not sure exactly the full details of why this
problem is happening. Hopefully this "fixes" it, though I don't
have a way to repro to tell.
7212347 System power off dialog is only visible to user 0
Make it visible. Also turn on some battery debugging stuff and
clean it up so we can just keep it.
Change-Id: I5add25bf2a763c8dfe1df23bc5c753a9ea5d157a
Some of the BatteryService state was being locked
sometimes and it wasn't at all consistent.
Bug: 7158734
Change-Id: I46e75f66fde92c5a577a80a6bd99c9573066f3c1
Added a new WindowManager.LayoutParams inputFeatures flag
to disable automatic user activity behavior when an input
event is sent to a window.
Added a new WindowManager.LayoutParams field userActivityTimeout.
Bug: 7165399
Change-Id: I204eafa37ef26aacc2c52a1ba1ecce1eebb0e0d9
Clearly isolated the DreamManagerService and DreamController
responsibilities. DreamManagerService contains just enough logic to
manage the global synchronous behaviors. All of the asynchronous
behaviors are in DreamController.
Added a new PowerManager function called nap() to request the device
to start napping. If it is a good time to nap, then the
PowerManagerService will call startDream() on the DreamManagerService
to start dreaming.
Fixed a possible multi-user issue by explicitly tracking for
which user a dream service is being started and stopping dreams
when the current user changes. The user id is also passed to
bindService() to ensure that the dream has the right environment.
Fix interactions with docks and the UI mode manager. It is
important that we always send the ACTION_DOCK_EVENT broadcast
to the system so that it can configure audio routing and the like.
When docked, the UI mode manager starts a dock app if there is
one, otherwise it starts a dream.
This change resolves issues with dreams started for reasons other
than a user activity timeout.
Bug: 7204211
Change-Id: I3193cc8190982c0836319176fa2e9c4dcad9c01f
Change RingtonePlayer to open content:// Uris based on requesting
UserHandle. Grant SystemUI visibility to all emulated storage so
it can play ringtones for apps without READ_EXTERNAL_STORAGE.
Resolve canonical file:// Uris before passing out of source app,
replacing any /emulated_legacy/-style paths with user-specific
variant so they can be opened by SystemUI. Calling for RemoteViews,
Ringtones, and Notifications.
Bug: 7202982
Change-Id: Ibf0eca8df80c1486711144a7b648f464aadfe099
Since emulated external storage paths differ based on execution
context, carefully fix up paths for various use-cases:
1. When sending paths to DefaultContainerService, always scope
OBB paths as belonging to USER_OWNER.
2. When sending paths to vold, always build emulated storage paths
visible to root.
3. Always use the original untouched path when talking with apps.
Mount OBB containers using shared app GID, so that an app can read
the mount point across users.
Handle legacy paths like "/sdcard" by resolving the canonical path
before sending to MountService. Move tests to servicestests, and
add tests for new path generation logic.
Bug: 7212801
Change-Id: I078c52879cd08d9c8a52cc8c83ac7ced1e8035e7
Keep track of user creation and last logged-in time.
adb shell dumpsys users
User switcher shouldn't show users about to be removed.
No need to check for singleton for activities.
Bug: 7194894
Change-Id: Ic9a59ea5bd544920479e191d1a1e8a77f8b6ddcf
The current MTP kernel driver at /dev/mtp_usb is exclusive, meaning
only one process can have it open. In addition, each MTP session
with a desktop requires unique object IDs, which doesn't hold true
across users on the device.
To solve these two issues, when switching users we cycle the USB host
stack to disconnect both local and remote MTP connections, giving the
new user's media process a chance to claim /dev/mtp_usb, and causing
the desktop to initiate a new MTP session.
This change also allows BroadcastReceivers to registerReceiver()
allow retrieval of a current sticky broadcast. Adds a system property
to override maximum users. Removes MOUNTED broadcasts for secondary
users. Allows INTERACT_ACROSS_USERS to getCurrentUser().
Bug: 6925114
Change-Id: I02b4a1b535af95fb2142655887b6d15a8068d18a
Add a USER_INFO_CHANGED intent for lockscreen and quicksettings to use
to monitor changes to the user name or icon.
Bug: 7164040
Change-Id: Id6fb8b6d38ce04ccd02bbadcf0c10699783d6c03
7173152 API REVIEW: android.content.pm.PackageUserState
7172969 API REVIEW: android.app.PendingIntent
7172730 API REVIEW: android.content.Context
7172726 API REVIEW: android.manifest.permission
Change-Id: Iad470256d3b5ca5596487f6a699ec1871457c3b5
So that we don't abuse the setUserIcon() for reading. So the new method won't try
to create the file, only return it if it exists.
Change-Id: I7a81d3f1b29d14d37e71f531744ce39f21d827ac
For multi-user devices, switch to storing policy per-user instead of
per-app. Also watch for user added/removed broadcasts to clean up
policies and apply global restrictions.
Bug: 7121279
Change-Id: Ia7326bd0ebe0586fa4ec6d3a62f6313dc8814007
Now we can bind to just one instance of DCS, instead of requiring
one-per-user. This also means we can operate on otherwise-stopped
users.
Bug: 7003520
Change-Id: I4881e064ae8942907f6a02c6b868926223455cdc
When building external storage paths, always include user in path
to enable cross-user paths and aid debugging.
Each Zygote process continues to only have access to the appropriate
user-specific emulated storage through bind mounts. A second set of
mounts continue supporting legacy /sdcard-style paths. For example,
a process running as owner has these mount points:
/storage/emulated_legacy
/storage/emulated_legacy/Android/obb
/storage/emulated/0
/storage/emulated/obb
Since Environment is created before Zygote forks, we need to update
its internal paths after each process launches.
Bug: 7131382
Change-Id: I6f8c6971f2a8edfb415c14cb4ed05ff97e587a21
Use a shared app gid for each app across different users which allows
forward-locked applications to share the same APK file.
Change-Id: Ifecf51ee7865547117746f83e9733083d3dd5111
This change is the initial check in of the screen magnification
feature. This feature enables magnification of the screen via
global gestures (assuming it has been enabled from settings)
to allow a low vision user to efficiently use an Android device.
Interaction model:
1. Triple tap toggles permanent screen magnification which is magnifying
the area around the location of the triple tap. One can think of the
location of the triple tap as the center of the magnified viewport.
For example, a triple tap when not magnified would magnify the screen
and leave it in a magnified state. A triple tapping when magnified would
clear magnification and leave the screen in a not magnified state.
2. Triple tap and hold would magnify the screen if not magnified and enable
viewport dragging mode until the finger goes up. One can think of this
mode as a way to move the magnified viewport since the area around the
moving finger will be magnified to fit the screen. For example, if the
screen was not magnified and the user triple taps and holds the screen
would magnify and the viewport will follow the user's finger. When the
finger goes up the screen will clear zoom out. If the same user interaction
is performed when the screen is magnified, the viewport movement will
be the same but when the finger goes up the screen will stay magnified.
In other words, the initial magnified state is sticky.
3. Pinching with any number of additional fingers when viewport dragging
is enabled, i.e. the user triple tapped and holds, would adjust the
magnification scale which will become the current default magnification
scale. The next time the user magnifies the same magnification scale
would be used.
4. When in a permanent magnified state the user can use two or more fingers
to pan the viewport. Note that in this mode the content is panned as
opposed to the viewport dragging mode in which the viewport is moved.
5. When in a permanent magnified state the user can use three or more
fingers to change the magnification scale which will become the current
default magnification scale. The next time the user magnifies the same
magnification scale would be used.
6. The magnification scale will be persisted in settings and in the cloud.
Note: Since two fingers are used to pan the content in a permanently magnified
state no other two finger gestures in touch exploration or applications
will work unless the uses zooms out to normal state where all gestures
works as expected. This is an intentional tradeoff to allow efficient
panning since in a permanently magnified state this would be the dominant
action to be performed.
Design:
1. The window manager exposes APIs for setting accessibility transformation
which is a scale and offsets for X and Y axis. The window manager queries
the window policy for which windows will not be magnified. For example,
the IME windows and the navigation bar are not magnified including windows
that are attached to them.
2. The accessibility features such a screen magnification and touch
exploration are now impemented as a sequence of transformations on the
event stream. The accessibility manager service may request each
of these features or both. The behavior of the features is not changed
based on the fact that another one is enabled.
3. The screen magnifier keeps a viewport of the content that is magnified
which is surrounded by a glow in a magnified state. Interactions outside
of the viewport are delegated directly to the application without
interpretation. For example, a triple tap on the letter 'a' of the IME
would type three letters instead of toggling magnified state. The viewport
is updated on screen rotation and on window transitions. For example,
when the IME pops up the viewport shrinks.
4. The glow around the viewport is implemented as a special type of window
that does not take input focus, cannot be touched, is laid out in the
screen coordiates with width and height matching these of the screen.
When the magnified region changes the root view of the window draws the
hightlight but the size of the window does not change - unless a rotation
happens. All changes in the viewport size or showing or hiding it are
animated.
5. The viewport is encapsulated in a class that knows how to show,
hide, and resize the viewport - potentially animating that.
This class uses the new animation framework for animations.
6. The magnification is handled by a magnification controller that
keeps track of the current trnasformation to be applied to the screen
content and the desired such. If these two are not the same it is
responsibility of the magnification controller to reconcile them by
potentially animating the transition from one to the other.
7. A dipslay content observer wathces for winodw transitions, screen
rotations, and when a rectange on the screen has been reqeusted. This
class is responsible for handling interesting state changes such
as changing the viewport bounds on IME pop up or screen rotation,
panning the content to make a requested rectangle visible on the
screen, etc.
8. To implement viewport updates the window manger was updated with APIs
to watch for window transitions and when a rectangle has been requested
on the screen. These APIs are protected by a signature level permission.
Also a parcelable and poolable window info class has been added with
APIs for getting the window info given the window token. This enables
getting some useful information about a window. There APIs are also
signature protected.
bug:6795382
Change-Id: Iec93da8bf6376beebbd4f5167ab7723dc7d9bd00
