The problem was that the ResolverActivity filters some activities
out of the list it shows, but it uses that display list as the
list of components the preference is set against when ultimately
setting it on the package manager... but that filtered list is *not*
the right component set, since it is not the same as the package
manager's view on it.
The fix here is to retain the original set of matching components
and use that when setting the preferred activity. Note that this
does mean that in very unusual cases where filtering is happeing
(such as one of the activities not being exported but being seen
as a possible completion from another app), then you will be setting
the preference for the complete set. Ultimately we probably need
to have the package manager apply these filtering rules up-front so
this is all consistent, but this is a very rare case so not that
important.
And then most of the change here is just improving the debug
output for intent resolution.
Change-Id: Ie35ac2c05a45946439951bbf41433c8b7de79c05
When a file already exists on disk, try adding a counter suffix to
make a unique name. Move services near top of roots list, just below
recents. Remove "Documents" root.
Increase number of recents allowed from single provider, and add more
logging to diagnose wedged loaders.
When launching GET_CONTENT apps, wait for successful result before
relaying result; canceled requests now return to DocumentsUI.
Add CloseGuard to ContentProviderClients, since leaked instances can
keep the remote process alive.
Fix UI bug around trailing breadcrumbs. Fix bug that dropped Recents
from roots list. Add up action to Settings activity. Give our
activity a default icon while waiting for async roots to load.
Bug: 10818683, 10819461, 10819461, 10819196, 10860199
Change-Id: I7b9e26b1cf8353dd3175458b23da2b4bda6c5831
- Adds null checks when setting mCompatibilityInfo and uses default no-op
CompatibilityInfo object instead of null
- Removes null checks when calling methods on mCompatibilityInfo since it is never
null
bug:10204942
Change-Id: I36e88f5cdceb46b8b19fb902270ef74023a81546
...while setting up a new user from settings.
We can now delay broadcasts when there are enough background services
currently starting (still set to 1 for svelte devices, 3 for normal
devices).
Add new intent flag to not allow receivers to abort broadcasts, which
I use to fix an issue with the initial BOOT_COMPLETED broadcast not
actually requesting pss data at the right time -- it can now be sent
as an ordered broadcast without the ability for the receivers to cancel
it.
Change-Id: I51155bbbabe23e187003f3e2abd7b754e55d3c95
Code path to release content provider associated with the PFD was
inadvertently bypassed by a previous change. Reinstate that code
when closing the PFD.
Bug: 10767447
Change-Id: I23306cfb3c28c99e587892b17ca85efd3f7a8a07
Bug: 9520957
DevicePolicyManagerService will play dumb if the feature is not installed.
Continue to keep track of failed password attempts for keyguard's use.
Change-Id: I28d258dc09a8b4976b188da6f453d8daabcc4bdd
This way an application can automatically sunset its permission requests
when running on later versions of the OS where those permissions are no
longer relevant, but may be alarming to the user. A canonical example
is WRITE_EXTERNAL_STORAGE, which as of KLP becomes unnecessary for an app
to use the external storage volume solely for its own large-data needs,
without the need for actual file-system sharing among multiple apps.
Bug 9761041
Change-Id: I60130af3a108fe4a750c356038a1c8cb897e9c8b
We now have the activity manager kill long-running processes
during idle maintanence.
This involved adding some more information to the activity manager
about the current memory state, so that it could know if it really
should bother killing anything. While doing this, I also improved
how we determine when memory is getting low by better ignoring cases
where processes are going away for other reasons (such as now idle
maintenance). We now won't raise our memory state if either a process
is going away because we wanted it gone for another reason or the
total number of processes is not decreasing.
The idle maintanence killing also uses new per-process information
about whether the process has ever gone into the cached state since
the last idle maintenance, and the initial pss and current pss size
over its run time.
Change-Id: Iceaa7ffb2ad2015c33a64133a72a272b56dbad53
Support decoding thumbnails delivered over pipes by wrapping in a
buffered stream. Also switch to using unstable provider references
to avoid crashing DocumentsUI.
Bug: 10516148, 10510851
Change-Id: I85f6eeaca70c97742bf79656d1d0c6da381fdd47
This changeset adds in typedef annotations (custom annotations
marked with @IntDef) for various int parameters and return values
in the API. It also adds nullness annotations for cases where the
documentation explicitly mentioned null policy, or where it was
blindingly obvious from the context. Also fixed some typos in the
documentation.
Change-Id: Ica27c01368895818e26237544edd8483007155bb
java.lang.SecurityException: Operation not allowed
There was a situation I wasn't taking into account -- components
declared by the system has a special ability to run in the processes
of other uids. This means that if that code loaded into another
process tries to do anything needing an app op verification, it will
fail, because it will say it is calling as the system package name but
it is not actually coming from the system uid.
To fix this, we add a new Context.getOpPackageName() to go along-side
getBasePackageName(). This is a special call for use by all app ops
verification, which will be initialized with either the base package
name, the actual package name, or now the default package name of the
process if we are creating a context for system code being loaded into
a non-system process.
I had to update all of the code doing app ops checks to switch to this
method to get the calling package name.
Also improve the security exception throw to have a more descriptive
error message.
Change-Id: Ic04f77b3938585b02fccabbc12d2f0dc62b9ef25
