Hand over ownership of overlays to OverlayManagerService.
Changes to a package's overlays are propagated using the activity life
cycle. Affected activities will be recreated as needed. This provides a
well-defined point to modify an application's assets while the
application is paused.
Consolidate how overlays targeting the system and overlays targeting
regular applications are handled. Previously, system overlays were
handled as a special case. Now, everything is handled identically. As a
side effect, the call to idmap --scan during Zygote boot has become
obsolete and is removed.
Information on what overlays to use is recorded in
ApplicationInfo.resourceDirs. The PackageManagerService is responsible
for the creation of ApplicationInfo objects. The OverlayManagerService
is responsible for informing the PackageManagerService in advance about
what resourceDirs to use.
When launching an application, the ApplicationInfo is already populated
with up-to-date information about overlays.
When enabling or disabling an overlay for a running application, the
OverlayManagerService first notifies the PackageManagerService about the
updated resourceDirs. It then tells the ActivityManagerService to push
the new ApplicationInfo object to the application's ActivityThread.
Finally the application requests its ResourcesManager to create new
ResourcesImpl objects based on the updated paths.
Co-authored-by: Martin Wallgren <martin.wallgren@sonymobile.com>
Signed-off-by: Zoran Jovanovic <zoran.jovanovic@sonymobile.com>
Bug: 31052947
Test: run tests from 'OMS: tests for OverlayManagerService'
Change-Id: Idc96dae6fc075d5373aa055bbf50e919136d7353
ro.kernel.qemu based check to determine whether Bluetooth should be
started or not was an old hack used when "features" was not available to
determine hardware availability. This was later fixed with the
hasSystemFeature check. However, the old check was not removed.
The presence of the old check causes Bluetooth to not start on Android
Things devices which have ro.kernel.qemu set for graphics usage. It's
also preferable to depend on the system API rather than on build
configs. Related CLs modify the emulator builds to correct the config in
builds.
Bug: 35361545
Change-Id: I219ce5e14709c76dcba43af4693093e985269d43
Test: Verified by launching bluetooth on local devices after removing
the old check. Also verified by booting up the emulator and verifying
that Bluetooth Services do not start.
We now turn on lazy preloading (see companion change 73c7df1bda76a0)
and explicitly preload zygote resources.
To provide the most benefit :
- We start the preload in the system_server, which means the system_server
starts quicker since it has one less preload to wait for. Morever, the
64 bit zygote also starts quicker because it has one less high
priority process to contend with for CPU and I/O.
- We start the preload after the core system services start up, since we
know no 32 bit zygote processes will be requested before that point.
- We start the preload ~1s before the webview factory preparation, to
ensure that it completes before the 32 bit relro process is forked
from the zygote. In the event that it takes too long, the webview
RELRO process will block, but it will do so without holding any locks.
I have not observed this happening in > 200 runs on marlin / sailfish
devices.
This change saves about 500ms in boot times, and sometimes even more.
AFTER:
successive-online : 16970.0,16668.0,16391.0,16498.0,17601.0,16736.0,16609.0,16820.0,16310.0,17557.0,
successive-online_avg : 16816.0
successive-boot : 28750.0,29520.0,29372.0,28424.0,30683.0,28523.0,29766.0,29779.0,29304.0,31607.0,
successive-boot_avg : 29572.8
BEFORE:
successive-online : 16678.0,18105.0,17197.0,16744.0,17453.0,16946.0,18068.0,16719.0,17453.0,16942.0,
successive-online_avg : 17230.5
successive-boot : 30855.0,32069.0,31223.0,30918.0,30284.0,29750.0,31036.0,30778.0,30310.0,30908.0,
successive-boot_avg : 30813.1
Note that successive-online is a little faster, as expected since we do
less work in the 32 bit zygote.
Test: manual, timings from tradefed.
Bug: 34810190
Change-Id: I90207a2706afda163b8134ff2af31f6917f3841b
This introduces an API for apps that support companion devices to provide a
more streamlined flow for pairing and setting up the device
Bug: 30932767
Test: Using a toy app, invoke the newly introduced API (CompanionDeviceManager),
and go through the flow. Ensure filtering works, and device is returned to
the calling app. Ensure the calling app can pair to the selected device.
Change-Id: I0aeb653afd65e4adead13ea9c7248ec20971b04a
- Starting sensor service in separate thread led into occasional 1 sec
blocking of WMS inside PhoneWindowManager to get sensor service.
- Change startSensorService into blocking call and call it from
separate thread using SystemServerInitThreadPool.
- This does not improve best case boot-up time but fixes occasional 1 sec delay
which is happening in 10 to 20% rate. So this is potential 100 to 200ms saving for many runs.
bug: 34846045
Test: multiple reboots.
Change-Id: Ia08fa3284aed5e576acaac6fbfd74b9db9f7d63c
- There is no other dependency for webview from system server.
Prepare it in separate thread and confirm completion
before allowing 3rd party apps.
bug: 33840151
Test: manual, reboot
Change-Id: I417b0451c37f663c577295ab07f33474e72fe457
This change adds APIs for instant apps to store cookie data
that is presisted across instant installs and across the
upgrade from an instant to a standard app. Standard apps
can use the cookie APIs but when they are uninstalled the
cookie is also deleted. The cookies are kept longer than
the instant apps as they are much smaller - 16KB by default.
We can change the cookie size via a system setting i.e.
after we ship we can increase size if needed.
We also add internal APIs to surface information about
installed and uninstalled instant apps which should be
used for showing them in the UI. For this puporse we store
the icon, permissions, and label of uninstalled apps. If
the app is re-installed we drop this meta-data but keep
the cookie around. If we have cookie data stored and the
signing cert of the app changes when it gets re-intalled
we wipe the cookie.
Test: CTS tests pass; hiddent APIs tested manually
Change-Id: If145c0440cc61a5303e2cbb70228d235d36037a5
Also added lazy accessor for mBackgroundLaunchBroadcasts to give more
time for SystemConfig init to finish.
Test: manual
Bug: 34809967
Change-Id: Iaba0ac61714d94e72d571f33cd22d8700b89bb31
Do not log framework_boot_completed/framework_locked_boot_completed
for secondary users, runtime restarts or first boot/upgrade.
First boot/upgrade also applies to boot_system_server_ready/
boot_package_manager_init_ready
Cherry-picked from commit 4ba91b9a879290d3d810330d172161ab1f923da8
Test: Manual update with fingerprint change
Test: runtime restart - not logged
Bug: 34516002
Bug: 32807863
Change-Id: I64b960c96a0e45b4fefaf05547ea5ac5c701c765
This change creates a new FontManagerService, in charge of providing
font management data. It exposes a public API to retrieve the
information in fonts.xml without accessing it directly. To do this,
it also refactors FontListParser's internal classes into a new public
FontConfig class holding all the font data.
getSystemFonts() returns all the available information in fonts.xml
as well as file descriptors for all the fonts. This allows us to
share the memory consumed by these files between all clients.
Bug: 34190490
Test: See attached CTS change in topic
Change-Id: I0e922f8bcc9a197a1988d04071eb485328d66fb7
Do not log framework_boot_completed/framework_locked_boot_completed
for secondary users, runtime restarts or first boot/upgrade.
First boot/upgrade also applies to boot_system_server_ready/
boot_package_manager_init_ready
Test: Manual update with fingerprint change
Test: runtime restart - not logged
Bug: 34516002
Bug: 32807863
Change-Id: I2e4237bf49e82101f483df6190111f4541328d19
When a device gets stuck in a crash loop, it's pretty much unusable
and impossible for users to recover from.
To help rescue devices from this state, this change introduces a new
feature that watches for runtime restart loops and persistent app
crash loops, and escalates through a series of increasingly
aggressive rescue operations. Currently these rescue levels walk
through clearing any experiments in SettingsProvider before finally
rebooting and prompting the user to wipe data.
Crash loops are detected based on a number of events in a specific
window of time. App stats can be stored in memory, but boot stats
need to be stored in system properties to be more robust.
Start up RecoveryService much earlier during the boot so we can
reboot into recovery when needed.
Add properties tha push system_server or SystemUI into a crash loops
for testing purposes.
Test: builds, boots, forced crashing walks through modes
Bug: 24872457, 30951331
Change-Id: I6cdd37682973fe18de0f08521e88f70ee7d7728b
- This service provides the TextClassificationManager access to the
classification model file.
See: Icb82b707c9c1b4dcb739f44d888bbc43bc3b03bb
- This service is started at boot time.
See: Ie4a597bc5c6c4140afbcf7feaa9dd237a3fd5fef
Test: Manually tested. Also see: Ic2a5eceeaec4cd2943c6c753084df46d30511fee
Bug: 32503402
Change-Id: Ic428d00f291e268211866b3fc6b7acbc3eb04e1e
During first boot after OTA, additional dexopting has to be done
during PM initialization. Timings for OTA are reported separately,
so we should ignore first boot to avoid skewing the metrics.
The following metrics were updated:
- framework_locked_boot_completed
- framework_boot_completed
Cherry-picked from commit 1d87e40d4214a7f6d20a58d6f27cca174f0d974e
Test: manual
Bug: 32807863
Change-Id: I9d545cf38118f45f3f13597df2949d0ae4abd26a
This should help to identify devices that report unusually long
boot_completed timings.
Test: manual
Bug: 32807863
Change-Id: Ic6c7103d43b3e395accb38ec418094bc580c7c40
Start WifiService before other wifi-related services.
This is now possible since service dependencies were
removed from the WifiStateMachine constructor.
Bug: 34137732
Test: frameworks/opt/net/wifi/tests/wifitests/runtests.sh
Test: frameworks/base/wifi/tests/runtests.sh
Test: manually tested wifi connection
Test: manually checked for Wifi Direct peers
Merged-In: Iad4eb7053e60542d0be72208db53cf0f83004ae2
Change-Id: I1e57bfac83708644df6f016808c5972d2d6136c6
Cherry-pick change that only starts P2P service if p2p is supported for
the device.
Disable WiFi p2p service if it's not supported.
b/26877020
Bug:34193861
Test: frameworks/base/wifi/tests/runtests.sh
Test: frameworks/opt/net/wifi/tests/wifitests/runtests.sh
Test: manually verified wifi connection
Test: manually checked for p2p peers
Change-Id: I84b822fa57423711de75d2147effe73a1fc40eb4
Merged-In: I84b822fa57423711de75d2147effe73a1fc40eb4
Start WifiService before other wifi-related services.
This is now possible since service dependencies were
removed from the WifiStateMachine constructor.
Bug: 34137732
Test: frameworks/opt/net/wifi/tests/wifitests/runtests.sh
Test: frameworks/base/wifi/tests/runtests.sh
Test: manually tested wifi connection
Test: manually checked for Wifi Direct peers
Change-Id: Iad4eb7053e60542d0be72208db53cf0f83004ae2
During first boot after OTA, additional dexopting has to be done
during PM initialization. Timings for OTA are reported separately,
so we should ignore first boot to avoid skewing the metrics.
The following metrics were updated:
- boot_system_server_init - check added for consistency with other
metrics in SystemServer. The metric is actually unaffected by first boot,
because dexopt will start later
- boot_package_manager_init_ready
- boot_system_server_init
- framework_locked_boot_completed
- framework_boot_completed
Test: manual + UserControllerTest pass
Bug: 32807863
Change-Id: Iff13697b7d4f9ff8439e1e932d7e276f48cd5c37
This API is designed to provide both UID-level stats and overall
summary data for a given storage device, as identified by UUID.
The use of UID-level granularity might appear a bit clunky, but it
matches other usage statistics (such as network and battery), and it
allows us to implement it using an extremely fast quota kernel
feature.
A future CL will wire up the implementation to installd.
Test: builds, boots
Bug: 32206268
Change-Id: I7b51877682d0370c2402c19346f57809f0e7ac53
System services can use it during the boot to submit tasks that can be run in
parallel with the main thread.
Switched PersistentDataBlockService and FingerprintService from FgThread to
the new thread pool.
UiModeManagerService: update initial configurations on init thread. They run
while holding the mLock so no extra synchronization barriers are needed at a
later stage.
Test: manual - device boots without errors
Test: ParallelPackageParserTest passes
Change-Id: I548f34b0a18f61924e09a39afb12e085cde35442
This service will only be enabled if the platform was built with
EMMA_INSTRUMENT=true
Test: Manual
Bug: 31077138
Change-Id: I4ba98b6568d31ded1b66da996b3c2e5a2ee07c75
There are a few major pieces here:
incidentd
---------
This daemon (started by init) runs and accepts incoming requests to take
incident reports. When prompted, it calls into various system services
and fills in an IncidentProto data structure, and then writes the report
into dropbox.
The next steps for incidentd:
- Security review of SELinux policies. These will be a subset of
the dumpstate permissions. Until this is done, incidentd is
not started at boot time.
incident
--------
This shell command calls into incidentd, and can initiate an incident
report and either capture the output or leave for dropbox.
incident_report
---------------
This host side tool can call adb shell with the correct parameters
and also format the incident report as text. This formatting code
was left of the device on purpose. Right now it's pretty small, but
as the number of fields increases, the metadata and code to do the
formatting will start to grow.
The incident_report command also contains a workaround to let it
work before incidentd is turned on by default. Right now, it is
implemented to call adb shell dumpsys <service> --proto directly,
whereas in the future it will go through the full incidentd flow.
incident_section_gen
--------------------
A build-time tool that generates a stripped down set of information
about the fields that are available.
libincident
-----------
This library contains the code to connect to incidentd, and the
meta proto definitions that are used by the framework protos.
The basics are here now, but they are not fully fleshed out yet.
The privacy.proto file contains annotations that can go in the
proto file that we will later use to filter which fields are
uploaded, and which are used by local sources. For example, a
device in a test lab is safe to upload much much more information
than a real user. These will share the same mechanism, but the
user's output will be filtered according to these annotations.
frameworks/core/proto
---------------------
These .proto files contain the definitions of the system's
output. There is one master android.os.IncidentProto file that
is the top level of an incident report, but some other services
(notification, fingerprint, batterystats, etc) will have others
that are used directly by the logging mechanism.
Other files which are shared by several of the services also go
here, such as ComponentName, Locale, Configuration, etc. There
will be many more.
There is also a first iplementation of a dump method handling
--proto in the fingerprint service.
IncidentManager
---------------
The java API to trigger an incident report.
Test: Not written yet
Change-Id: I59568b115ac7fcf73af70c946c95752bf33ae67f
