Since these alarms allow you to bypass the idle restrictions,
we don't want them to be so open-ended like other alarms. This
implements a policy where the alarm manager will only deliver these
types of alarms every X minutes to each application. For this
initial implementation, X is 1 minute under normal operation and
15 minutes when in idle mode.
To do this, I needed to introduce a new internal allow-while-idle
flag for system alarms, which applications can't get, and doesn't
have these new restrictions.
Also tweaked how the alarm manager handles the alarm window, so it
doesn't change if the alarm gets rescheduld; the window is now always
what as computed based on the time when the alarm was first
given to it.
Finally, fix TimeUtils to be able to correctly print times that
are > 999 days.
Change-Id: Ibad8c6a7c14b0624b54e82267be23224b4c31e84
The fact that currently apk signature is certificates is just
implementation details.
Bug: 20820366
Change-Id: Icdd02cb51a550ea71ff83a84e2bdfcc21f8d43ed
Issue #21039494: API Review: android.os.PowerManager.isDeviceIdleMode()
Issue #21347000: API Review: android.content.IntentFilter
Issue #20654534: API Review: android.app.assist
Also allow use of ActivityManager.setWatchHeapLimit on any platform
build as long as the calling app is debuggable.
Change-Id: Ic597e596fa772fcdf2553b64f444b3d9269e8b92
SYSTEM_INTERACTION events are signals to the system for a package's
implicit actions (service bound, etc).
These should not affect the API visible stats like lastTimeUsed, etc.
USER_INTERACTION is for user initiated actions (notification interaction, etc).
Bug:21761781
Change-Id: I4585cf35fbb158612a3c737710108bec34e89183
If an application has native code (and primary abi)
include path to corresponding folder inside apk-file
to ldLibraryPath when constructing PathClassLoader
Bug: 21647354
Bug: 21667767
Bug: 21726698
Bug: 8076853
Change-Id: Ib0a2f01ee69019d3206a00c542bd7d0f58d0c481
Add new APIs to associate a Request with a name, get all active
requests, and get active request by name.
Also add a new Activity.onProvideReferrer() which will allow
applications to propagate referrer information to the assistant
(and other apps they launch) in a consistent way.
Change-Id: I4ef74b5ed07447da9303a74a1bdf42e4966df363
Currently lock task modes started by the activity flag
android:lockTaskMode behave differently from those started using
startLockTask(). With those changes lock tasks initiated by non-priv
apps cannot finish without calling into stopLockTask. Revoking the
whitelisting on a locked task will also kill that task, independently
of the way the lock task mode was started.
Bug: 21608206
Change-Id: I841abf1103855e2d7218a4a8ca9b43c105630dc9
...services get out of app idle
Introduce a new process state to even better distinguish foreground
services from other states. Rework the INTERACTION reporting to
usage stats to do it less when the screen is off -- require that
an app sit in the foreground service or top activity state for
at least 30 minutes before we consider it an interaction.
Also eradicate a bunch of logging in package manager.
Change-Id: I94249e67f9a9c62e9a92ae104710e6747b16327e
- User flow is now similar to requesting access to notification
content, namely prompting the user to visit a settings page
for enabling/disabling apps access.
- New ACTION_NOTIFICATION_POLICY_ACCESS_GRANTED_CHANGED intent
for apps to listen to this state change.
- Removed obsolete request method and associated internal callback
aidl.
- Added new android.permission.ACCESS_NOTIFICATION_POLICY permission
for apps to include as a signal that they want to request this access
(and therefore appear in the list on the settings page).
- Improve javadocs, outline the user flow in NotificationManager#isNotificationPolicyAccessGranted
and link to this method elsewhere.
- NoManService now persists the user-enabled package list across reboots
and does so per-user.
- Rename public settings intent to correspond with the noman api.
Bug: 21621663
Change-Id: I72cbc21cd736e6a157b6be5d1d0ba0b4a8e7ef4e
Per java doc of java.lang.Process, #destroy() should be called
after the parent process is done with the sub process.
Bug: 20435160
Change-Id: I254982388c5b46c93c214b37a1e8563f21805e82
We were previous only taking the Configuration into account when
creating Display objects in the ResourceManager. This led to the
Display object not containing critical CompatibilityInfo. We now
take the entire DisplayAdjustment into account.
Bug: 21637615
Change-Id: Ide5ff49bfa12791ad17993764f312836216b1dd8
Simplifies behavior wrt automatically setting the
web URI for ACTION_VIEW Intents, by not doing so
for custom Intents.
Adds a boolean isAppProvidedIntent() as a signal for
recepients of the AssistContent that a custom Intent
was provided. Custom Intents are more likely to be
relevant.
Change-Id: Ibe4bfa040eba904411b9820ab4ddfcf509413829
* Introduce VoiceInteractor.Prompt, holding multiple voice prompts
("What genre?", "What genre of music?", "What genre of music, for
example classical?") as well as a different visual prompt to show
on screen ("Choose genre").
* Migrate framework voice interactor code from a CharSequence prompt
to Prompt.
Bug: 21024958
Change-Id: Ib595fbdb2801cc558085e9b8366d619ff1d4d656
This patch adds a send-trim-memory command to the ActivityManager to allow
for better debugging&testing.
The command is
adb shell am send-trim-memory [--user <USER_ID>] <PROCESS> <LEVEL>
whereas LEVEL can be one of the following:
[HIDDEN|RUNNING_MODERATE|BACKGROUND|RUNNING_LOW|MODERATE|
RUNNING_CRITICAL|COMPLETE]
Bug: 21633189
Change-Id: I7a41ce02c3c9043ffd3e5aaa791f7b7306a9de49
In order to track the input device that was used to trigger assist, the
input device id is sent as an extra in the assist intent whenever it is
available. This is particularly useful on TVs, when an app may want to
know whether the input device has a microphone.
Bug: 21666123
Change-Id: I0f8c09e2f617606bef481bdff924cb6b9b47dd12
