A network subsystem (e.g. Wi-Fi) will be responsible for implementing
INetworkScoreCache. NetworkScoreService will load caches for each
configured network subsystem. When it receives a call to update
scores, it will separate the networks by type and call updateScores on
the appropriate INetworkScoreCache.
Each subsystem will also be responsible for requesting scores for new
networks by calling NetworkScoreManager#requestScores.
Bug: 14408144
Bug: 14137255
Change-Id: I76e5e5205bc359c39d6b9c1782126fb7f465cd96
On the app side, requests are now composed by subclassing
from various types of Request objects.
On the service side, starting a voice interaction session
involves starting another service that will then manage the
session. This leads the service design much more to what
we want, where the long-running main service is very tiny
and all the heavy-weight transient session work is elsewhere
in another process.
Change-Id: I46c074c6fe27b6c1cf2583c6d216aed1de2f1143
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
This is a very barebones first pass, meant to ensure we're all on the
same page, and also get feedback.
Change-Id: I7d5492dc5aafbe583f7c2d97ebf1444b6d2e068a
This service will ultimately be responsible for propagating scores
down to lower-level network subsystems. For now, it just keeps scores
in memory and exposes these for debugging purposes via "adb shell
dumpsys network_score".
This change also adds provisioning of a default scorer. When
NetworkScoreService is first initialized, it checks to see if it has
ever set a default scorer; if not, it reads a package name from a
build config property and attempts to set it as the default.
Also add autogenerated equals/hashCode methods to all parcelables.
Bug: 14111427
Bug: 13786258
Change-Id: I02271171653d42e12acd240b73b9e23950744f6b
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
This provides APIs to control and create individual television inputs on
the system which will later be hosted by television applications.
Change-Id: I6866d28e78175a1bff2c32a85c5d77e94d0cd60c
UserManager
- Corp badging
- Querying list of managed profiles
Launcher API
- LauncherApps and Service to proxy changes in managed profile
to the launcher in the primary profile
- Querying and launching launchable apps across profiles
Change-Id: Id8f7b4201afdfb5f414d04156d7b81300119289e
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
...and now fail conservatively when two apps both attempt to define
the same permission. Apps signed with the same certificate are
permitted to redefine permissions.
We also finally have a (hidden) interface class for observing package
installation so that we can now rev the interface without breaking
existing callers.
Bug 13551375
Change-Id: Ifa4e59154dcccbb286ee46a35a6f25e4ad0f0f01
...and now fail conservatively when two apps both attempt to define
the same permission.
We also finally have a (hidden) interface class for observing package
installation so that we can now rev the interface without breaking
existing callers.
Bug 13551375
Change-Id: I3a286d024a30e812ee4b098f345401df3c00e178
Add a dummy wifi hotspot service for futher development use. This is to
resolve the different between master branch and kwd branch, such that future
development can go into kwd and being auto-merged to master.
bug: 5485670
Change-Id: Ica58de445dd050a9f0b817f8e4accaa2478299c5
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
This CL adds a system service handling HDMI-CEC protocol. The service
is equipped with the capability sending/receiving HDMI-CEC messages
Not all the messages are in place. Currently it has messages to support
a few features only, as follows:
- One touch play
- System information
- Routing control (partially - active source status maintenance only)
- Device OSD transfer
- Power status
It will be extended to cover the wider usages in the follow up CLs.
The CEC standard version referenced in the implementation is 1.3a.
Change-Id: Ifed0b02f52ebf098eddb3bd0987efbf353b7e8fe
Also add new API for determining whether the current data network
is active, and thus better scheduling network operations. This
API is designed to not be tied to a mobile network -- regardless
of the network, apps can use it to determine whether they should
initiate activity or wait. On non-mobile networks, it simply always
reports as the network being active.
This changed involved reworking how the idle timers are done so
that we only register an idle timer with the current default
network. This way, we can know whether we currently expect to
get callbacks about the network being active, or should just always
report that it is active. (Ultimately we need to be getting this
radio active data from the radio itself.)
Change-Id: Iaf6cc91a960d7542a70b72f87a7db26d12c4ea8e
When a doze component has been specified in a config.xml resource
overlay, the power manager will try to start a preconfigured dream
whenever it would have otherwise gone to sleep and turned the
screen off. The dream should render whatever it intends to show
then call startDozing() to tell the power manager to put the display
into a low power "doze" state and allow the application processor
to be suspended. The dream may wake up periodically using the
alarm manager or other features to update the contents of the display.
Added several new config.xml resources related to dreams and dozing.
In particular for dozing there are two new resources that pertain to
decoupling auto-suspend mode and interactive mode from the display
state. This is a requirement to enable the application processor
and other components to be suspended while dozing. Most devices
do not support these features today.
Consolidated the power manager's NAPPING and DREAMING states into one
to simplify the logic. The NAPPING state was mostly superfluous
and simply indicated that the power manager should attempt to start
a new dream. This state is now tracked in the mSandmanSummoned field.
Added a new DOZING state which is analoguous to DREAMING. The normal
state transition is now: AWAKE -> DREAMING -> DOZING -> ASLEEP.
The PowerManager.goToSleep() method now enters the DOZING state instead
of immediately going to sleep.
While in the doze state, the screen remains on. However, we actually
tell the rest of the system that the screen is off. This is somewhat
unfortunate but much of the system makes inappropriate assumptions
about what it means for the screen to be on or off. In particular,
screen on is usually taken to indicate an interactive state where
the user is present but that's not at all true for dozing (and is
only sometimes true while dreaming). We will probably need to add
some more precise externally visible states at some point.
The DozeHardware interface encapsulates a generic microcontroller
interface to allow a doze dream for off-loading rendering or other
functions while dozing. If the device possesses an MCU HAL for dozing
then it is exposed to the DreamService here.
Removed a number of catch blocks in DreamService that caught Throwable
and attempted to cause the dream to finish itself. We actually just
want to let the process crash. Cleanup will happen automatically if
needed. Catching these exceptions results in mysterious undefined
behavior and broken dreams.
Bug: 12494706
Change-Id: Ie78336b37dde7250d1ce65b3d367879e3bfb2b8b
This is far from complete but puts the basic components in place
for an app to interact with media sessions.
Change-Id: Icfe313f90ad76ae56badbe42b0e43fc5f68db36f
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
1. There are a few parcelable classes related to printing and accessibility
which are public but not added in the framework.aidl list so third parties
cannot write aidl interfaces that pass these classes. As these classes
are public it is resonable for devepers to be able to pass them between
processes.
Change-Id: I85da1de5198902b74f19d23e3fe16b45b4a11051
- Introduce concept of ActivityStacks residing on Displays and able
to be decoupled and moved around.
- Add a new interface, IActivityContainer for clients to handle
ActivityStacks.
- Abandon ordering of stacks based on mStackState and instead use
ActivityDisplayInfo.stacks<ActivityStack> ordering.
Progress towards closing bug 12078972.
Change-Id: I7785b61c26dc17f432a4803eebee07c7415fcc1f
