Bug: 10918599
Reduce the number of recent tasks to 10 on lowram devices
Use RGB_565 on low ram devices for thumbnails instead of ARGB_8888
Combined this saves ~9MB across system_process and systemui
Change-Id: Ieddcb512c7341a90097bc7cbc72d7355a775b416
Newly added private flags were being masked in the public flag variable
as opposed to the correct privateFlags variable.
bug:11033280
bug:11043194
Change-Id: Idda3a70a083457f3f1b7d4b46d231f4a7e704cf0
The main problem here was a mistake when turning a single process
structure to a multi-package-process structure with a common
process. When we cloned the original process state, if there were
any services already created for the process for that package, they
would be left with their process pointer still referencing the
original now common process instead of the package-specific process,
allowing the active counts to get bad. Now we switch any of those
processes over to the new package-specific process.
There was also another smaller issue with how ServiceRecord is
associated with a ServiceState -- we could be waiting for an
old ServiceRecord to be destroyed while at the same time creating
a new ServiceRecord for that same service class. These would share
the same ServiceState, so when the old record finally finished
destroying itself it would trample over whatever the new service
is doing.
This is fixed by changing the model to instead of using an "active"
reference count, we have an object identifying the current owner
of the ServiceState. Then when the old ServiceRecord is cleaning
up, we know if it is still the owner at that point.
Also some other small things along the way -- new Log.wtfStack()
method that is convenient, new suite of Slog.wtf methods, fixed
some services to use Slog.wtf when catching exceptions being
returned to the caller so that we actually know about them.
Change-Id: I75674ce38050b6423fd3c6f43d1be172b470741f
- Call in all circumstances but only set launchHomeTaskNext for
focused stack. Previous version didn't call handleAppDiedLocked for
non-focused stack.
- Rearrange logic to run down the top task and make sure that all
remaining activities belong to the dying app. Previous version just
looked at the top non-finishing activity and based its behavior on
that.
Fixes bug 11029560.
Change-Id: Ic3a7c873c4c975577d6b390a8955ff41729bdfde
Should fix the array index out of bounds. valueAt() is when we have the
index, not the key.
Bug: 11014210
Change-Id: Icb53fe763782befbd5de1b3df6630b87cda72e84
If two activities are started at the same time the first activity can
add a starting window but never start. In that case there is no event
that will clear the starting window. This change adds a 10 second
timeout for the starting window to be cleared after which it will
clear the starting window automatically.
Fixes bug 10797865.
Change-Id: I1d59c3058c63367ff688d426474e8a6f006b2e0d
All ContentProvider calls are currently blocking, making it hard for
an app to recover when a remote provider is wedged. This change adds
hidden support to ContentProviderClient to timeout remote calls,
treating them as ANRs. This behavior is disabled by default.
Update DocumentsUI to use a 20 second timeout whenever interacting
with a storage provider.
Bug: 10993301, 10819461, 10852518
Change-Id: I10fa3c425c6a7225fff9cb7a0a07659028230cd3
Fixes jank exposed in 10881705. Specifically background activity
animating up along with translucent activity. Repro steps on manta:
1. From home start Settings.
2. Press home.
3. From home start Downloads (translucent activity that takes 85% of
screen).
4. Observe that as Downloads zooms up the 15% boundary that should be
dimly transparent are showing Settings.
The cause was that there is a finishing activity in the Downloads task
that was used to launch the DownloadsActivity. The existence of that
activity kept the logic from recognizing that the home activity was
behind the DownloadsActivity, not the Settings activity.
This fix descends through all of the activities in a task sitting on
home and makes sure that they only keep home from showing if such
activities are not finishing and visible.
Change-Id: I607afce6b0000b4db634f2ce40a6c37fcee369d7
Not dealing with the case where there is a null list.
Also fixed some bugs I found while looking at this:
- When resetting the stats, we would use a newly computed time stamp
for the total durations rather than the one we used to reset the
proc/service entries. This would result in them being able to be
slightly > 100%.
- There was a bug in how we split a single process state into its
per-package representation, where we would but the cloned process
state into the new package's entry (instead of properly for its
own package entry), to be immediately overwritten by the new
process state we make for that package. This could result in
bad data for processes that have multiple packages.
- There was a bug in resetting service stats, where we wouldn't
update the overall run timestamp, allowing that time to sometimes
be > 100%.
- There was a bug in computing pss data for processes with multiple
packages, where the pss data was not distributed across all of the
activity per-package process states.
- There was a bug in computing the zram information that would cause
it to compute the wrong value, and then never be displayed.
Finally a little code refactoring so that ProcessState and ServiceState
can now share a common implementation for the table of duration values.
Change-Id: I5e0f4e9107829b81f395dad9419c33257b4f8902
Do not use the shortcut of the package name to identify the home
activity.
Fixes bug 10963726.
Fixes bug 10920950.
Change-Id: I725781a26672b055a816994aee6ea458a7f07c88
Killing the GEL search results was killing everything in its package.
This fix keeps the home process from being killed when a task in its
package is killed.
Fixes bug 10927223.
Change-Id: I56e75f0a0118885a1604cbd70320bbdb4f8cf1a2
The home activity was being returned to when any activity in a task
that was launched from home crashed. If there were still activities
left in the task then the crash should have brought up those
activities next, not home.
This may be a partial fix for crashes where the back stack was showing
up under launcher icons. Bug 10858941.
Change-Id: I840a25bd8395bfce46f4e21b112d78b12884706d
If an activity is visible behind the keyguard when it is launched
by another activity then there would be no call to dismissKeyguard.
Because the other activity is pausing the call to dismissKeyguard
is skipped in startActivityLocked(). And because it is already
visible the call to ActivityRecord.windowsVisible() is never made and
the call to reportActivityVisibleLocked() which calls
dismissKeyguard() is also never made.
This change recognizes when an activity is resumed and visible and
calls dismissKeyguard() in that case.
Fixes bug 10732489.
Change-Id: I3de1350a55231aaa14dadc8709fd0fcf4960742c
Back out changes from CLs ag/363992 and ag/363859. These introduced
the bugs found in bug 10917435 which is now fixed. Note that backing
out these changes reintroduces bug 10732489.
Change-Id: Ic5105dd4cfc8bf79c6f06188283d1ee3680c370c
Check and throw if callers request invalid grant flags. Add API to
test if a Uri is backend by a DocumentsProvider.
Bug: 10919391, 10935608
Change-Id: Ifa6afefb95983558c8c64dc15ddf650e9fe07080
Now when memory low, if a service's process is above
a selected pss, then the process is not allowed to go
in to the service a list.
Also simplified the normal meminfo details dump to not
include the shared dirty and shared clean sizes by
default, since these can be very confusing. You will
still get to see them with the "-a" flag.
Finally some small steps to better managing service
processes in the LRU list, so hopefully we can some
day be better about letting them drop down in the list
when there isn't really much interesting happening in
the process. Not yet used at this point.
Change-Id: I654bfd6d05de2a63120185ebb15ffda8cbeb5dac
Change our Intent flag to indicate that a Uri permission grant is
persistable, but don't actually persist it until explicitly taken by
the receiving app. This prevents apps from spamming each other if
persisted permissions aren't really required.
Remember the last time a persisted grant was taken by an app, and
use this to prune away the oldest grants when the number of grants
grows too large. Allow apps to query persisted grants they are
holding, and allow them to release previously persisted grants. Add
public UriPermission class to return grant details and timestamp.
Track various permission strengths separately, and combine together
after each mutation pass. Persistable grants are currently treated
like global grants, but they could be moved to have owners in the
future. Require that grant holders trying to extend a persistable
permission actually hold a persistable permission themselves.
Bug: 10835779
Change-Id: I95b2f797c04ce7fd2612f9a644685dbd44e03759
