Added some code to the activity manager to keep track of
services that are launching and limit the number that can
be launched concurrently. This only comes into play under
specific circumstances: when the service launch is a background
request (so timing is not important) and its process is not
already running at a high priority.
In this case, we have a list of services that are currently
launching and when that gets too big we start delaying the
launch of future services until currently launching ones are
finished.
There are some important tuning parameters for this: how many
background services we allow to launch concurrently (currently
1 on low-ram devices, 3 on other devices), and how long we
wait for a background service to run before consider it to be
a more long-running service and go on to the next pending
launch (currently set to 15 seconds).
Also while in here, did some cleanup of the service code:
- A little refactoring to make per-user data cleaner.
- Switch to ArrayMap.
Change-Id: I09f372eb5e0f81a8de7c64f8320af41e84b90aa3
Before:
4539 does not have permission:android.permission.CLEAR_APP_USER_DATA to clear datafor process:com.android.chrome
After:
PID 4539 does not have permission android.permission.CLEAR_APP_USER_DATA to clear data of package com.android.chrome
Change-Id: Ic466decb050e4fa7f3fee4098c4f2abdc6cedf5c
1. Removed unneeded code in Resolution that was storing its
label as resource and package name. We do not have predefined
resolutions, therefore we always persist the label.
2. Renamed the print attribute margins to minMargins to reflect
that these are the minimal margins the printer support. Updated
the docs as well.
3. Renamed the create method of all builder to build.
bug:10727487
Change-Id: Ie72ab8aaa5215b8bd2853885011b3b4efa4deb2e
As part of the power manager rewrite in JB MR1, we removed the ability
for the phone to suspend with positive proximity because it was not
clear that the proximity sensor was always correctly registered as
a wake-up source. The sensor service itself does not contain any
code to manage wake-ups. Therefore proximity sensor based wake-up
relies on the sensor driver acquiring a timed wake lock when the
sensor reports a negative result. This behavior is not very well
defined in the sensor HAL so there is a chance that it will not
work reliably on all devices.
This change adds a new config.xml resource to specify whether the
device should be allowed to suspend when the screen is off due to
positive proximity. Devices that support this feature should set
the "config_suspendWhenScreenOffDueToProximity" resource to "true" in
their resource overlays. The feature is disabled by default.
Bug: 9760828
Change-Id: Ic65ab7df0357271b133e2e44f5e35e7756e1e9e0
If the user selects some print options from the dialog and then
changes the printer to one that has the same capabilities the
selections in the UI should not change.
bug:10631856
Change-Id: Ia76ce58c446815e3498d2f4b4739dee62d11d96a
AppOps stats are used to populate the "apps recently using location"
list in settings->location. There is no reason to show Android OS
in that list simply because of internal location requests supporting
other clients.
Change-Id: I6908aa63deb19d22733b8d9cdae6ea5dbbea55e0
1. Now after a print service crashes we are bringing it to the same
state of its lifecycle. For example, if a service does a discovery
and crashes we recreate the discovery session call the start
discovery method and so on.
2. Turned off debugging logs since we have fully fledged state dump.
bug:10697779
Change-Id: Id790537461428e96b197eef12258996bda2bd1ce
- JNI exception accessing a geofence method with wrong signature
- FlpHardwareProvider exception when the monitoring status contains no location information
Bug: 10691492
Change-Id: I1959712912af712dc9dc344f20afd1112da46efc
- LocationManager.isProviderEnabled() no longer throws SecurityException:
the caller could already circumvent the permission check by calling
Secure.isLocationProviderEnabled()
Change-Id: I5abd04264299671ed35ce4594b5be46d86378767
Reverts extension to assist context API to query
foreground services for assist context data.
Also hides Intent.ACTION_VOICE_ASSIST because
nobody's actually using it yet.
Bug: 10461702
Change-Id: Idf6836adc659b434e11ebb2b98e8b814c94a7227
netd now tracks statistics for tethered interfaces across tethering
sessions, so switch to asking for all tethering stats. (Currently
we're double-counting all tethering data, ever since it started
tracking across sessions.)
Also catch OOME to handle corrupt stats files, which we then dump to
DropBox and then start over.
Bug: 5868832, 9796109
Change-Id: I2eb2a1bf01b993dd198597d770fe0e022466c6b9
This is a regression in the new power manager. Apparently
some apps try to use ON_AFTER_RELEASE with partial wake locks
which doesn't make sense. Ignore the flag just like we used to
prior to JB MR1.
Bug: 10336375
Change-Id: Ib307eb60201612ba9bb03dc4da3365aba0b4848d
It turns out that on some devices the sensor event timestamp
may be non-monotonic. This may cause the detector to hold
a wakelock indefinitely if the time jumps backwards. These
timestamps are not well tested in general so there may be
other artifacts as well. Use elapsed realtime instead.
Bug: 9926451
Change-Id: Idb0b316e22b23aac86837bd25b953daf49f9b758
This provides group membership to the FUSE daemon, since system
packages like NFC and Bluetooth hold sdcard_rw.
Bug: 10610659
Change-Id: I7428e999cfa4087ffe220b9d8bd80827191ab997
Make it a little easier to diagnose input dispatch timeouts by
providing the detailed reason as the ANR annotation in the log.
Bug: 10689184
Change-Id: Ie18fd9ad066b0673d1f57c030e027ad0085f4650
Added a hidden API under ConnectivityManager to toggle airplane mode.
This may be a temp solution for b/10653570.
bug:10653570
Change-Id: I0b2b42230073289eb8dc6891317d62b84e26c133
In cases where the client is waiting for an activity to launch
(startActivityMayWait()) it is a bad idea to clear
ActivityRecord.displayStartTime when going into the pause state. If
displayStartTime is cleared before the activity is displayed,
the client will never be released.
This fix keeps pause from clearing displayStartTime if any client
is waiting for the activity to be displayed.
Fixes bug 10095558. But not a permanent fix, startActivityMayWait()
should not be called by any production code.
Change-Id: I7cbdcb04256f4a26233867c52aedd3bc4151adc3
- Deprecates SurfaceTexture.OutOfResourcesException, it wasn't used
- Make all JNI code throw only Surface.OutOfResourcesException
- Get rid of redundant SurfaceControl.OutOfResourcesException
Bug: 10566539
Change-Id: I58126260771b9ccff6a69c672ce7719b9f98138d
There is some validation code that is eventually detecting that we
have an invalid network; only the result is a crash. The right thing
to do is to do validation up front; and fail calls if the network
configuration looks invalid.
Bug: 10571289
Change-Id: I100506b777a34b26ac9a310ba508140560f87a90
