- Report capture failures from service to application
- Only go to error state for device-level errors
- Adjust binder interface method names to match the service side names
- Reduce failed session creation logging
- Don't fire CaptureSession.onActive for CameraDevice.onBusy
- Check with session to determine capture failure reason
Bug: 17160301
Bug: 15524101
Bug: 14448494
Bug: 11272459
Change-Id: I9dd606004fd7845910dc865738fbe17f1640f07d
The max limit is now 100 (or 50 on svelte devices), and that is
what everyone used.
Re-arranged things so we have a big expensive "fix the world!"
function for recents that we go in to at only select points:
when first initializing the system, when external storage comes
and goes, and if we detect something wrong with the recents
structure.
With that, now getRecentTasks() and addRecentTaskLocked() are
generally much simpler, doing very little work in most cases.
This will help a lot with scaling up to many more recents
entries.
Change-Id: I7b5ae89edc06568f68c8af54a4420aff7635581c
Changed from getConfirmDeviceCredentialIntent to createConfirmDeviceCredentialIntent
Fixes bug 17288988
Change-Id: Iae9a997d9ea49ce23bdbbe38ad7b0763779b8f59
Treat activity title changes as window title changes when propagating
to action bars. This gives it lower priority if a "hard" title has
been set. Fix some lifecycle handling around this that previously
resulted in multiple calls.
Automatically detect the starting display options for a
ToolbarWidgetWrapper if we're not grabbing them from styles. This
prevents setTitle and friends from going totally out to lunch if
constructed around a Toolbar with no starting title.
Bug 17138048
Change-Id: I9f58a3d222546745c8aa873e996b8f0d52a0ad21
We keep per user settings for enabled print services which are
observed to update the print manager service state. We were listening
to all user changes but the handling code was not updating the state
of the user whose settings changed, rather the current user.
Added hidden APIs in content observer to know which user changed
and now the print manager serivce handles content changes for the
correct user.
bug:16977006
Change-Id: I71ec88c8f3f38cb405844c13ab83695c2029eb79
Some events in the future may not have originated
from a class, so we shouldn't be using ComponentName.
Bug:17259858
Change-Id: Id7fe3245b91596cf27ae4ec51655602f01665622
Getting the indexOf is useful for doing compound operations
like:
int i = set.indexOf(key);
if (i >= 0) {
Object o = set.valueAt(i);
o.blah();
set.removeAt(i);
}
Change-Id: I3d4b77d1461ba969fc6b4d332d52d4d084b5b53c
In application processes, monitor for when we start getting close
to the Dalvik heap limit, and ask the activity manager to try to
prune old activity instances in that case.
Add an explicit API for apps to ask that they have their own
activity instances cleaned up, if they want.
Fix some bugs in launching activities that were not correctly
applying the "multi task" behavior in the appropriate situations
of document-centric recents.
Clean up the activity manager's process removal code to all share
a common path.
Add a new "Spam" option to ActivityTests, which continually creates
new tasks, checking that the activity manager will now prune old
tasks rather than letting the app run out of RAM.
And while I was was doing this, I found problems with the path
for bringing an empty task to the foreground -- it could make
a new task instead of re-starting the root activity in the
existing task. This is fixed, and some code in the recents
UI for working around the bug is removed.
And as long as I am doing that, we now have nice hooks in to
the activity manager for AppTask to give some APIs for better
managing the task, so add those along with more tests for these
APIs in ActivityTests.
We should look at also having the activity manager try to prune
old tasks when it sees app processes being killed, to better balance
memory use across multiple processes when some processes may host
many documents. That however is for another CL...
Change-Id: I2bb81c3f92819350c868c7a7470b35817eb9bea9
Rename Ranking.meetsInterruptionFilter() to matchesInterruptionFilter()
as suggested by API council.
Marking the old version @removed for now, will remove once prebuilds had
the chance to update.
Bug: 17255109
Change-Id: Iaee094df2dddf82029e127c194ea88581d1a48bb
Moving apps to/from SD cards has historically been neglected, meaning
it can easily break. This happened most recently for split APKs,
64-bit native code, and multiArch support.
To make this easier to maintain, treat move as a no-op upgrade,
following the inheriting code path that split APKs depends on.
Also clean up scary places where different flavors of flags were
being combined, and remove unused flags. Fix media broadcasts to be
sent based on existing app storage location.
New API to abandon install session without opening it.
Bug: 17158495
Change-Id: Ia33bf8f6fdaae099124dfe534f0e320b37bc8e16
1. An external contribution changed the ordering of views for
accessibility. While it attempted to fix a platform issue
for a comparator breaking transitivity, it changed the way
we order views and results in very unnatural accessibility
traversal order. It also broke CTS tets. This change tweaks
the comparator which fixes the tests and improves traversal
order.
2. If there is at least one accessibility service which cares
about windows we register a callback in the window manager
for window change notifications. We are updating the window
list on this callback. There was a case where if the service
requests window updates and immediately asks for the windows
it gets none as we have not received a callback from the
window manager yet. Now this call returns after we get the
callback in a timed fashion. This is consistent with how the
other introspection APIs work.
3. Window info objects are cached in the accessibility service
process. When putting them in the cache a cloning call was
missing resulting in some cases of clobbering windows given
to the client. For example, we get some windows, cache them,
and return these windows to the client. Now a call to clear
the cache arrives while the user processes the windows and
the client windows get clobbered.
4. Added API for checking if a window has accessiblity focus
to be consistent to the API we have to check whether this
window has input focus.
5. Removed some obsolete code.
bug:16402352
Change-Id: Ided6da4a82cc0fc703008c58a2dff0119a3ff317