Prevents the TrustManagerService from binding to any non-platform
trust agents and updates the SampleTrustAgent to use the new
permission.
Bug: 15287044
Change-Id: I38c3deebd5ad359075e68f52d19417bab5ab43db
Mechanism to register a provider for requesting an
administrator to respond to permission requests.
Request format and response format constants.
Description of manifest template for static restrictions.
Int type introduced in RestrictionEntry.
Needs more javadoc and better description of manifest templates,
including specifying the XML attributes.
Change-Id: I5a654d364e98379fc60f73db2e06bf9a8310263d
Revert the following changes from the I/O preview. This reverts the
following changes:
Revert "Revert "Revert "Modify TelephonyManager to expose sendEnvelopeWithStatus instead of sendEnvelope."""
This reverts commit 452e185fb6df92358701fb68d4fe6c65f172cc29.
Change-Id: I6bbff508b2f542d6ef3d372956db53d63a9165eb
Revert "Revert "Revert "Expose sendEnvelope."""
This reverts commit 0d5e5b9cce8af40494f72ff9decc169f99780254.
Revert "Adding support for SIM communication from Android over logical channels."
This reverts commit 57f656b9f6271cf857b5ecec5f8c7eacb321ec0b.
Change-Id: I975eb468841e85d63e506f68a5d8c879e110d9f6
This will be re-added as a Trustlet in a subsequent CL.
This reverts commit 38a7ed05f8fed0aa81f7214d827875f9876ffbe1.
Change-Id: I5aa36df42a7751f165b4ef184e0cda57e5568b59
This renames several of the core session classes to be prefixed
with Media. It also adds @hide to all route references for now.
Change-Id: Idb42897d490cf24626e4e93ca975b2cb93ec054c
This reverts a temporary hack which was required for a temporary launcher version to work for development purposes.
Change-Id: Ifd17447076bf5c67ad2ce8df8f184fe6f12baad3
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
The package manager service maintains, for some user ids, a list of forwarding intent filters.
A forwarding intent filter is an intent filter with a destination (a user id).
If an intent matches the forwarding intent filter, then activities in the destination can also respond to the intent.
When the package manager service is asked for components that resolve an intent:
If the intent matches the forwarding intent filter, and at least one activity in the destination user can respond to the intent:
The package manager service also returns the IntentForwarderActivity.
This activity will forward the intent to the destination.
Change-Id: Id8957de3e4a4fdbc1e0dea073eadb45e04ef985a
Add the condition provider interface, base class, and associated
system metadata.
Pull out common service management code into a reusable helper,
used by notification listeners and condition providers. The
helper, ManagedServices, is now completely self-contained - it
has no dependencies on NoMan or NoMan abstractions.
Bug:13743109
Change-Id: I6856d40f0a2ead78ac9b5707568559a57e7eb009
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
Compiles and works with OneMedia. This currently is a rough test of
the system for finding, connecting to, and sending messages to routes.
This will just connect to the first route it finds when a request to
open the route picker is made (and disconnect when another request is
made).
Change-Id: I5de5521a079471b9e02664be4654c0591dfd9a6d
Simple wrapper around the UserManager.{get|set}ApplicationRestrictions
APIs. Also added a new Intent to signal to running apps that the set
of restrictions has changed since startup.
Change-Id: Ifd108108a73f87325b499d9de2e1b2aacc59b264
NetworkScoreManager defines all interactions between the framework and
the scorer app. An ACTION_SCORE_NETWORKS broadcast is sent to the
default scorer with any unscored networks, which responds by calling
updateScores() with scores for those networks. An app may also check
whether they are currently the default scorer with
getDefaultScorerPackage() and request to become the default via the
ACTION_CHANGE_DEFAULT broadcast.
Bug: 13786258
Change-Id: Id3dc0f7c1109f0e3afd73356e2475b7f34167419
* commit '8ebd66c259602f6b0be26fdfd3fe2f55538f6424':
Add stringType and requiredPermissions to SensorManager.java, as well as a permission for the heart rate sensor
* commit 'cd4c1c714c37a1bc7ba35ebd2509eca4f0f6a314':
Add stringType and requiredPermissions to SensorManager.java, as well as a permission for the heart rate sensor
This provides APIs to control and create individual television inputs on
the system which will later be hosted by television applications.
Change-Id: I6866d28e78175a1bff2c32a85c5d77e94d0cd60c
* commit '819239e5bec90ee3c861ac45fffac4a832a183a1':
Revert "Add stringType and requiredPermissions to SensorManager.java, as well as a permission for the heart rate sensor"
* commit 'bdfe384106de364ea2effac6ab80108556d11649':
Add stringType and requiredPermissions to SensorManager.java, as well as a permission for the heart rate sensor
* commit 'fd53d8352a4617941b0a0449390aa562a01ea1d3':
Add stringType and requiredPermissions to SensorManager.java, as well as a permission for the heart rate sensor
Adds the TrustManager system service that allows
registering for changes to the trust status and
reporting events that are important to trust agents.
Bug: 13723878
Change-Id: I7d0d2ea86fd755702d31aa5d49cac038a6cd4301
Backup/restore now supports app widgets.
An application involved with app widgets, either hosting or publishing,
now has associated data in its backup dataset related to the state of
widget instantiation on the ancestral device. That data is processed
by the OS during restore so that the matching widget instances can be
"automatically" regenerated.
To take advantage of this facility, widget-using apps need to do two
things: first, implement a backup agent and store whatever widget
state they need to properly deal with them post-restore (e.g. the
widget instance size & location, for a host); and second, implement
handlers for new AppWidgetManager broadcasts that describe how to
translate ancestral-dataset widget id numbers to the post-restore
world. Note that a host or provider doesn't technically need to
store *any* data on its own via its agent; it just needs to opt in
to the backup/restore process by publishing an agent. The OS will
then store a small amount of data on behalf of each widget-savvy
app within the backup dataset, and act on that data at restore time.
The broadcasts are AppWidgetManager.ACTION_APPWIDGET_RESTORED and
ACTION_APPWIDGET_HOST_RESTORED, and have three associated extras:
EXTRA_APPWIDGET_OLD_IDS
EXTRA_APPWIDGET_IDS
EXTRA_HOST_ID [for the host-side broadcast]
The first two are same-sized arrays of integer widget IDs. The
_OLD_IDS values are the widget IDs as known to the ancestral device.
The _IDS array holds the corresponding widget IDs in the new post-
restore environment. The app should simply update the stored
widget IDs in its bookkeeping to the new values, and things are
off and running. The HOST_ID extra, as one might expect, is the
app-defined host ID value of the particular host instance which
has just been restored.
The broadcasts are sent following the conclusion of the overall
restore pass. This is because the restore might have occurred in a
tightly restricted lifecycle environment without content providers
or the package's custom Application class. The _RESTORED broadcast,
however, is always delivered into a normal application environment,
so that the app can use its content provider etc as expected.
*All* widget instances that were processed over the course of the
system restore are indicated in the _RESTORED broadcast, even if
the backing provider or host is not yet installed. The widget
participant is responsible for understanding that these are
promises that might be fulfilled later rather than necessarily
reflecting the immediate presentable widget state. (Remember
that following a cloud restore, apps may be installed piecemeal
over a lengthy period of time.) Telling the hosts up front
about all intended widget instances allows them to show placeholder
UI or similarly useful information rather than surprising the user
with piecemeal unexpected appearances.
The AppWidgetProvider helper class has been updated to add a new
callback, onRestored(...), invoked when the _RESTORED broadcast
is received. The call to onRestored() is immediately followed by
an invocation of onUpdate() for the affected widgets because
they will need to have their RemoteViews regenerated under the
new ID values.
Bug 10622506
Bug 10707117
Change-Id: Ie0007cdf809600b880d91989c00c3c3b8a4f988b
1. The old introspection model was allowing querying only the active window
which is the one the user is touching or the focused one if no window is
touched. This was limiting as auto completion drop downs were not inspectable,
there was not way to know when the IME toggles, non-focusable windows were
not inspectable if the user taps them as until a screen-reader starts
introspecting the users finger is up, accessibility focus was limited to
only one window and the user couldn't use gestures to visit the whole UI,
and other things I can't remember right now.
The new APIs allow getting all interactive windows, i.e. ones that a
sighted user can interact with. This prevents an accessibility service
from interacting with content a sighter user cannot. The list of windows
can be obtained from an accessibility service or the host window from an
accessibility node info. Introspecting windows obey the same rules for
introspecting node, i.e. the service has to declare this capability
in its manifest.
When some windows change accessibility services receive a new type
of event. Initially the types of windows is very limited. We provide
the bounds in screen, layer, and some other properties which are
enough for a client to determined the spacial and hierarchical
relationship of the windows.
2. Update the documentation in AccessibilityService for newer event types.
3. LongArray was not removing elements properly.
4. Composite accessibility node ids were not properly constructed as they
are composed of two ints, each taking 32 bits. However, the values for
undefined were -1 so composing a 64 long from -1, -1 prevents from getting
back these values when unpacking.
5. Some apps were generating inconsistent AccessibilityNodeInfo tree. Added
a check that enforces such trees to be well formed on dev builds.
6. Removed an necessary code for piping the touch exploration state to
the policy as it should just use the AccessibilityManager from context.
7. When view's visibility changed it was not firing an event to notify
clients it disappeared/appeared. Also ViewGroup was sending accessibility
events for changes if the view is included for accessibility but this is
wrong as there may be a service that want all nodes, hence events from them.
The accessibility manager service takes care of delivering events from
not important for accessibility nodes only to services that want such.
8. Several places were asking for prefetching of sibling but not predecessor
nodes which resulted in prefetching of unconnected subtrees.
9. The local AccessibilityManager implementation was relying on the backing
service being ready when it is created but it can be fetched from a context
before that. If that happens the local manager was in a broken state forever.
Now it is more robust and starts working properly once the backing service
is up. Several places were lacking locking.
bug:13331285
Change-Id: Ie51166d4875d5f3def8d29d77973da4b9251f5c8
