am: 53560db
* commit '53560db137aeab0a25c6a81c61da4426a676ce37':
Make WifiScanner state not static and use ConnectivityThread
Change-Id: If2d49d771b63e0fd1bd96bdd976048da9435648a
am: 3c58709
* commit '3c5870912b6dc20e13c3af5e078a600b88904e99':
Make WifiScanner state not static and use ConnectivityThread
Change-Id: Ia2c6bb955461884e88d13af885e0011fcafec7b5
We now keep track of how long each app has been running a job
for, in 30 minute batches. If it is running jobs frequently,
we will bump down the priority its jobs run at to allow other
jobs to run before it.
Currently we count both pending and active as the job running,
which means that an app that has jobs waiting in the pending
queue will count against its abuse prevention. This could
allow starvation -- if we bump down the priority of an app's
jobs and the system is so busy continually that they sit
in the pending queue a lot -- it could never recover. But I
think that is okay... if we are really in a state where we
are continually running as many jobs as possible, we probably
have other larger issues.
Change-Id: I838aa4b5840e91df49a1e17b53188d6e4a66a6d1
am: 96d49b1
* commit '96d49b1ac6e197f64103e5454e308f65609b2853':
API polish in DPM for organization color and name methods
Change-Id: I90b74fa1b0c3e2961fb26fc5e84e85d5bc5da1f5
am: 1271cef
* commit '1271cef419bdb7577f64b1dfa05d5678df706ef5':
API polish in DPM for organization color and name methods
Change-Id: I6073662932fc256fc4860a19c4d45b1f9fcf9ced
am: 7b13098
* commit '7b13098b6299530348c836266d74369b0ff0b3d4':
Added api to delete cache files for a given user
Change-Id: I4a2c3d4137e2f48bf3e57c3a54c0ed5e573ed66e
am: 0a6a6db
* commit '0a6a6dbe9107a3e31d74293f853b46ae0e5b9e7b':
Added api to delete cache files for a given user
Change-Id: If8bc5327e76680d3d30127b1129e7c4c36928421
Added an api to delete application cache files for a specific user. This
allows settings to clear cache files for work profile apps as well.
Bug: b/25338468
Change-Id: I52d4944a7a03b6d63ad44dd6bb868aec62815eab
am: 0666069
* commit '06660697a3198835b5a7955f3955e58fb92e407f':
Fixes name of intent launch flag for Action Extender
Change-Id: Ia824a1bc0a6c52697e0e0ce7cea0f6448ef60594
am: e3f3cb1
* commit 'e3f3cb10484260fac167e59d0178902a63ea7a6b':
Fixes name of intent launch flag for Action Extender
Change-Id: Idbfc4beca1067031b9a7608930aa61779644901e
- Returning and accepting CharSequence instead of String
- Enforcing 100% opacity and adjusting javadocs for color
format
- Adding @ColorInt annotations
Bug: 27531295
Change-Id: Id27d4fd5e7bb4d746cc61288457eb4eb86224505
am: 4ed2fb8
* commit '4ed2fb8b5cfe63087d155d1f4f2bbe0b8a312980':
Fix notifications that are sent for USER_ALL.
Change-Id: Ifa2314c4f0f913f92f22fe02ff770912e307e913
am: 01a1ad5
* commit '01a1ad511e126aca0b445457f06e31f903b84ffb':
Fix notifications that are sent for USER_ALL.
Change-Id: I73f0984bf8d298017577fbe20406a0f19996fed6
Also avoid creating a heavy LoadedApk object which will be cached
around in the long-lived system process.
Bug: 28116427
Change-Id: I1a5fc43e6d559a09088636b2fe4b5c76f08d3413
Loaders report entering the started state in two places, once from
their host callbacks and once when moving into their host fragment's
starting state. In the former, we will also deliver load results if
we're finishing a retained cycle.
In practice, the individual fragment start happens first which clears
the report-next-start flag, then the finishRetain step sees that flag
is cleared and dispatches the finished load results again. Change
reportStart to only call onLoadFinished if we are not finishing up a
retain step.
Bug 28074512
Change-Id: I85b848f7d7b239c8fac5aec8f0c91e4eea6bcebf
