| 4f128e4d968b376bb7c3fa209d27b0a30202e604 |
|
10-May-2016 |
Amith Yamasani <yamasani@google.com> |
Fix multi-window assiststructure trashing
When multiple activities within the same process
try to handle requests for AssistStructure, the
singleton mLastAssistStructure tends to trash
the old structure when a second window's request
comes in.
This change passes in a sessionId so that the
cache is only cleared if the session id changes.
Bug: 28348867
Change-Id: I07efcd933db7e48aefd25a1c95493b71bbcffe4b
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 933076d80561751618f462b26309ce9e4c3ff3bf |
|
30-Mar-2016 |
Andrii Kulian <akulian@google.com> |
Refactor usages of Picture In Picture and Multi Window (1/4)
Bug: 27365860
Change-Id: I1590e430a12ceb84cb83da295e0bf7e4378fea96
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| c4fb5f9d4b8012bc007f0c7e472d4ff4801254f5 |
|
03-Feb-2016 |
Colin Cross <ccross@android.com> |
Add dumpsys meminfo --unreachable
dumpsys meminfo --unreachable will search the native heap for
allocations that are unreachable.
Bug: 27208635
Change-Id: I40ab1c261cb222ca71d04ab8408f355bcb18ed94
(cherry picked from commit 84b1e3554b36b7fbccf57330c93bf484985ae3d6)
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 3b93a4d351aeb154fba8a4b2fa66ca25a951993d |
|
30-Jan-2016 |
Wale Ogunwale <ogunwale@google.com> |
Renamed Activity class multi-window APIs
As requested by API council.
Bug: 26507736
Change-Id: I2a87c5eb3c1b48d52703103c2a4f72c250a9a827
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 0af6fa7015cd9da08bf52c1efb13641d30fd6bd7 |
|
18-Jan-2016 |
Amith Yamasani <yamasani@google.com> |
Voice Interaction from within an Activity
This allows an app to show a voice search button
and invoke a voice interaction session for use
within the activity. Once the activity exits, the
session is stopped.
Test application has a new activity that
demonstrates it with the test voice interaction
service.
This initial version is functional enough for
an integration test, with some more tests
and improvements to come later.
Bug: 22791070
Change-Id: Ib1e5bc8cae1fde40570c999b9cf4bb29efe4916d
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 5f986095bed776c119d2f5452e0afeac3a437ea2 |
|
05-Dec-2015 |
Wale Ogunwale <ogunwale@google.com> |
APIs for activity to know when its windowing/pip modes change
Added APIs that allow activities to ask the system if they are currently
in multi-window or picture-in-picture mode and also get notified when
their modes change.
Bug: 25509834
Bug: 25683717
Change-Id: I4b8c316a49940bd6a8b31a93b345f9fd725a4721
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| ca66481244913c4a17b62c3ddff214d2ca72c439 |
|
04-Dec-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Update client configuration when resizing without crossing size threshold.
Even though the activity won't be relaunched and won't receive a
callback about the resize, we still need to update it's configuration.
Otherwise when the application queries for it, it will receive wrong
data.
Bug: 23904868
Change-Id: I601e91b8e71691c1cb5edb2734894441c4fde8e2
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| a4d4e82927ceadc23863e74b7e1160e4497504a7 |
|
05-Oct-2015 |
Pablo Ceballos <pceballos@google.com> |
Remove GLTrace support
GLTrace is defunct, it does not support newer GL features, breaks
security requirements, and has no supported tooling now that Eclipse
is at end of life.
Bug 22329852
Change-Id: I64c58464f8c2c7ae6125f5d5c7884e3fd34d68ea
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| a59ac9cd645d25f03e4e488100bd99f92e83a3a7 |
|
11-Sep-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Preserve window during resize triggered relaunches.
This changes application code behavior when the activity relaunches due
to configuration change. It only applies to scenarios, where the
configuration change was triggered by a user generated resize of an
activity (i.e. user drags a corner of an activity and thus changes its
size).
Preserving a window means that we will keep the decor view and non
client decor view around, but remove all children views when the
activity gets destroyed. When the activity gets created again, it will
attach its new content to the preserved view hierarchy. Mind, we
actually recreate application side Window object, since some of its
features might changed, but we retain its elevation (to not trigger
relayout with new layout params).
Preserving the window also means that we don't call the window manager
service to remove and later add the window. Instead, we continue using a
single window state throughout the resize operation.
Change-Id: Ie3d2878ed09c99ff343044bfe7a29a0ba07a265e
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 80bea9cde179e37def61748ff0e68b4155b5360c |
|
25-Jun-2015 |
Man Cao <manc@google.com> |
resolved conflicts for merge of 8fb82074 to master
Change-Id: I27c7ddeead5a589ae8824f87bf6b42998dc081eb
|
| 8fb8207412905d034305b4b1be6eac07bdac833f |
|
25-Jun-2015 |
Mathieu Chartier <mathieuc@google.com> |
resolved conflicts for merge of 0f14548c to mnc-dev-plus-aosp
Change-Id: I2f79840f82150eddebfbd549afd1eca28075eb43
|
| cfa78b2080e590ca3b28dbf59e6d6f6e7ece7764 |
|
12-Jun-2015 |
Man Cao <manc@google.com> |
Add an AM option to start with allocation tracking
The new option "--track-allocation" is to work with the new
allocation tracker in ART.
Bug:20037135
Change-Id: Ic5f8945ab4c1f167c27b05ad0d11d04bac680c1f
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 8ee0c2cf24cc4de0abe7114c189051277568f7f1 |
|
23-Jun-2015 |
Rahul Chaturvedi <rkc@google.com> |
Merge "Add binder transaction tracking."
|
| 52613f9084f40100021fbf21173bda329a2d5cc3 |
|
18-Jun-2015 |
Rahul Chaturvedi <rkc@google.com> |
Add binder transaction tracking.
Add the ability to am to be able to track binder transact calls. This
will help us diagnose excessive IPC calls.
This CL adds the trace-ip command to am. The usage is,
To start binder transaction tracking,
am trace-ipc start
To stop tracking and dump the data to a file,
am trace-ipc stop --dump-file <FILE>
Bug: 21398706
Change-Id: Ic0c9b3be757dd0662a2750a0d8447e2a5ef1fa90
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 8a2ce3c7519d30daab37e0754d8f2b2f527af24e |
|
19-Jun-2015 |
Christopher Tate <ctate@google.com> |
Debug logging for a certain class of binder transaction failures
Bug 21801759
Change-Id: I9973d4ffb9450e510a4e1c64e2eae1489ce93054
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| c14b9cf628471f4f3b34d7c91ef193326eff92c6 |
|
13-Mar-2015 |
Richard Uhler <ruhler@google.com> |
Add 'App Summary' section to meminfo.
The 'App Summary' section is shown by default when other memory
details are shown. This adds a new meminfo flag '-s' to show only the
App Summary section.
Change-Id: I66913673cd3afca873a8b13e45abe071d4c57b82
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| c2607b4ececbefd18f223fa89d1b1aac56516009 |
|
08-Feb-2015 |
Wale Ogunwale <ogunwale@google.com> |
Include stack override configurations in onConfigurationChanged() call.
Important for activities that handle configuration changes.
Change-Id: I4d1612026f293fbb99e1abc17e663f0215658ae6
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 60454dbc4d815c90ff2713e224953d6547fc3ad5 |
|
24-Jan-2015 |
Wale Ogunwale <ogunwale@google.com> |
Support activities in the same process having different resources.
Activities can be of various sizes in a multi-window environment.
This change allows them to have override configurations that allows
different resources to the loaded if needed.
Bug: 19002213
Change-Id: Ib2c7be0b427f5ce05e7a362bcdd496ddbc9164f0
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| c2ae6fb9ada52e9c990542a6d1cae80085318f31 |
|
16-Jan-2015 |
Jeff Sharkey <jsharkey@android.com> |
Merge commit '605eb79c9519307147fc1795d0eb155638a7f542' into manualmerge
Change-Id: Id6db8cce3a477572478a1d50f624823200848896
|
| 605eb79c9519307147fc1795d0eb155638a7f542 |
|
04-Nov-2014 |
Jeff Sharkey <jsharkey@android.com> |
Offer to detect non-SSL/TLS network traffic.
Introduces new module that provides network-related features for
the StrictMode developer API. The first feature offers to detect
sockets sending data not wrapped inside a layer of SSL/TLS
encryption.
When a developer enables, we ask netd to watch all outgoing traffic
from our UID, and penalize us accordingly if cleartext sockets are
detected. When enabled, netd captures the offending packet and
passes it back to the owning process to aid investigations. When
death penalty is requested, all future traffic on the socket is
blocked, which usually results in a useful stacktrace before the
app is actually killed.
Bug: 18335678
Change-Id: I3adbc974efd8d3766b4b1a23257563bb82d53c29
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 85d558cd486d195aabfc4b43cff8f338126f60a5 |
|
04-Nov-2014 |
Dianne Hackborn <hackbod@google.com> |
Add Activity API to get referrer information.
This expands the use of EXTRA_REFERRER to be relevant anywhere,
allowing apps to supply referrer information if they want. However,
if they don't explicitly supply it, then the platform now keeps
track of package names that go with Intents when delivering them
to apps, which it can be returned as the default value.
The new method Activity.getReferrer() is used to retrieve this
referrer information. It knows about EXTRA_REFERRER, it can return
the default package name tracked internally, and it also can return
a new EXTRA_REFERRER_NAME if that exists. The latter is needed
because we can't use EXTRA_REFERRER in some cases since it is a Uri,
and things like #Intent; URI extras can only generate primitive type
extras. We really need to support this syntax for referrers, so we
need to have this additional extra field as an option.
When a referrer is to a native app, we are adopting the android-app
scheme. Since we are doing this, Intent's URI creation and parsing
now supports this scheme, and we improve its syntax to be able to build
intents with custom actions and stuff, instead of being all hung up
on custom schemes.
While doing this, fixed a problem when parsing both intent: and new
android-app: schemes with a selector portion, where we were not
respecting any scheme that was specified.
Change-Id: I06e55221e21a8156c1d6ac755a254fea386917a2
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| a4e102ee580282dc7abeb22f4a025813e53b9431 |
|
05-Sep-2014 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #17357238: Recents is often slow if not used in a while
Add a new activity attribute, resumeWhilePausing, that allows an
activity specifying it to immediately start running without waiting
for the previous activity to pause. The recents activity is updated
to use this.
The implementation of this is ultimately fairly simple -- if we are
in the path of resuming such an activity, and find that we first need
to pause the existing activity, then within the activity manager we
do the regular pause flow but act like it has immediately finished
pausing right then so that we can immediately go on to the resume.
To make this clean, we tell the activity when asking it to pause that
it should not come back and tell us it is done, because we aren't in
any way waiting for it.
One potentially important change I needed to make here is the pause
callback no longer provides the saved persistent state, because we
now can't count on that callback happening. I don't think there was
really any utility in this anyway -- all modern apps will have their
save state flow happen as part of stopping, not pausing, so we'll
only capture that saved state when the stop is reported back anyway.
And since we do send the saved state back when stopping, it would
always blow away whatever we had gotten at the pause.
Finally, update the documentation for AppTask.startActivity(), and
fix the implementation handling that to be cleaner -- we need to
deal with inTask first before getting in to "oh noes add NEW_TASK
if this isn't coming from a calling activity" flow.
Change-Id: Ia1da0fac90d7bdbaafdda2e34850d795ce17a39f
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 1b012d302b56b4adf950035136d1d191a1936d5a |
|
20-Aug-2014 |
Jeff Hao <jeffhao@google.com> |
Add sample profiling option to am.
Also bundles all profiling options into a class.
Bug: 17040932
Change-Id: I85d675ee1494bdc7308caffdf94145d27c996e9d
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 4b6c6697da5a20c08b2f9f2ca40c94008477e914 |
|
13-Aug-2014 |
Jose Lima <joselima@google.com> |
Renamed "media playing" APIs to "visible behind"
- Request from API Review: rename the media playing APIs to a more
generic name, reflecting the background visibility feature these
methods actually control.
- Made the new isActivityVisibleBehind().
- Changed convertFromTranslucent() and convertToTranslucent() to be
SystemApi.
Bug: 16959028
Change-Id: I526eac22f44273b3254dd6201f89194d13e597e2
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 8746a478abcfb3b0d73b156232051af1e8d21ce2 |
|
25-Jul-2014 |
Craig Mautner <cmautner@google.com> |
Create end of animation callback for Activity
Activities cannot draw while their entering animations are active.
This change introduces a callback, onEnterAnimationComplete() so
that activities can know when their draws will be effective.
Fixes bug 13658460.
Change-Id: Ic48540cd4c7e37538f10cb2dc0852aa3f55d11e1
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| ee2e45acbff28986c2ced636b7550d0afbb0eeb7 |
|
27-Jun-2014 |
Craig Mautner <cmautner@google.com> |
Add Media Playing API
These methods permit an activity to play or continue playing media
behind a translucent activity above it. Particularly the home
activity in Android TV. Methods exist to notify the upper activity
when playing starts or stops and for notifying the playing activity
when to stop playing and release its resources.
Methods are called when either activity's state changes or new
activities are launched.
Fixes bug 14469711.
Change-Id: I7ba10c5a4683504931cffa228488f5281e5bbf86
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| eb8abf7207aa118065999514f9248affbdd94de1 |
|
03-Jul-2014 |
Craig Mautner <cmautner@google.com> |
Introduce onNewActivityOptions for return activity
When an activity that is already translucent returns to the
previous activity using a scene transition the receiving activity
did not receive its ActivityOptions for its side of the animation.
The new method onNewActivityOptions() delivers those options.
Fixes bug 14869070.
Change-Id: I09b136b3213aae5d3521894e17a7500ac793f3d2
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 65dfc83cef6dd936deef428f1d318d10ff1d7af5 |
|
19-Jun-2014 |
Jeff Sharkey <jsharkey@android.com> |
am b9a45aae: am 447b68e7: am b5e05cff: Merge "Fixing parcel leaks to avoid virtual memory leak"
* commit 'b9a45aae8d07e7a92806b53cbc36f5488e3bac2d':
Fixing parcel leaks to avoid virtual memory leak
|
| db1a9a3862e62ea088ced2ae04a78e515089ba7e |
|
19-Jun-2014 |
Maunik Shah <mshah@codeaurora.org> |
Fixing parcel leaks to avoid virtual memory leak
Client has to call recycle() on parcel object after its usage
otherwise native layer of binder won't clear the resources of
parcel which were allocated for IPC
Change-Id: Ib31ddcc92aa4ebd80bb66729922b9133692e9c9e
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 7fd239cf0a1ddc0500b51d97e0e6c3539b42639f |
|
14-May-2014 |
Craig Mautner <cmautner@google.com> |
Merge "Pass ActivityOptions back from finishing activity."
|
| 233ceeebab7efe6ad4783371003c4cf29b896436 |
|
10-May-2014 |
Craig Mautner <cmautner@google.com> |
Pass ActivityOptions back from finishing activity.
Adding an ActivityOptions parameter to convertToTranslucent provides
a mechanism for delivering these options to the activity that
launched the one that is returning.
Fixes bug 13032208.
Fixes bug 14469460.
Fixes bug 14597427.
Change-Id: I4115dd3c69de9d175f6df0498a6e964fca5eca29
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 83520b95124e0fcaaf3154a7a267f6be0205bc74 |
|
09-May-2014 |
Jason Monk <jmonk@google.com> |
Switch PacUrl storage from String to Uri
Since the interface for creating/accessing PAC URLs through a
ProxyInfo is Uri based, so should the internal storage and
references.
Change-Id: Ibf15c350f4cc526f81aba3ec463070f26af8f535
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| a002604af0c9b1204556610537b85685d7055996 |
|
23-Apr-2014 |
Craig Mautner <cmautner@google.com> |
Introduce persistent forms of Activity lifecycle calls.
When an Activity is created with R.attr.persistable true different
forms of activity lifecycle methods including PersistableBundle will
be used.
Fixes bug 13736007.
Change-Id: I7e92917b300b76964257cfcc26c24e76aa19bd16
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 09233289624a85093b1d99e4a6a149bf09059d8d |
|
30-Apr-2014 |
Dianne Hackborn <hackbod@google.com> |
Make GET_TASKS signature|system.
Normal apps can't hold it now. If they try to use
getRecentTasks() or getRunningTasks() without the permission,
they will only see their own tasks and home in the list.
Also took this opportunity to eradicate all of the old pending
thumbnail stuff.
Change-Id: I6dc52a06221c78097162e4a8b482027b798bf3ee
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 91097de49b0f683b00e26a75dbc0ac6082344137 |
|
05-Apr-2014 |
Dianne Hackborn <hackbod@google.com> |
Initial implementation of new voice interaction API.
This gives a basic working implementation of a persist
running service that can start a voice interaction when
it wants, with the target activity(s) able to go through
the protocol to interact with it. It may even work when
the screen is off by putting the activity manager in the
correct state to act like the screen is on.
Includes a sample app that is a voice interation service
and also has an activity it can launch.
Now that I have this initial implementation, I think I
want to rework some aspects of the API.
Change-Id: I7646d0af8fb4ac768c63a18fe3de43f8091f60e9
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| ccb2a086fe0de77a4e3277454cb4a66f8e7dc57d |
|
19-Dec-2013 |
Narayan Kamath <narayan@google.com> |
Inform libcore of time format pref. changes.
- Introduce a boolean extra for intent TIME_CHANGED that
specifies if the user wants a 24 hour format or not.
- Have the ActivityManagerService inform running processes
of changes to this preference.
- Add plumbing in ActivityThread to inform j.t.DateFormat
(cherry-picked from dd491cc756233c088fd26eba4918671fcc9cfc30)
Change-Id: Ib90636bda4bc8332cfa22def831877b524b5c486
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 27ad525c7e91bde38d6c9e3e67ab38b97eb7eed0 |
|
19-Dec-2013 |
Narayan Kamath <narayan@google.com> |
Inform libcore of time format pref. changes.
- Introduce a boolean extra for intent TIME_CHANGED that
specifies if the user wants a 24 hour format or not.
- Have the ActivityManagerService inform running processes
of changes to this preference.
- Add plumbing in ActivityThread to inform j.t.DateFormat
Change-Id: I05fafb903ae54e39c03a048b7a219dc5a93fd472
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 8a985d24ce9a38f40ed88fecbdcd0e75e3a68f44 |
|
25-Feb-2014 |
John Spurlock <jspurlock@google.com> |
Tabs -> spaces in frameworks/base.
Change-Id: I5a84e8e93ac99b5ed0212b37bf66efa5e53864be
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| cfbe9be5b3b701d95fb24fa0f7c8d9be43eec776 |
|
06-Nov-2013 |
Adam Powell <adamp@google.com> |
Add support for cross-activity scenes and transitions
* Add theme attributes for specifying a top-level TransitionManager
for an activity window.
* Add window feature for automatic content transitions. This
automatically assigns/creates a Scene for setContentView calls.
* Add named transitions. This allows apps to define APIs for
handshake-agreements about which exit/entrance transitions to play.
* Add new transition type for ActivityOptions. This lets the system
use ActivityOptions to communicate transition specifics and
arguments to the called activity.
* Have ActivityManager pass appropriate ActivityOptions through to the
called Activity. Have the called activity call back into the caller
to let it know which transition of a possible requested set was
chosen.
Still to do:
* Define and pass arguments for transitions. This will require
defining a Parcelable version of TransitionValues and deciding how
much leeway apps should have for these things.
* Determine how to appropriately filter the ActivityOptions bundle so
that only appropriate data reaches the target.
* Determine if generalizing the auto-Scenes functionality to
ViewGroups is appropriate.
Change-Id: I10684b926129ab2fbc1adec9ef31767237acae79
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| dd97f4233fa8cca2a258c568f56a77c9bdc5fe74 |
|
09-Oct-2013 |
Jeff Sharkey <jsharkey@android.com> |
Install providers enabled after app started.
When an app has already been started, and a ContentProvider component
is enabled with DONT_KILL_APP, use the existing ProcessRecord to
install the provider.
Bug: 11118692
Change-Id: I990f18b337eb19768ee1db895f1e2eb982046cce
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| c2be0d61830dd867f3092923e149e0cc251cdfc5 |
|
23-Sep-2013 |
Amith Yamasani <yamasani@google.com> |
Unmarshall PFDs properly when hand-crafting interface stubs
ParcelFileDescriptors now carry an optional socket fd to communicate
close events. So, make sure that the correct creator is called when
reconstructing parceled PFDs.
Bug: 10759966
Change-Id: Ic6b9ffb8cb7af5f3a12440def595f74682231866
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 3bc8f78d7a3d23a67c06221cc41292d04a2fd439 |
|
19-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Implement issue #10691475: Kill cached processes if about to...
...be uncached and too large
When the device is in a low RAM state, when we go to pull a cached
process out to use for some background operation, we can now kill
the current process if we consider its size to be too large.
Note that the current implementation for killing processes is to
just use the same killUnneededProcessLocked() method that we already
have for other things like too many cached processes. This is a
little wrong here, though, because in this case we are at the
point where the caller is actually looking for a process to use.
This current code is not actually removing or cleaning up the
process, so we still need to return the now killed ProcessRecord
and let things fall out from there, which typically means the caller
trying to make an IPC on it and failing and falling into its "oh
no the process died unexpectedly" path. All code using this
*should* be able to handle this correctly, anyway, since processes
really can be killed at any time.
At some point we may to make this implementation cleaner, where it
actually tears down the process right in the call and returns a
null ProcessRecord. That is very dangerous however (we'd need to
go through all paths into this to make sure they are going to be
okay with process state changing on them like that), and I'm not
sure it is really worthwhile. This intention is that killing
processes like this is unusual, due to processes being too large,
and anyway as I wrote all of our incoming code paths must already
be able to handle the process being killed at this point and one
could argue this is just another way to excercise those code paths.
Really, the main negative to this is that we will often have spam
in the log with exceptions about processes dying unexpectedly.
If that is the only issue, we could just add some conditions to
quiet that up at in this case.
We don't want to compute the size of the process each time we try
to evaluate it here (it takes 10s or ms to do so), so there is now
a new field associated with the process to give us the last pss
size we computed for it while it was in the cached state.
To be able to have better cached pss data when we now need it, the
timing for computing process pss has been tuned to use a much
shorter delay for the situations when the process has first switch
into a new state. This may result in us having a fair amount more
pss data overall, which is good, as long as it doesn't cause us to
be computing pss excessively and burning cpu.
Procstats now also has new state to keep track of the number of
times each process has been killed by this new system, along with
the min, avg, max pss of all the times it has happened. This has
slightly changed the checkin format to include this additional data
at the end of pkgkills/prockills lines.
Other changes here:
- Fixed a problem where GPU RAM was not being seen when dumping
the full RAM details of a process. This was because in that
case the system would ask the process to compute its own MemInfo,
which it returned, but the process doesn't have permission to
access the files containing the GPU RAM data. So now the system
always computes the MemInfo and hands it to the app.
- Improved broadcast delays to not apply the delay if the next receiver
of the broadcast is going to run in the same process as the last
one. A situation I was seeing was an application that had two
receivers, one of which started a service; we are better off letting
the second receiver run while the service is running.
- Changed the alarm manager's TIME_TICK broadcast to be a foreground
broadcast. This really should have been anyway (it is supposed to
go out even minute, on the minute, very accurately, for UI elements
to update), and is even more important now that we are doing more
things to delay background broadcasts.
- Reworked how we maintain the LRU process list. It is now divided
into the two parts, the top always containing the processes holding
activities. This better matches the semantics we want (always try
to keep those around modulated by the LRU order we interleave with
other cached processes), and we now know whether a process is being
moved on the LRU list because of an activity operation so we can
only change the order of these activity processes when user operations
happen. Further, this just makes that common code path a lot simpler
and gets rid of all the old complexity that doesn't make sense any
more.
Change-Id: I04933ec3931b96db70b2b6ac109c071698e124eb
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 7140a25f0135f473b66d01eb042471b2f0ebc836 |
|
11-Sep-2013 |
Adam Skory <skory@google.com> |
Revert services assist context in KitKat
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
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 77ece7b192d45351b313ee23270caab373d3c477 |
|
08-Aug-2013 |
Matt Casey <mrcasey@google.com> |
Merge "Extend assist context to foreground services"
|
| 602b232a06ede86999aa362a12eb28cbc782dc1d |
|
03-Jul-2013 |
Jason Monk <jmonk@google.com> |
Add PAC File support for proxy configuration
PAC (Proxy auto-config) files contain a single javascript function,
FindProxyForURL(url, host). It gets called to determine what proxy should be
used for a specific request.
This adds PAC support to the system. The ProxyProperties has been modified
to hold the PAC file when one is present. The Proxy method
setHttpProxySystemProperty has been modified to insert a PacProxySelector
as the default ProxySelector when it is required. This new ProxySelector
makes calls to the ConnectivityService to parse the PAC file.
The ConnectivityService and the WifiConfigStore have been modified to support
saving the extra PAC file data.
The ConnectivityService now has a class attached (PacProxyNative) that
interfaces to the native calls for PAC files. The parsing of the PAC file
is handled by libpac (which is being added to external/) which utilizes
libv8 to parse the javascript.
As a fallback to applications that don't use the java ProxySelector, the proxy
is setup to point to a local proxy server that will handle the pac parsing.
bug:10182711
Change-Id: I5eb8df893c632fd3e1b732385cb7720ad646f401
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| dfc7fd7818cda46b914c8a9d69d1ba00443ffe5b |
|
06-Aug-2013 |
Adam Skory <skory@google.com> |
Extend assist context to foreground services
Add Service.onProvideAssistData(Bundle) which will be
called on foreground Services that have the new attr
in their manifest of provideAssistData = true;
Rename private reference to e.g. "getTopActivityExtras"
as "getAssistContextExtras" - do not rename the relevant
permission, since it is already public.
In ActivityManagerService, request extras both from the
top activity and from any foreground services with the
above attribute. Extend PendingActivityExtras as
PendingAssistExtras with a list of Services from which
extras are expected.
Reduce the timeout to or reporting extras from 4 sec to
just 500 ms.
Bug: 9526331
Change-Id: Ia03b96e8189033a68ae9c514c8cea0199a19bce8
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| a413dc06b2193442a2d956571b829aeb5fb97862 |
|
12-Jul-2013 |
Dianne Hackborn <hackbod@google.com> |
Add new proc state constants and delivery.
The activity manager now keeps a new "process state" for
each process, indicating the general execution and memory
state of the process. This closely follows the out-of-memory
adjustment and scheduling class that it currently tracks,
but roles these together (plus a little more info) into one
more semantically meaningful number.
This value is reported to each process as it changes, so they
can do things like tune the Dalvik garbage collector to match
the current process state.
I think I should also switch to this for process states. It
will give is more meaningful divisions of time for each process.
Also fix a problem in the activity stack where the previous
process was not being set correctly when moving between
activity stacks.
Change-Id: I598b1667dc46547f8fadae304e210c352cc9d41f
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 5eda9b330120f75964cd78b29f6101cc273c2a7e |
|
02-Jul-2013 |
Craig Mautner <cmautner@google.com> |
Add convertToTranslucent to API.
Rename convertToOpaque to convertFromTranslucent. Add the
counterpart to Activity.convertFromTranslucent() for returning from
opaque to a translucent Activity. The caller should wait until
TranslucentConversionListener.onTranslucentConversionComplete() is
called before actually changing the background to translucent.
Change-Id: Id04b026bcc4dd8bad9a33a7af126e1bb28fb9c03
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 64770d16b0907a8e1ee81ef6c8fa398a6bdbee79 |
|
24-May-2013 |
Dianne Hackborn <hackbod@google.com> |
Some improvements to meminfo output.
- Rename "Swappable PSS" to "PSS Clean" which I think is what it
means and is consistent with the other memory metrics.
- Split at the top level the dalvik heap from other dalvik allocations,
so when you look on the dalvik allocations line things are consistent
with the allocator's data and it is clear what are app allocations vs.
other data in dalvik.
- Don't print lines that are all 0.
- Don't print the detailed Dalvik allocation data by default; add a new
option to have it printed.
Here's what a typical system process dump now looks like:
** MEMINFO in pid 6358 [system] **
Pss Pss Shared Private Shared Private Heap Heap Heap
Total Clean Dirty Dirty Clean Clean Size Alloc Free
------ ------ ------ ------ ------ ------ ------ ------ ------
Native Heap 0 0 0 0 0 0 6964 3599 2048
Dalvik Heap 7541 0 4344 7356 0 0 11768 11194 574
Dalvik Other 3553 0 2792 3448 0 0
Stack 28 0 8 28 0 0
Cursor 4 0 0 4 0 0
Ashmem 5 0 12 0 0 0
Other dev 4004 0 24 4000 0 4
.so mmap 3959 684 2500 2280 5468 684
.apk mmap 173 68 0 0 692 68
.dex mmap 4358 3068 0 0 9276 3068
Other mmap 60 0 8 8 244 36
Unknown 4387 0 508 4380 0 0
TOTAL 28072 3820 10196 21504 15680 3860 18732 14793 2622
Objects
Views: 10 ViewRootImpl: 1
AppContexts: 8 Activities: 0
Assets: 3 AssetManagers: 3
Local Binders: 176 Proxy Binders: 341
Death Recipients: 141
OpenSSL Sockets: 0
SQL
MEMORY_USED: 473
PAGECACHE_OVERFLOW: 98 MALLOC_SIZE: 62
DATABASES
pgsz dbsz Lookaside(b) cache Dbname
4 68 49 7/21/7 /data/data/com.android.providers.settings/databases/settings.db
4 20 17 0/13/1 /data/system/locksettings.db
4 20 21 96/14/2 /data/system/locksettings.db (1)
4 20 21 75/13/2 /data/system/locksettings.db (2)
4 80 29 4/17/3 /data/system/users/0/accounts.db
Change-Id: Ifd511a7baaa8808f82f39509a5a15c71c41d1bac
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| d0fd54648ca6249f56cf469c57181b5a7bbb71d0 |
|
29-Jan-2013 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Adding UI test automation APIs."
|
| f9c5e0fe837a3090820da502ecaabc5accc00ace |
|
23-Jan-2013 |
Dianne Hackborn <hackbod@google.com> |
Add new API to propagate contextual data to the assist action
When launching an assist, we have a new API allowing the
current foreground activity/application to provide additional
arbitrary contextual information that is stuffed in the
assist intent before it is launched.
Change-Id: I0b2a6f5a266dc42cc0175327fa76774f814af3b4
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 80943d8daa6ab31ab5c486d57aea406aa0730d58 |
|
02-Jan-2013 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding UI test automation APIs.
This change adds APIs support for implementing UI tests. Such tests do
not rely on internal application structure and can span across application
boundaries. UI automation APIs are encapsulated in the UiAutomation object
that is provided by an Instrumentation object. It is initialized by the
system and can be used for both introspecting the screen and performing
interactions simulating a user. UI test are normal instrumentation tests
and are executed on the device.
UiAutomation uses the accessibility APIs to introspect the screen and
a special delegate object to perform privileged operations such as
injecting input events. Since instrumentation tests are invoked by a shell
command, the shell program launching the tests creates a delegate object and
passes it as an argument to started instrumentation. This delegate
allows the APK that runs the tests to access some privileged operations
protected by a signature level permissions which are explicitly granted
to the shell user.
The UiAutomation object also supports running tests in the legacy way
where the tests are run as a Java shell program. This enables existing
UiAutomator tests to keep working while the new ones should be implemented
using the new APIs. The UiAutomation object exposes lower level APIs which
allow simulation of arbitrary user interactions and writing complete UI test
cases. Clients, such as UiAutomator, are encouraged to implement higher-
level APIs which minimize development effort and can be used as a helper
library by the test developer.
The benefit of this change is decoupling UiAutomator from the system
since the former was calling hidden APIs which required that it is
bundled in the system image. This prevented UiAutomator from being
evolved separately from the system. Also UiAutomator was creating
additional API surface in the system image. Another benefit of the new
design is that now test cases have access to a context and can use
public platform APIs in addition to the UiAutomator ones. Further,
third-parties can develop their own higher level test APIs on top
of the lower level ones exposes by UiAutomation.
bug:8028258
Also this change adds the fully qualified resource name of the view's
id in the emitted AccessibilityNodeInfo if a special flag is set while
configuring the accessibility service. Also added is API for looking
up node infos by this id. The id resource name is relatively more stable
compared to the generaed id number which may change from one build to
another. This API facilitate reuing the already defined ids for UI
automation.
bug:7678973
Change-Id: I589ad14790320dec8a33095953926c2a2dd0228b
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 20e809870d8ac1e5b848f2daf51b2272ef89bdfc |
|
01-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
Add registering for explicit users.
New API to register as an explicit user, which allows you to
also select ALL to see broadcasts for all users.
New BroadcastReceiver API to find out which user the broadcast
was sent to.
Use this in app widget service to handle per-user package broadcasts
and boot completed broadcasts correctly.
Change-Id: Ibbe28993bd4aa93900c79e412026c27863019eb8
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 82b131f27418ecdd60d52638a72d01d4ad2b109f |
|
12-Jun-2012 |
Dianne Hackborn <hackbod@android.com> |
am f6e39b06: am a03696dc: Merge "ApplicationThread: Check interface before invoking scheduleLowMemory"
* commit 'f6e39b068d1d5491dc3d73d73f598790688a1c4e':
ApplicationThread: Check interface before invoking scheduleLowMemory
|
| 6ae8d1821822296df0606c9cd1c46708cc21cb58 |
|
23-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix (mostly) issue #5109947: Race condition between retrieving a...
...content provider and updating its oom adj
This introduces the concept of an "unstable" reference on a content
provider. When holding such a reference (and no normal stable ref),
the content provider dying will not cause the client process to be
killed.
This is used in ContentResolver.query(), .openAssetFileDescriptor(),
and .openTypedAssetFileDescriptor() to first access the provider
with an unstable reference, and if at the point of calling into the
provider we find it is dead then acquiring a new stable reference
and doing the operation again. Thus if the provider process dies
at any point until we get the result back, our own process will not
be killed and we can safely retry the operation.
Arguably there is still the potential for a race -- if somehow the
provider is killed way late by the OOM killer after the query or
open has returned -- but this should now be *extremely* unlikely.
We also continue to have the issue with the other calls, but these
are much less critical, and the same model can't be used there (we
wouldn't want to execute two insert operations for example).
The implementation of this required some significant changes to the
underlying plumbing of content providers, now keeping track of the
two different reference counts, and managing them appropriately. To
facilitate this, the activity manager now has a formal connection
object for a client reference on a content provider, which hands to
the application when opening the provider.
These changes have allowed a lot of the code to be cleaned up and
subtle issues closed. For example, when a process is crashing, we
now have a much better idea of the state of content provider clients
(olding a stable ref, unstable ref, or waiting for it to launch), so
that we can correctly handle each of these.
The client side code is also a fair amount cleaner, though in the
future there is more than should be done. In particular, the two
ProviderClientRecord and ProviderRefCount classes should be combined
into one, part of which is exposed to the ContentResolver internal
API as a reference on a content provider with methods for updating
reference counts and such. Some day we'll do that.
Change-Id: I87b10d1b67573ab899e09ca428f1b556fd669c8c
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 92a8b22e7410e74e1cba1b856333116652af8a5c |
|
10-Mar-2012 |
Siva Velusamy <vsiva@google.com> |
ActivityManager: add option to allow OpenGL trace.
This patch adds an option to enable tracing of OpenGL functions.
OpenGL tracing can be enabled by passing "--opengl-trace" option
to am start. This option requires either a device in debug mode,
or that the application itself has debug permission set.
Change-Id: I77788bfe97c9108943b1f947ce81afe8293d78a0
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| e94a3e7f84c4e47f013be07901f8f1ceeedefb6e |
|
02-Feb-2012 |
Vairavan Srinivasan <vairav@codeaurora.org> |
ApplicationThread: Check interface before invoking scheduleLowMemory
Change-Id: I51317386e1729366d19f7e3a1747b05170b9305a
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 6754ba24f12a54b97b3ca1c5d29fc23c15980abe |
|
15-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Add plumbing for dumping database info using dumpsys.
Change-Id: I51b0364c3d3d41aa38a759fbce48e625fff1b2dd
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 18cb28756caf02bf2b2f5e67c68451edaf719b47 |
|
15-Nov-2011 |
Marco Nelissen <marcone@google.com> |
Add ContentProvider.dump()
This is similar to the existing dump() facility for services.
ContentProviders can now implement dump() and that info will be shown
when running "dumpsys activity provider" and when taking a bugreport.
Change-Id: I33b3b132e3c4f920153355cc368eda2f725a715f
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 58f42a59bda3bc912d0d2f81dc65a9d31d140eaa |
|
10-Oct-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5405788: Device continuously opening and closing...
...the "Complete action using" dialog
When an application goes idle, it sends back to the activity manager
the configuration it last used, to make sure the two don't get out
of sync. Fix a bunch of edge cases here in dealing with that, and
be sure to also send the current configuration when launching an
activity so the client is always up-to-date when launching.
Also a small fix to not show the upgrading dialog during first boot.
Change-Id: I14ed366a87cd689d1c78787369e052422290ac6f
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 5d927c2d8e832fcfcb0154c8741f896001141ef4 |
|
02-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5150899: Call activity takes 15MB we never get back.
Persistent process can no longer use hardware acclerated drawing
when running on a low-memory device.
Change-Id: I3110335617af1c98fcede9bf41f4a1d0c20d0e87
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 62f20ecf492d2b29881bba307c79ff55e68760e6 |
|
16-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Add new am option to profile the launching of an activity.
Change-Id: Ie71a8043eafe41f53a0b3dbb5170276d87acbc9b
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| b437e090ec03a2bab10bdfcb9484577a7f34e157 |
|
06-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Improved memory use reporting.
Change-Id: I38e53e6228bba92a142bafeedb5af8df4e4e5724
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 9a8c5cefcab3d5dec6ff63f0e99553e1aa9a4af8 |
|
22-Jul-2011 |
Romain Guy <romainguy@google.com> |
Ouput looper traces as traceview traces
Change-Id: I96c8e85fd7497d970febbf6f5aefc4ab903add8e
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 7eabe55db6b113f83c2cefcd06812648927de877 |
|
21-Jul-2011 |
Romain Guy <romainguy@google.com> |
Add looper profiling to adb shell am
To profile the looper, run the following command:
adb shell am profile looper start <process> <file>
adb shell am profile looper stop <process>
Change-Id: I781f156e473d7bdbb6d13aaffeeaae88bc01a69f
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 0e3328fbdd3845b0e2bec364e951498eaee6b079 |
|
17-Jul-2011 |
Dianne Hackborn <hackbod@google.com> |
Rework and fix "adb shell dumpsys meminfo"
We now collect more detailed information splitting the maps into
additional useful categories.
Fixed some bugs in account, such as not correctly handling all of
the current dalvik allocations.
The activity manager now prints a final summary of all pss organized
by the apps and the categories.
Change-Id: Iafc5f27c998095812b1483c6803b8e0f0587aeae
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| ce86ba86df61de8b34b226a4eb6c23ec33e866e0 |
|
14-Jul-2011 |
Dianne Hackborn <hackbod@google.com> |
Improve handling of low memory.
Now classify background processes into a set of bins of how much
memory they should try to clear. The last bin also involves
destroying all activities in that process.
Removed the old code for the simulator that is no longer needed
(yay). The debugging features it had are now integrated into the
regular oom adj code.
Small fixes to load average service.
Change-Id: Ic8df401714b188c73b50dbc8f8e6345b58f1f3a0
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| aa9d84c37e05f696ec158dac98ce38cf41e18314 |
|
10-May-2011 |
Dianne Hackborn <hackbod@google.com> |
resolved conflicts for merge of 05be6d6f to master
Change-Id: Ic6a6c5bb300f6f1d43f9ed550b284282b4f16212
|
| e2515eebf42c763c0a2d9f873a153711778cfc17 |
|
28-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
Better compat mode part one: start scaling windows.
First step of improving app screen size compatibility mode. When
running in compat mode, an application's windows are scaled up on
the screen rather than being small with 1:1 pixels.
Currently we scale the application to fill the entire screen, so
don't use an even pixel scaling. Though this may have some
negative impact on the appearance (it looks okay to me), it has a
big benefit of allowing us to now treat these apps as normal
full-screens apps and do the normal transition animations as you
move in and out and around in them.
This introduces fun stuff in the input system to take care of
modifying pointer coordinates to account for the app window
surface scaling. The input dispatcher is told about the scale
that is being applied to each window and, when there is one,
adjusts pointer events appropriately as they are being sent
to the transport.
Also modified is CompatibilityInfo, which has been greatly
simplified to not be so insane and incomprehendible. It is
now simple -- when constructed it determines if the given app
is compatible with the current screen size and density, and
that is that.
There are new APIs on ActivityManagerService to put applications
that we would traditionally consider compatible with larger screens
in compatibility mode. This is the start of a facility to have
a UI affordance for a user to switch apps in and out of
compatibility.
To test switching of modes, there is a new variation of the "am"
command to do this: am screen-compat [on|off] [package]
This mode switching has the fundamentals of restarting activities
when it is changed, though the state still needs to be persisted
and the overall mode switch cleaned up.
For the few small apps I have tested, things mostly seem to be
working well. I know of one problem with the text selection
handles being drawn at the wrong position because at some point
the window offset is being scaled incorrectly. There are
probably other similar issues around the interaction between
two windows because the different window coordinate spaces are
done in a hacky way instead of being formally integrated into
the window manager layout process.
Change-Id: Ie038e3746b448135117bd860859d74e360938557
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 0c5001d776d56bae02a5cc2663286a125d99bc5e |
|
13-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
Add APIs to remove tasks.
You can remove sub-tasks inside of a task, or an entire task.
When removing an entire task, you can have its process killed
as well.
When the process is killed, any running services will get an
onTaskRemoved() callback for them to do cleanup before their
process is killed (and the service possibly restarted).
Or they can set a new android:stopWithTask attribute to just
have the service automatically (cleanly) stopped at this point.
Change-Id: I1891bc2da006fa53b99c52f9040f1145650e6808
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| e17aeb31030cfeed339a39a107912ad5e9178390 |
|
08-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
Improve activity manager debug dumps.
Activity manager now does all dump requests into apps
asynchronously, so it can nicely timeout if there is an
app problem. Also lots of general cleanup of the am
dump output.
Change-Id: Id0dbccffb217315aeb85c964e379833e6aa3f5af
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 54d068ec6af0ee6d261a135400efe6816c6f5ffe |
|
02-Mar-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Add system wide management of core settings
bug:3505060
Since we want to have some settings that are used very frequently
by many applications (long-press timeout is one example) these should
be managed efficiently to reduce lookups from different processes
because in the case of a cache miss a disk I/O is performed. Now
the system manages such core settings and propagates them to the
application processes.
Change-Id: Ie793211baf8770f2181ac8ba9d7c2609dfaa32a7
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 4eba96bb314d8ff773ea33d6cb3179f25751ecce |
|
21-Jan-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #3377999: Activities need to be stopped when sleeping
This is a band-aid over the existing kludgy stopping mechanism
where the semantics of stop are different in the activity manager
than in the clients.
This change is intended to be as unobtrusive as possible, only
impacting the sleep case. I have a different change that
completely reworks how we stop activities to simply this all
a lot by unifying the semantics between the server and client.
However, it is too late in HC for such an extensive change. Later
I'll revert this one and put in the better solution.
Change-Id: Id77f2db1ec83469cdd888acb8fbc4679daa7766e
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 30d7189067524000c738c188c4ff91f84f474d25 |
|
11-Dec-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #3274841: Orientation change problem with a paused activity
Plus a bunch of debug output improvements.
And some new Intent helpers for dealing with restarting an app.
Change-Id: I50ec56bca6a86c562156b13fe8a6fdf68038a12e
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 434203a277cd2f237a71508a3d5a7d1602126cd5 |
|
12-Oct-2010 |
Robert Greenwalt <rgreenwalt@google.com> |
Notify all VMs when proxy changes.
bug:2700664
Change-Id: I74cc6e0bd6e66847bf18f524ce851e3e9d2c4e87
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 03595d01188d88c169e8c9dd51b357fd545e69cc |
|
02-Nov-2010 |
Robert Greenwalt <rgreenwalt@google.com> |
Tell each VM to flush their DNS cache.
bug:3095357
Change-Id: I93de24e3e5a7d8b94d55f4facfffc863a2b8c202
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 625ac271f80777668f832a344486a6fcdc06d0ae |
|
18-Sep-2010 |
Dianne Hackborn <hackbod@google.com> |
Work on fragments in layouts.
- Change semantics if IDs associated with these fragments, to
work correctly when placed in a container. If the container
has an ID or you have supplied a tag, the fragment's ID is
optional.
- To do this, there is a new LayoutInflater API that allows code
creating views to access the parent container that view will
be in.
- Fix issues with state management around these fragments. Now
correctly retains state when switching to a layout that doesn't
include the fragment.
Also:
- Add new simple list layouts for items that want to show an
activated state.
- Add new Activity.dump() that can be invoked with adb shell
dumpsys; the default implementation dumps fragment state.
Change-Id: I192f35e3ea8c53fbd26cf909095f2a994abfc1b6
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 824c510752fd6a30cdba5ed7324cb80a5043ce26 |
|
10-Jul-2010 |
Andy McFadden <fadden@android.com> |
Allow "am" to initiate heap dumps.
This was mostly cloned from the "am profile" implementation. It's
intended to replace the old "kill -10" approach used by "runhat".
We could really use a native heap dump, so I pass a "managed"
flag through that indicates whether we want to dump the native or
managed heap. We don't currently have a native heap dump-to-file
function, so it currently just logs a warning.
(android.ddm.DdmHandleNativeHeap.getLeakInfo is a good start -- it
copies /proc/maps and then calls get_malloc_leak_info to get some
goodies. Needs some formatting to make it human-readable. I didn't
want to cram all that into this change.)
It would be useful if "am" didn't exit until the heap dump operation
completed, but I'm not sure how to do that.
Bug 2759474.
Change-Id: I46bc98067738d8c72ac0fc10002ca67bb4929271
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| c27181c7f3e11170ec82807cfa416f0a906ff574 |
|
30-Jun-2010 |
Christopher Tate <ctate@google.com> |
Remove memory monitoring from the system watchdog
This was originally written as an in-case-we-need-it facility, but was
never actually used in production. It also soaked up a surprising amount
of cpu on occasion, as well as doing sketchy things like demoting the
system_server's primary looper thread to the background cgroup at times.
Change-Id: I9a81a8d1e9caea9e0a1277d97785fe96add438d7
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 9d39d0cb361c5d3bba04a6bacf299be2162a6e92 |
|
25-Jun-2010 |
Dianne Hackborn <hackbod@google.com> |
Make bad notifications crash their application.
Implement notification manager handling of bad notifications, to
call a new activity manager to have the owner's process crashed
(if there is one).
Change-Id: Ib15e8d0c598756f3b39c99cc2045c18e054daf6b
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 4416c3d6e4becd9ed39b89a03db0239c8225a135 |
|
05-May-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #2643754: Launcher is caching widget layouts for too long
With the .apk file names now changing during an update, we need
to make sure to flush all caches related to a package when the
package is removed. Otherwise we can continue to use the old
package, since its old file may still exist if we try to load it
too soon.
Change-Id: I15f08dffca3feac999dbca4f24bef12a30ca0a66
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 871ecdce67fb59a2603c1b93db657fe8b65695bd |
|
12-Dec-2009 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #2304284: contacts/dialer/recentcalls constantly flashing
Make sure the application is always given the most recent configuration
when launcher. Use the current configuration, instead of whatever happens
to be set by the app, for reporting what it was launched with.
Change-Id: I2ffe306f56cc9092b640546dd0a28d2c29b9c0b3
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 68d881cf2d2b252f6f795cd64d43e316a1d736e5 |
|
05-Oct-2009 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #2166755: BroadcastReceiver trying to return result during a non-ordered broadcast
Tell the broadcast receiver whether it is getting an initial sticky value,
so it will be quiet about attempts to do ordered broadcast stuff.
Note that the original bug being reported was not actually a crash, just
an error log. So all we are doing here is making the log quieter.
Change-Id: Iaf1b718d82093ec1197142410a64feff47eb3859
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 5e1ab335e6e8fbfa19c64d53880a22f472010953 |
|
02-Sep-2009 |
Christopher Tate <ctate@android.com> |
Expand apps' control over the settings restore process
Applications can now specify two more aspects of the restore process: whether
they need to run with their own custom Application subclass rather than being
launched in the usual restricted mode during restore, and whether it's okay for
the backup manager to kill the app process once restore has completed. The new
manifest attributes for these are, respectively, android:restoreNeedsApplication
and android:killAfterRestore.
If unspecified in the manifest, restoreNeedsApplication is false, and
killAfterRestore is true.
In order to support kill-after-restore cleanly, this change also adds a new
system-process-only interface to the Activity Manager, which will schedule a
"commit suicide" event on the target app's main thread looper.
The framework backup agents have been given the appropriate new backup
attributes as well.
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 3025ef332c29e255388f74b2afefe05f64bce07c |
|
01-Sep-2009 |
Dianne Hackborn <hackbod@google.com> |
Various infrastructure to support a running services UI.
Some of this is temporary (in particular the two approaches for getting
process memory, one working but horrible, the other not working but
preferred) until I figure out the best way to do it.
Change-Id: I8c8f25062d481fcea22a47d459b083d2fd8a5040
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| f6f9f2d0256930ce0bb4913b2260b8480914edc2 |
|
22-Aug-2009 |
Dianne Hackborn <hackbod@google.com> |
Add more control over a service's start state.
One of the problems I have been noticing is background services
sitting around running and using resources. Some times this is
due to the app developer doing this when they shouldn't, but there
are also a number of issues with the current Service interaction
model that make it very difficult (or impossible) to avoid
getting services stuck in the started state. This is a
change/enhancement to the Service API to try to address this.
The main change is that Service.onStart() has been deprecated,
replaced with a new Service.onStartCommand() that allows the
service to better control how the system should manage it. The
key part here is a new result code returned by the function, telling
the system what it should do with the service afterwards:
- START_STICKY is basically the same as the previous behavior,
where we usually leave the service running. The only difference
is that it if it gets restarted because its process is killed,
onStartCommand() will be called on the new service with a null
Intent instead of not being called at all.
- START_NOT_STICKY says that, upon returning to the system, if
its process is killed with no remaining start commands to
deliver, then the service will be stopped instead of restarted.
This makes a lot more sense for services that are intended to
only run while executing commands sent to them.
- START_REDELIVER_INTENT is like START_NOT_STICKY, except if
the service's process is killed before it calls stopSelf()
for a given intent, that intent will be re-delivered to it
until it completes (unless after 4 or more tries it still
can't complete, at which point we give up).
Change-Id: I978f5ca420d70023d1b5e7f97de639d09381f8ad
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| d884f43ffa47f1966e9c63d1ac4722994e037c0b |
|
23-Jul-2009 |
Christopher Tate <ctate@android.com> |
BackupAgent-related lifecycle APIs need to be oneway
Bad Things(tm) happen if some of the lifecycle interfaces on IActivityThread are
oneway but others are not [notably, out-of-order method delivery, i.e.
catastrophe]. This change makes the methods added for backup-agent management
oneway like the rest of the API.
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| b06ea706530e6d19eb2a1a9a7ae6c5dd77d80af0 |
|
13-Jul-2009 |
Dianne Hackborn <hackbod@google.com> |
Add reporting of activity movement for search manager.
This adds a new API with the activity manager to find out about movement between
activities. For my sanity, the old IActivityWatcher is now renamed to
IActivityController, and the new activity movement interface is named
IActivityWatcher.
This changes the search manager itself to use the new API to manage its state.
Note that there are still problems when going back to the search dialog after
it was hidden -- the suggestions window no longer appears until you explicitly
dismiss and re-show it.
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 9c8dd55a9d829c29a3feee9469d8c2f27a9f5516 |
|
24-Jun-2009 |
Dianne Hackborn <hackbod@google.com> |
Fix bug 1829561 ("am profile" with bad filename kills process).
The am command is now the one that takes care of opening the target file,
handling the opened file descriptor to the process that will be profiled.
This allows you to send profile data to anywhere the shell can access, and
avoids any problems coming up from the target process trying to open the
file.
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 1ccac75e1f1b97eccb916a8de04fc1012b30f6e5 |
|
12-Jun-2009 |
Suchi Amalapurapu <asuchitra@google.com> |
Remove circular dependency in PackageManager. api freeStorage uses PendingIntent from android.app
Create a new public IntentSender class that can be used by PackageManager instead.
This new class uses IIntentSender internally and can only be created by PendingIntent for now.
Provide a new getIntentSender api in PendingIntent to create an instance of this class.
Move IIntentSender and IIntentReceiver from android.app to android.content
Change imports of IIntentSender and IIntentReceiver to reflect the new package name
The PackageManager api has been named as freeStorageWithIntent and will be renamed as freeStorage
once the older api(which has been deprecated) will be removed shortly.
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 1885b37913181230c36d6485bdd389f89fa90f43 |
|
05-Jun-2009 |
Christopher Tate <ctate@google.com> |
Fix backup agent unbind
The handwritten binder transaction passing wasn't propagating the agent-destroy
transaction to the client side. Oops.
Also, remove obsolete run-one-agent code from the backup manager service.
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 181fafaf48208978b8ba2022683ffa78aaeddde1 |
|
14-May-2009 |
Christopher Tate <ctate@google.com> |
Retool the backup process to use a new 'BackupAgent' class
Backups will be handled by launching the application in a special
mode under which no activities or services will be started, only
the BackupAgent subclass named in the app's android:backupAgent
manifest property. This takes the place of the BackupService class
used earlier during development.
In the cases of *full* backup or restore, an application that does
not supply its own BackupAgent will be launched in a restricted
manner; in particular, it will be using the default Application
class rather than any manifest-declared one. This ensures that the
app is not running any code that may try to manipulate its data
while the backup system reads/writes its data set.
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 06de2ea752171f52a4e6e6872cb3a0689e591dcb |
|
21-May-2009 |
Dianne Hackborn <hackbod@google.com> |
Activity Manager changes the scheduling group of processes.
The algorithm for this is currently very simple: all persistent processes are
always in the normal scheduling group, all other processes are normal if their
oom_adj is as good or better than VISIBLE, otherwise they are in the background
group.
Note that this currently results in a fair number of log messages about not
being able to change the group, since the system process does not have
permission to do so. Once a kernel fix is in, these will go away and the code
will start working.
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| f5b4b98fada53d91c4c2ebeb5a1d33ccc95c94d2 |
|
06-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@136745
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 9066cfe9886ac131c34d59ed0e2d287b0e3c0087 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| f1e484acb594a726fb57ad0ae4cfe902c7f35858 |
|
22-Jan-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@127436
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 9266c558bf1d21ff647525ff99f7dadbca417309 |
|
16-Jan-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@126645
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|
| 54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/java/android/app/ApplicationThreadNative.java
|