| Age | Commit message (Collapse) | Author |
|---|
|
Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.
Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
|
|
Change-Id: I08e9f9a2d2185ccf0c41a87c8527ea7e02ac3117
|
|
On devices without /dev/alarm, use a new backend based on timerfd.
timerfd has near-equivalent syscalls for the /dev/alarm ioctls we care
about, with two key differences:
1) /dev/alarm uses one fd for all clocks, while timerfd needs one fd per
clock type.
AlarmManagerService addresses this by replacing the fd (int) with an
opaque pointer (long) to the backend-specific state.
2) When the RTC changes, the /dev/alarm WAIT ioctl always returns, while
timerfd cancels (and signals events) only on specially-flagged RTC
timerfds.
The timerfd backend masks this by creating an extraneous RTC timerfd,
specifically so there's always something to signal on RTC changes.
Change-Id: I5aef867748298610347f6e1479dd8bf569495832
Signed-off-by: Greg Hackmann <ghackmann@google.com>
|
|
Provide an abstract class for system services to extend from,
similar to the android.app.Service.
This will allow services to receive events in a uniform way,
and will allow services to be created and started in the
correct order regardless of whether or not a particular
service exists.
Similar to android.app.Service, services are meant to implement
Binder interfaces as inner classes. This prevents services from
having incestuous access to each other and makes them use the
public API.
Change-Id: Iaacfee8d5f080a28d7cc606761f4624673ed390f
|
|
...even if the new one is later than some other existing alarms.
Bug 11392699
Change-Id: I80dccd76300acb4729f0337665b91e897a770571
|
|
The existing code wasn't retaining the requested window bounds, if any,
and so could wind up rebatching alarms into much longer potential
delivery windows than originally demanded by the caller. This could
wind up delivering alarms outside their designated windows entirely.
Bug 11324357
Change-Id: I4d418cd08702e397b3c7692b412d4bf51d5d9e4b
|
|
Bug 10746233
Change-Id: I18c84f2bd53a511fc86be42b5d72062650e5b289
|
|
Backing until you hear glass is generally contraindicated.
Bug 10056484
Change-Id: Ie1331fbbc5fbb5d6384a6cfc975aa1840a5c9a2d
|
|
...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
|
|
They have served their purpose.
Bug 10112313
Change-Id: Ia88c350c5b51bdd29f23f491b47e4188770b1ea0
|
|
Change-Id: I663ea3078d405f0fa667a04bdaa376ae6652e994
|
|
Bug 10056484
Change-Id: I527f592b0bb91bfbfff1d52c3327fe9e2ac53471
|
|
For apps build against the KLP+ SDK, this will now throw an illegal argument
exception. Legacy apps will simply see the alarm delivered immediately.
Bug 9965704
Change-Id: Ia103d9529d32640098be324820fe228efa95431d
|
|
Bug 10055940
Change-Id: I75bcbdf6177f5faa41f420518513a22f47bcac5e
|
|
Also: turn off verbose logging, but enable a new debugging
consistency check.
Bug 9965704
Change-Id: Ib20fb8b6275b77ff98291cf12a43b2a1128ab4b9
|
|
This reverts commit 02600fb66b805c161e35f6c787372e4074f2213f.
Broke some tests.
Change-Id: Ic47b23a935bf90aba817073c27cd247306db7d5f
|
|
Change-Id: Ibcff01a9f54a89fde6e7e5b7658e9a90b9a2445b
|
|
Bug 9965704
Change-Id: I18111682664a069c2dc4fd956df49a02e2c455a8
|
|
Bug 9965704
Change-Id: I41819bd1da16cc61c54938ed4ddd421f15b56fbb
|
|
Bug 9532215
Change-Id: I0efe32cbaaae8ce6ab223041eed116c3470a7326
|
|
Bug 9940349
Change-Id: I60205899cd33070394752fc4b2f1e0cf6a2d9192
|
|
The default Alarm Manager behavior for KLP+ apps will be to aggressively
coalesce alarms, trading exact timeliness of delivery for minimizing the
number of alarm-delivery points, especially wakeup points.
There is new API in AlarmManager, setExact() and setExactRepeating(),
for use by apps that absolutely *must* get their alarms at a specific
point in time.
Bug 9532215
Change-Id: I40b4eea90220211cc958172d2629664b921ff051
|
|
Keeps one day of alarm history, and for each one puts a line in dumpsys:
RTC timestamp, millis since previous wakeup alarm, uid, and intent action
Bug 9532215
Change-Id: Ib4fb41aa6291a4cf8f3301bfebf7974e99a9d52c
|
|
Yay to ArrayMap, letting me get rid of a bunch of temporary
iterators in core code paths like updateOomAdj. (Now I definitely
need an ArraySet to finish that up.)
Also clean up various other things that are doing unnecessary
allocations, clean up some debug output, make more of the debug
output respect package filtering.
Change-Id: Ib4979faf4de8c7912739bc0937c3fa9e7bfcde67
|
|
* commit 'a3e7919932199e2178792cbae8870e9b48c57523':
TIME_TICK was not occurred for one hour
|
|
TIME_TICK was not occurred at the end of DST for one hour
Step to reproduce:
1. Settings -> Date & time
2. uncheck Automatic date & time and Automatic time zone
3. select Time zone -> select Brussels
4. set date -> Oct. 28. 2012
5. set time -> 1:59 AM
Bug: 7922117
Change-Id: I2e78bd97b508d6a38471425cfbaca45fb4b89c1e
|
|
In alarm manager, print a summary of the top 10 alarms by time
being executed. Keep track of execution time (and wake count) of
each type of alarm for each application so this can be printed in
the summary (and used to compute the top 10 alarms). Rework how
the alarm summary stats are tracked so that we don't need to hold
on to the full Intent for each stat and can get the Intent information
at the time the alarm is sent rather than waiting for whatever Intent
comes back in the result.
Also in the battery stats: sort the kernel wake locks by time, add
a new section showing all partial wake locks across all applications
sorted by time.
Finally a new LocalLog class that is used by AlarmManager to log
important warning messages, so these can also be later found in
its dumpsys output.
Change-Id: Icc07810053e60fb623a49937e696819cb8352b06
|
|
Change-Id: Iaa8de2d3732bffd63fcd4fafba50955d1776611d
|
|
7173152 API REVIEW: android.content.pm.PackageUserState
7172969 API REVIEW: android.app.PendingIntent
7172730 API REVIEW: android.content.Context
7172726 API REVIEW: android.manifest.permission
Change-Id: Iad470256d3b5ca5596487f6a699ec1871457c3b5
|
|
...otherwise you crash trying to send a broadcast to all users.
Change-Id: If627eeb3eadb1052242c986fe24482d87c8fc093
|
|
You can now use ALL and CURRENT when sending broadcasts, to specify
where the broadcast goes.
Sticky broadcasts are now correctly separated per user, and registered
receivers are filtered based on the requested target user.
New Context APIs for more kinds of sending broadcasts as users.
Updating a bunch of system code that sends broadcasts to explicitly
specify which user the broadcast goes to.
Made a single version of the code for interpreting the requested
target user ID that all entries to activity manager (start activity,
send broadcast, start service) use.
Change-Id: Ie29f02dd5242ef8c8fa56c54593a315cd2574e1c
|
|
The activity manager now keeps track of which users are running.
Initially, only user 0 is running.
When you switch to another user, that user is started so it is
running. It is only at this point that BOOT_COMPLETED is sent
for that user and it is allowed to execute anything.
You can stop any user except user 0, which brings it back to the
same state as when you first boot the device. This is also used
to be able to more cleaning delete a user, by first stopping it
before removing its data.
There is a new broadcast ACTION_USER_STOPPED sent when a user is
stopped; system services need to handle this like they currently
handle ACTION_PACKAGE_RESTARTED when individual packages are
restarted.
Change-Id: I89adbd7cbaf4a0bb72ea201385f93477f40a4119
|
|
Wakelock usage for the purpose of sending an alarm broadcast is now
attributed to the application which posted the alarm, not to the OS.
Bug 5911317
Change-Id: I8cb79c3bd5db467388716ab68285f4ab0bfe468b
|
|
Allows applications to propagate multiple URI grants through an
Intent.
Later on, we should probably redefine the share actions to be
based on this ClipData with the old extras-based approach only
there for compatibility. Even if we don't do that, though, this
allows you to do a multi-select share that grants multiple URI
permissions by stuffing the URIs in a ClipData.
Also add some documentation in various places telling people how
they can grant URI permissions.
Change-Id: Id4ba8e72c11caf7e1f1f438cb7af058d1586a37c
|
|
...Should Skip Unsecure Lockscreen (ICS)
Also while I am in there, clean up logging of intent objects to include
even less sensitive information, while showing the true Intent in dump
output (since apps can't get to that).
Change-Id: I35fed714645b21e4304ba38a11ebb9c4c963538e
|
|
Change to use a real item alarm for scheduling ACTION_TIME_TICK
intents for the case where time goes backwards after the tick intent
is schedule, and where the time change is not noticed from the call
to waitForAlarm().
Bug: 5166877
Change-Id: I46b9a1c80146d27becedc341c4af977fcdf47352
|
|
calculating timezone"
* commit 'c1b62e3ba91d69dd75569b480aec55be8f808331':
Check if we are in daylight time when calculating timezone
|
|
The code that calculates the Kernel TimeZone does not check
if we are actually in daylite time prior updating the kernel
time zone. Use TimeZone.getOffset which checks for daylight
savings. Also updated setTimeZone for consistency.
Change-Id: I44565bc8df48e81370ea3bfbb099a6a5675e343d
|
|
The previous implementation failed to properly distinguish between
trigger times in the RTC vs the ELAPSED time bases. The pernicious
result of this was that sometimes it would decide to align RTC
alarms based on, say, 0 rather than on the real current time.
This would pull the recurrence into wall-clock alignment, with
serious side effects: in particular, periodic tasks that would hit
external network resources would, because *all* devices would be
pulled into wall-clock alignment, wind up inducing heavy QPS
spikes on the backends.
The new implementation works completely differently. The basic
goal is the same: try to align inexact alarms to "the same" time,
avoiding extra wakeups / radio spinups / etc. The way this is done
is to divide the timeline into 15-minute quanta, and drift the start
time of every inexact alarm onto one of these 15-minute quantum
boundaries. The skew between the RTC and ELAPSED time bases is
taken into effect; RTC alarms are no longer pulled into wall clock
alignment.
Fixes bug 3388961
Change-Id: I2a0460e1f5d0e4036f3402f332b642b557b2fc20
|
|
And also fix #3343369: EGL_BAD_DISPLAY and/or broadcast intent
TIME_SET before boot completion
And a few more tweaks to animations to keep the wallpaper displayed
when needed.
And make more use of the drag and drop "rotation disabled" thing to
also use it while animating the screen rotation, since if we try to
start a new rotation while doing the animation we end up with a mess.
Change-Id: I373af305a6e23a92835abed96229a83e173f67ce
|
|
Merge commit 'fb1e5529724d121aa47485e7245b69965088fbb4' into gingerbread-plus-aosp
* commit 'fb1e5529724d121aa47485e7245b69965088fbb4':
Fix time zone info in kernel is nothing after reboot
|
|
com.android.settings.widget.SettingsAppWidgetProvider
Exposes an Intent I need (okay it fixes an unrelated thing in the power widget),
and fixes some dump output.
Change-Id: I51d6c93a6ac879bab64e9d5aa21129e2bbcd461b
|
|
If sys_tz is not set correctly, the timestamp of
filesystem will be in-consistent with android's time,
until time zone is set from android's UI. Set kernel
timezone while initializing AlarmManagerService.
Change-Id: Ic85def954fc9388e943e3dee45767d8179825a49
|
|
When the wakeup time is negative, the kernel /dev/alarm driver
never triggers the alarm. This can cause alarms to back up in the
priority queue since an alarm at the head with a negative wakup time
will never be triggered. Now we use 0 as the wakup time which causes
an immediate triggering.
When the wakeup time is very large, it is possible for a numeric
overflow to occur when converting the timestamp from milliseconds
since epoch to nanoseconds. This has been fixed by avoiding the
intermediate conversion in the JNI call so that overflow cannot
occur.
Bug: b/2558820
Change-Id: I4f5b4646a04090cc749a9fc5d3982a68402954ef
|
|
Change-Id: I296e6587aa1bb391e748ff4bb5649dcfa6ebbc24
|
|
|
|
setting
I am getting tired of writing package monitor code, realized this is missing in
a number of places, and at this point it has gotten complicated enough that I
don't think anyone actually does it 100% right so:
Introducing PackageMonitor.
Yes there are no Java docs. I am still playing around with just what this
thing is to figure out what makes sense and how people will use it. It is
being used to fix this bug for monitoring voice recognizers (integrating the
code from the settings provider for setting an initial value), to replace
the existing code for monitoring input methods (and fix the bug where we
wouldn't remove an input method from the enabled list when it got
uninstalled), to now monitor live wallpaper package changes (now allowing
us to avoid reverting back to the default live wallpaper when the current
one is updated!), and to monitor device admin changes.
Also includes a fix so you can't uninstall an .apk that is currently enabled
as a device admin.
Also includes a fix where the default time zone was not initialized early
enough which should fix issue #2455507 (Observed Google services frame work crash).
In addition, this finally introduces a mechanism to determine if the
"force stop" button should be enabled, with convenience in PackageMonitor
for system services to handle it. All services have been updated to support
this. There is also new infrastructure for reporting battery usage as an
applicatin error report.
|
|
Add checks for fwdlocked and updated system apps
add more tests
remove duplicate adds
|
|
|
|
Add new broadcasts ACTION_MEDIA_RESOURCES_AVAILABLE and
ACTION_MEDIA_RESOURCES_UNAVAILABLE that get broadcast by
PackageManagerService when sdcard gets mounted/unmounted
by MountService so that packages on sdcard get recognized by
various system services as being installed/available or
removed/unavailable by the system.
The broadcasts are sent before the actual package cleanup which includes
mounting/unmounting the packages and we force a gc right after so
that any lingering file references to resources on sdcard get
released.
|
