Minor refactoring of dock observer to allow its state to be
inspected and modified via dumpsys for debugging purposes.
eg. View current state.
adb shell dumpsys DockObserver
eg. Simulate being docked.
adb shell dumpsys DockObserver set state 1
eg. Reset back to normal.
adb shell dumpsys DockObserver reset
Change-Id: Ie48db775290ebed9aa4d9d9d5ac5a6fcb6122ac9
WallpaperManager should always do a null check on the service object.
SystemServer should always bring up the DevicePolicyManagerService,
and let the service do appropriate default no-ops if the feature
is not supported.
Change-Id: Iaaf12b60ed375fe2e341ec11faa10c9344d7d9da
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
The dreams manager also manages dozing. It has a minimal footprint
so there is no real reason to disable the component (it just makes
debugging more difficult).
Improved the documentation of the config_dreamsSupported resource
to clarify exactly what it controls.
Bug: 12494706
Change-Id: I78244846f7c1ddfd11bc1605af59b0db91337971
This change simplifies the process of initializing a SystemService
by folding the onCreate() step back into the constructor. It removes
some ambuiguity about what work should happen in the constructor and
should make it possible for services to retain most of their final
fields after refactoring into the new pattern.
Change-Id: I25f41af0321bc01898658ab44b369f9c5d16800b
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
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
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
(Cherry pick from master)
As a next step they can be moved into separate directories to be
built as separate modules that may or may not be included in a
particular configuration.
Moves AppWidgetService, BackupManagerService, ClipboardService, DevicePolicyMS,
and WallpaperMS.
Change-Id: Idd92871c1828bdde81d85fe99a9c87a22d53169d
This change adds a new media router service whose purpose is to track
global state information associated with media routes. This service
publishes routes to the media router instance in application processes
and handles requested state changes such as selecting or unselecting
global routes. The service also binds to remote display provider
services which can offer new remote display routes to the system.
Includes a test application for manually verifying certain aspects
of the operation of the media router service.
The remote display provider interface is essentially a stripped down
media route provider interface as defined in the support library
media router implementation. For now, it is designed to be used only
by first parties to publish remote display routes to the system so
it is not exposed as public API in the SDK. In the future, the remote
display provider interface will most likely be deprecated and replaced
with a more featureful media route provider interface for third
party integration, similar to what is in the support library today.
Further patch sets integrate these new capabilities into the System UI
and Settings for connecting remote displays.
Bug: 11257292
Change-Id: I31109f23f17b474d17534d0f5f4503e388b081c2
Wifi statemachine starts P2p statemachine; which uses network management
service to (i.e. netd) to start p2p0 interface. But it only gets a
reference to network management service in conenctivityServiceReady().
Calling that later means there's a chance of a race between this
thread's setting of the network manager, and P2p statemachine thread's
usage of the same.
Bug: 11048296
Change-Id: If151026ed5fbb12db57ee7f9bdd47c67dd7142e5
We now have the activity manager kill long-running processes
during idle maintanence.
This involved adding some more information to the activity manager
about the current memory state, so that it could know if it really
should bother killing anything. While doing this, I also improved
how we determine when memory is getting low by better ignoring cases
where processes are going away for other reasons (such as now idle
maintenance). We now won't raise our memory state if either a process
is going away because we wanted it gone for another reason or the
total number of processes is not decreasing.
The idle maintanence killing also uses new per-process information
about whether the process has ever gone into the cached state since
the last idle maintenance, and the initial pss and current pss size
over its run time.
Change-Id: Iceaa7ffb2ad2015c33a64133a72a272b56dbad53
1. Now a user state has ins own spooler since the spooler app is
running per user. The user state registers an observer for the state
of the spooler to get information needed to orchestrate unbinding
from print serivces that have no work and eventually unbinding from
the spooler when all no service has any work.
2. Abstracted a remote print service from the perspective of the system
in a class that is transparently managing binding and unbinding to
the remote instance.
3. Abstracted the remote print spooler to transparently manage binding
and unbinding to the remote instance when there is work and when
there is no work, respectively.
4. Cleaned up the print document adapter (ex-PrintAdapter) APIs to
enable implementing the all callbacks on a thread of choice. If
the document is really small, using the main thread makes sense.
Now if an app that does not need the UI state to layout the printed
content, it can schedule all the work for allocating resources, laying
out, writing, and releasing resources on a dedicated thread.
5. Added info class for the printed document that is now propagated
the the print services. A print service gets an instance of a
new document class that encapsulates the document info and a method
to access the document's data.
6. Added APIs for describing the type of a document to the new document
info class. This allows a print service to do smarts based on the
doc type. For now we have only photo and document types.
7. Renamed the systemReady method for system services that implement
it with different semantics to systemRunning. Such methods assume
the the service can run third-party code which is not the same as
systemReady.
8. Cleaned up the print job configuration activity.
9. Sigh... code clean up here and there. Factoring out classes to
improve readability.
Change-Id: I637ba28412793166cbf519273fdf022241159a92
System server always forks from Zygote so we no longer need
the system_server executable which was probably broken anyhow.
This makes the initialization sequence slightly more intelligible.
Likewise, we don't need the GrimReaper anymore because init
will automatically take care of restarting the system when the
service manager dies.
Change-Id: I02c88d9392f7c8133d9cde9d0d978da89ed80452
The MountService will take 2 minutes to time out trying to
get volume and asec lists from vold, because vold is busy encrypting
and not listening to requests on its socket. So when encrypting,
do not wait for it to be ready, as we don't have /data mounted anyhow.
Change-Id: I45c1067b168231cbec7a0f577de2ff3b28dbac55
Adds an optimization for checking whether a looper is stuck,
with a new Looper method to see if its thread is currently
idle. This will allow us to put a large number of loopers
in the monitor efficiently, since we generally won't have to
do a context switch on each of them (since most looper threads
spend most of their time idle waiting for work).
Also change things so the system process's main thread
is actually running on the main thread. Because Jeff
asked for this, and who am I to argue? :)
Change-Id: I12999e6f9c4b056c22dd652cb78c2453c391061f
1. The scheduling was relying on receiving battery level broadcasts
which however are not sent if the device is asleep. The maintenance
window was not bound and we could miss a frame if the user did
not interact the device longer than the min time between two
maintenance windows.
2. Hide the idle maintenance intents since this will be rewritten
to user services.
bug:8688454
Change-Id: I17b421b09823cb46ec218cabda19e02432d94f8c
This introduces four generic thread that services can
use in the system process:
- Background: part of the framework for all processes, for
work that is purely background (no timing constraint).
- UI: for time-critical display of UI.
- Foreground: normal foreground work.
- IO: performing IO operations.
I went through and moved services into these threads in the
places I felt relatively comfortable about understanding what
they are doing. There are still a bunch more we need to look
at -- lots of networking stuff left, 3 or so different native
daemon connectors which I didn't know how much would block,
audio stuff, etc.
Also updated Watchdog to be aware of and check these new
threads, with a new API for other threads to also participate
in this checking.
Change-Id: Ie2f11061cebde5f018d7383b3a910fbbd11d5e11
When the Android runtime starts, the system preloads a series of assets
in the Zygote process. These assets are shared across all processes.
Unfortunately, each one of these assets is later uploaded in its own
OpenGL texture, once per process. This wastes memory and generates
unnecessary OpenGL state changes.
This CL introduces an asset server that provides an atlas to all processes.
Note: bitmaps used by skia shaders are *not* sampled from the atlas.
It's an uncommon use case and would require extra texture transforms
in the GL shaders.
WHAT IS THE ASSETS ATLAS
The "assets atlas" is a single, shareable graphic buffer that contains
all the system's preloaded bitmap drawables (this includes 9-patches.)
The atlas is made of two distinct objects: the graphic buffer that
contains the actual pixels and the map which indicates where each
preloaded bitmap can be found in the atlas (essentially a pair of
x and y coordinates.)
HOW IS THE ASSETS ATLAS GENERATED
Because we need to support a wide variety of devices and because it
is easy to change the list of preloaded drawables, the atlas is
generated at runtime, during the startup phase of the system process.
There are several steps that lead to the atlas generation:
1. If the device is booting for the first time, or if the device was
updated, we need to find the best atlas configuration. To do so,
the atlas service tries a number of width, height and algorithm
variations that allows us to pack as many assets as possible while
using as little memory as possible. Once a best configuration is found,
it gets written to disk in /data/system/framework_atlas
2. Given a best configuration (algorithm variant, dimensions and
number of bitmaps that can be packed in the atlas), the atlas service
packs all the preloaded bitmaps into a single graphic buffer object.
3. The packing is done using Skia in a temporary native bitmap. The
Skia bitmap is then copied into the graphic buffer using OpenGL ES
to benefit from texture swizzling.
HOW PROCESSES USE THE ATLAS
Whenever a process' hardware renderer initializes its EGL context,
it queries the atlas service for the graphic buffer and the map.
It is important to remember that both the context and the map will
be valid for the lifetime of the hardware renderer (if the system
process goes down, all apps get killed as well.)
Every time the hardware renderer needs to render a bitmap, it first
checks whether the bitmap can be found in the assets atlas. When
the bitmap is part of the atlas, texture coordinates are remapped
appropriately before rendering.
Change-Id: I8eaecf53e7f6a33d90da3d0047c5ceec89ea3af0
Instead of warning on Process.SYSTEM_UID, which is also used by the
Settings app, change to have the parent process explicitly ask for
warnings.
Bug: 8667286
Change-Id: Ib26676694a4041ff4e6d3ffdcc14055b7eba13c7
SystemServer is currently a monolithic class that brings up key system
services. This change is the first phase of refactoring it to be more
configurable. Specifically, it adds a set of on/off switches used to control
startup of individual services. Future plans include finer grained controls
and a more explicit and consistent startup sequence for these services.
Change-Id: I7299f5ce7d7b74a34eb56dffb788366fbc058532
The Activity Manager sets up a permission-guarded domain socket, which
debuggerd connects to when a crash happens. If this is successful,
the daemon then mirrors the logged crash report to that socket, then
closes it.
The Activity Manager parses the native crash dump supplied by debuggerd
and forwards it to the standard app-crashed code. The UX result is
that users now see the normal "app has stopped unexpectedly" dialog
with "report" and "okay" options for native crashes, not just for
DVM-mediated crashes.
Bug 8322568
Change-Id: Ie1b279896c603bd74d82d6cfcfd66a8f231da134
Write out entropy if we're shutting down or rebooting,
or if someone plugs in the power.
Bug: 8312061
Change-Id: Id9a48064a7bdfe6c05a9227ea95a1bdbd0e9b8ae
This is in preparation to moving keyguard into its own process.
Moved keyguard source and resources into new .apk.
Got basic test app working. Still need to implement MockPatternUtils
and means to pass it into KeyguardService with local binder interface.
Added new ACCESS_KEYGUARD_SECURE_STORAGE permission.
Temporarily disabled USER_PRESENT broadcast.
Remove unintentional whitespace changes in PhoneWindowManager, etc.
Checkpoint basic working version.
Move to systemui process.
Synchronize with TOT.
Sync with recent user API changes.
Fix bug with returing interface instead of stub for IKeyguardResult. Create KeyguardServiceDelegate to allow
for runtime-selectable local or remote interface.
More keyguard crash robustness.
Keyguard crash recovery working. Currently fails safe (locked).
Fix selector view which was still using frameworks resources.
Remove more references to internal framework variables. Use aliases for those we should move but
currently have dependencies.
Allow runtime switching between service and local mode.
Fix layout issue on tablets where orientation was reading the incorrect constant
from the framework. Remove more framework dependencies.
Fix PIN keyboard input.
Remove unnecessary copy of orientation attrs.
Remove unused user selector widget and attempt to get multi user working again.
Fix multi-user avatar icon by grabbing it from UserManager rather than directly since
keyguard can no longer read it.
Merge with AppWidget userId changes in master.
Change-Id: I254d6fc6423ae40f6d7fef50aead4caa701e5ad2
It is beneficial that there is a mechanism on the platform
to notify applications whether it is safe to perform somehow
expensive operations while the user is not using the device.
Thus, user experience will not be degraded. An example is
discarding of unused blocks on a mounted file system instead
of doing this on every write operation.
bug:8056794
Change-Id: I708bad9d3ce6c8f1d5a1c05c0abf46f81a3d464b
Initial implementation, tracking use of the vibrator, GPS,
and location reports.
Also includes an update to battery stats to also keep track of
vibrator usage (since I had to be in the vibrator code anyway
to instrument it).
The service itself is only half-done. Currently no API to
retrieve the data (which once there will allow us to show you
which apps are currently causing the GPS to run and who has
recently accessed your location), it doesn't persist its data
like it should, and no way to tell it to reject app requests
for various operations.
But hey, it's a start!
Change-Id: I05b8d76cc4a4f7f37bc758c1701f51f9e0550e15
This helps reduce the pressure on framework.jar, and makes it clear
that it should only be used by the system_server.
Bug: 7333397
Change-Id: I0858904239535380fbf30562b793e277d8c3f054
