Changing Configuration first and then testing for changes yields a
result indicating no change.
Fixes bug 12904769.
Change-Id: If7e39e843f15b1143d9877497d595511afabd020
We now try to have a better label for the first wake lock
that is acquired in the log. This is done in two ways:
- The alarm manager now sorts the alarms it is going to
execute so that wakeup alarms are first, which are more
important w.r.t. which one should be logged.
- There is a new power manager facility to make a wake lock
as "unimportant for logging," which just means in battery
stats that a wake lock acquired after that can be considered
the actual one to log. This is only used by the alarm manager
to mark its TIME_TICK alarms as unimportant for logging.
Also reworked the battery history code to be cleaner and a bit
smaller. There is no longer a separate EVENT command, instead
the event code and tag are just another thing that can be included
in an UPDATE command.
The bits used in the first history int are also re-arrange, so
that only the ones that really change a fair amount in the state
bits are up at the top and there is no longer space used for
the command code (since now it is always just UPDATE). This
allows us to have more room for the time delta at the bottom,
to better avoid situations where we need to write an int delta.
Change-Id: I1bb860ae5b558a248800b090b03a84fbf7acd68a
Allowing the detach of ActivityStack from DisplayContent to happen
immediately was causing all sorts of problems associated with not
having a Display to complete the animations.
Waiting for animations to complete before either the detach or the
display removal fixes those problems.
Change-Id: I8a5663bfac5c3c1084ff4fcc451e0e38e8080265
Now that activities and tasks can be detached from a display do not
keep their state within the DisplayContent class. All such state is
now moved to the TaskStack class with this change.
Change-Id: Ie6b1811e9ec3f545782bad8c3461bd4f2d336b93
At startup, we check with PackageManager whether a system service is
available before attempting to load it. A system service is available
if its associated feature (similar to hardware features) is present.
This does not remove unavailable services from the compiled jar.
Change-Id: I13571805083aa4e65519a74acb52efd17b9fb3d7
PendingIntents and IntentSenders can now be launched. Still does not
work once the host activity has been paused and resumed.
Window manager TaskStacks now exist independently of Displays and app
windows persist after Displays are removed below them. Attaching the
stack to a new Display does not yet restore the windows to it.
Fixes bug 12747909.
Change-Id: I509007ee23fda400b353f483cf6ecce08177763b
Add new RIL commands and generic code cleanups.
The only changes required for OMA DM support are the
addition of five new methods in ITelephony.aidl for
reading/writing NV items and performing NV config and
radio resets (requires MODIFY_PHONE_STATE), along with
the new RIL request IDs in RILConstants.java.
Bug: 12864208
Change-Id: I958d2571580d98a49936ef2e6822e5ac086acbe2
When an application wishes to do low-priority background work when the
device is otherwise idle (e.g. in a desk dock overnight), it declares
a service in its manifest that requires this permission:
android:permission="android.permission.BIND_IDLE_SERVICE
to launch, and which publishes this intent filter:
<intent-filter>
<action android:name="android.service.idle.IdleService" />
</intent-filter>
This string is declared in the API as IdleService.SERVICE_INTERFACE.
The service must be implemented by extending the new "IdleService"
class, which provides the API through which the system will communicate
with the app.
IdleService declares three methods, two of which are lifecycle callbacks
to the service, and the third of which is for the service itself to
invoke when appropriate. The lifecycle callbacks are
public abstract boolean onIdleStart();
public abstract void onIdleStop();
The first of these is a notification to the service that an idle
maintenance interval has begun. The service can then spin off
whatever non-UI work it wishes. When the interval is over, or if
the OS determines that idle services should be shut down immediately,
the onIdleStop() method will be invoked. The service must shut down
any background processing immediately when this method is called.
Both of these methods must return immediately. However, the OS
holds a wakelock on the application's behalf for the entire period
between the onIdleStart() and onIdleStop() callbacks. This means
that for system-arbitrated idle-time operation, the application does
not need to do any of its own wakelock management, and does not need
to hold any wakelock permissions.
The third method in IdleService is
public final void finishIdle();
Calling this method notifies the OS that the application has finished
whatever idle-time operation it needed to perform, and the OS is thus
free to release the wakelock and return to normal operation (or to
allow other apps to run their own idle services).
Currently the idle window granted to each idle service is ten minutes.
The OS is rather conservative about when these services are run; low
battery or any user activity will suppress them, and the OS will not
choose to run them particularly often.
Idle services are granted their execution windows in round-robin
fashion.
Bug 9680213
Change-Id: Idd6f35940c938c31b94aa4269a67870abf7125b6
* commit 'af17925f94c3a293022a4c41fc284a0a9312dcb6':
[ActivityManager]: Fix the activity visibility state not sync between ActivityManager and WindowManager
* commit '45b68ac3a7acb7af95fdfc5c0e31560b3c28c9f8':
[ActivityManager]: Fix the activity visibility state not sync between ActivityManager and WindowManager
This a merger of two commits submitted to AOSP by
the following authors:
ashok.bhat@arm.com, david.butcher@arm.comacraig.barber@arm.com, kevin.petit@arm.com and
marcus.oakland@arm.com
Due to the very large number of internal conflicts, I
have chosen to cherry-pick this change instead
of letting it merge through AOSP because the merge
conflict resolution would be very hard to review.
Commit messages below:
================================================
AArch64: Make graphics classes 64-bit compatible
Changes in this patch include
[x] Long is used to store native pointers as they can
be 64-bit.
[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)
[x] AssetAtlasManager is not completely 64-bit compatible
yet. Specifically mAtlasMap member has to be converted
to hold native pointer using long. Added a TODO to
AssetAtlasManager.java to indicate the change required.
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
==================================================================
AArch64: Use long for pointers in graphics/Camera
For storing pointers, long is used in
android/graphics/Camera class, as native
pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use of
jint instead of int in JNI function prototypes)
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
===================================================================
Change-Id: Id5793fa0ebc17ee8b1eecf4b3f327977fdccff71
The ACTION_EXTERNAL_APPLICATIONS_UNAVAILABLE broadcast now uses the
EXTRA_REPLACING intent extra when it is sent as part of an upgrade operation
on a forward-locked application. Update PackageMonitor to recognize this
new information and express it appropriately to the observer.
Bug 11988313
Change-Id: I34dfaa965dd322f4fa8945e7b83c9f2e8cf5269a
This a merger of two commits submitted to AOSP by
the following authors:
ashok.bhat@arm.com, david.butcher@arm.comacraig.barber@arm.com, kevin.petit@arm.com and
marcus.oakland@arm.com
Due to the very large number of internal conflicts, I
have chosen to cherry-pick this change instead
of letting it merge through AOSP because the merge
conflict resolution would be very hard to review.
Commit messages below:
================================================
AArch64: Make graphics classes 64-bit compatible
Changes in this patch include
[x] Long is used to store native pointers as they can
be 64-bit.
[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)
[x] AssetAtlasManager is not completely 64-bit compatible
yet. Specifically mAtlasMap member has to be converted
to hold native pointer using long. Added a TODO to
AssetAtlasManager.java to indicate the change required.
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
==================================================================
AArch64: Use long for pointers in graphics/Camera
For storing pointers, long is used in
android/graphics/Camera class, as native
pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use of
jint instead of int in JNI function prototypes)
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
===================================================================
Change-Id: Ib3eab85ed97ea3e3c227617c20f8d213f17d4ba0
Now the per-package proc stats data is also per-app-version-code.
In addition to changing the data structure to have one more
SparseArray and passing a version code all over, this also required
improving how we reset the stats so that we can prune a multi-package
process record back to a single package. Otherwise, as you install
updates to apps, the proc stats data would continue to explode as
the data for each of those app's processes got turned to a
multi-package due to tracking the old and new versions at the
same time.
This also bumps the checkin version code, since the package entries
also include a new field for the app version code.
Change-Id: I80de36addb0a75c7b08aef747c6f6c8012d01ee4
- Adjust total power use when there is unaccounted power so that our
percentages don't end up > 100%.
- Fix accounting of isolated uids to be against the owning real app
uids.
- Rework how we put cpu use into the battery stats to no longer need
this uid name cache that can confuse the uid it is associated with.
- Finish implementing events in the history, adding a string pool and
reading/writing/dumping them.
- Add first two events: processes starting and finishing.
- Fix alarm manager reporting of wakeup alarms to be adjusted by the
WorkSource associated with the alarm, so they are blamed on the
correct app.
- New "--history" dump option allows you to perform a checkin of
only the history data.
- Fixed BitDescription bug that would cause incorrect printing of
changes in some states.
Change-Id: Ifbdd0740132ed178033851c58f165adc0d50f716
Transform DisplayManagerService into a SystemService and start cleaning
up other local services that it uses from window manager and input manager.
Clean up service thread initialization.
Remove unnecessary static variables from ActivityManagerService.
It's starting to become clear that we really need a better way to manage
service dependencies. Boot phases don't quite cut it.
Change-Id: If319dbd7cbfbd4812fe55ece969e818d4b20755b
