This change sets LOCAL_SDK_VERSION for all packages where
this is possible without breaking the build, and
LOCAL_PRIVATE_PLATFORM_APIS := true otherwise.
Setting one of these two will be made required soon, and this
is a change in preparation for that. Not setting LOCAL_SDK_VERSION
makes the app implicitly depend on the bootclasspath, which is
often not required. This change effectively makes depending on
private apis opt-in rather than opt-out.
Test: make relevant packages
Bug: 73535841
Exempt-From-Owner-Approval: Global cleanup
Change-Id: I26458e41ecb84de91ac9a356a5d4bafb44f463c1
This change should have no effect on the app. It is simply unifying some of the prebuilts.
Bug: 72566647
Change-Id: Ic748f8f425e8c8e44bacf62ea61b9af307774911
This commit adds the plumbing which sends the signals from the API
to the component in SysUI. The dialog will be implemented in another
CL in this topic.
Bug: 67497360
Test: Modify Settings to use the new API
Test: FingerprintDialogImpl is able to notify FingerprintDialog clients
of user events
Test: System dialog is dismissed when client application is killed
unexpectedly
Test: Open FP settings, lock device, authenticate, authenticate. Repeat
Change-Id: Id28ec9691646bed765dc069cceb4678d9f6db92e
Using androidx package and new API, also splitting content into
multiple views for better animation support.
Bug: 64155983
Test: visual, see data from provider propagate to AoD
Change-Id: I74b5511d582e7ec1f6ffe5dbc5595f54b9ccb202
- Creating com.android.system.shared library with recents model code and
corresponding recents tests
- Removing notion of blacklisted apps since that is now obsolete.
Bug: 67510855
Test: It builds, Recents runs
Change-Id: Ib1f5eefa6e4d4964366061246002509e2e15b19e
Previously only the contentview inflation was on the
background, now the inflation of the row is too.
Test: runtest systemui
Bug: 34888292
Change-Id: I3adc6b3311217421c9de5c37794397b8a3fd665d
Add android-support-v7-palette to SystemUI for
android-support-v7-mediarouter
Bug: 36902714
Test: m -j ANDROID_COMPILE_WITH_JACK=false checkbuild
Change-Id: I6aa18380fa338a01f73381ab0a3259ff94173ce1
(cherry picked from commit 2560663a1e)
Add android-support-v7-palette to SystemUI for
android-support-v7-mediarouter
Test: m -j ANDROID_COMPILE_WITH_JACK=false checkbuild
Change-Id: I6aa18380fa338a01f73381ab0a3259ff94173ce1
SystemUI builds against the framework, it doesn't need to have its
own copy of framework-protos.
Test: m -j ANDROID_COMPILE_WITH_JACK=false checkbuild
Change-Id: Ia971b2bc648558283562c7080b4d683a7e45fb60
Send a broadcast back and forth to speed up the rate at which plugins
are enabled or disabled.
Also update make files to handle exclude tests better.
Test: Manual
Change-Id: Ic8f45c663c3a5e5fd4b3e9e2f79480e155845c14
Why this is safe:
- To never ever be used in production code, simply for rapid
prototyping (multiple checks in place)
- Guarded by signature level permission checks, so only matching
signed code will be used
- Any crashing plugins are auto-disabled and sysui is allowed
to continue in peace
Now on to what it actually does. Plugins are separate APKs that
are expected to implement interfaces provided by SystemUI. Their
code is dynamically loaded into the SysUI process which can allow
for multiple prototypes to be created and run on a single android
build.
-------
PluginLifecycle:
plugin.onCreate(Context sysuiContext, Context pluginContext);
--- This is always called before any other calls
pluginListener.onPluginConnected(Plugin p);
--- This lets the plugin hook know that a plugin is now connected.
** Any other calls back and forth between sysui/plugin **
pluginListener.onPluginDisconnected(Plugin p);
--- Lets the plugin hook know that it should stop interacting with
this plugin and drop all references to it.
plugin.onDestroy();
--- Finally the plugin can perform any cleanup to ensure that its not
leaking into the SysUI process.
Any time a plugin APK is updated the plugin is destroyed and recreated
to load the new code/resources.
-------
Creating plugin hooks:
To create a plugin hook, first create an interface in
frameworks/base/packages/SystemUI/plugin that extends Plugin.
Include in it any hooks you want to be able to call into from
sysui and create callback interfaces for anything you need to
pass through into the plugin.
Then to attach to any plugins simply add a plugin listener and
onPluginConnected will get called whenever new plugins are installed,
updated, or enabled. Like this example from SystemUIApplication:
PluginManager.getInstance(this).addPluginListener(OverlayPlugin.COMPONENT,
new PluginListener<OverlayPlugin>() {
@Override
public void onPluginConnected(OverlayPlugin plugin) {
PhoneStatusBar phoneStatusBar = getComponent(PhoneStatusBar.class);
if (phoneStatusBar != null) {
plugin.setup(phoneStatusBar.getStatusBarWindow(),
phoneStatusBar.getNavigationBarView());
}
}
}, OverlayPlugin.VERSION, true /* Allow multiple plugins */);
Note the VERSION included here. Any time incompatible changes in the
interface are made, this version should be changed to ensure old plugins
aren't accidentally loaded. Since the plugin library is provided by
SystemUI, default implementations can be added for new methods to avoid
version changes when possible.
-------
Implementing a Plugin:
See the ExamplePlugin for an example Android.mk on how to compile
a plugin. Note that SystemUILib is not static for plugins, its classes
are provided by SystemUI.
Plugin security is based around a signature permission, so plugins must
hold the following permission in their manifest.
<uses-permission android:name="com.android.systemui.permission.PLUGIN" />
A plugin is found through a querying for services, so to let SysUI know
about it, create a service with a name that points at your implementation
of the plugin interface with the action accompanying it:
<service android:name=".TestOverlayPlugin">
<intent-filter>
<action android:name="com.android.systemui.action.PLUGIN_COMPONENT" />
</intent-filter>
</service>
Change-Id: I42c573a94907ca7a2eaacbb0a44614d49b8fc26f
Cars usually have an external audio module. When Android is serving as
the car's headunit, users should be able to adjust the car's volume
through SystemUI. The following changes are made to make it work:
+ Load VolumeDialogController from SystemUIFactory
+ Added CarSystemUIFactory
+ Added CarVolumeDialogController which extends VolumeDialogController
and it uses CarAudioManager as source of truth for volume controls.
+ Some refactor in VolumeDialogController to make it easier for
subclasses to override volume controls.
Note that CarAudioManager does not completely replace AudioManager.
Majority of code in VolumeDialogController still applies in the car use
case, so I made CarVolumeDialogController a subclass of
VolumeDialogController instead of making them peers.
Bug: 27595951
Change-Id: Id4adec7281e41aa71f3de034e5b88a32a89be305
Moves the protos and event log tags into a library,
so the build system doesn't think they're duplicates.
Bug: 27151225
Change-Id: Ic96b6b811d4813a4c48940081ea77b12fb23f0bc
First of several change lists:
1. Add in the new proto (this CL)
2. Migrate the existing code over to the proto.
3. Remove MetricsConstants once it is unused.
Bug: 26442178
Change-Id: Ic24829246af8ec5b202e39a85960aac5cf336c33
- Initial changes to show a history view within Overview (behind tuner
flag)
- Restoring the task view dim in the stack
Change-Id: I0503d11768736c86f3145942404391dfacd0ddd6
- Removing old broadcasts in favor of direct aidl interface between
system and secondary users. Also moving user specific implementation
into RecentsImpl, allowing Recents to handle proxying between users.
Change-Id: I4bd5ef1d1ee47309b7c754f50a5e8b2e2aab988f
Added a new component which tracks touch and sensor events and
also events like showing the bouncer tapping a notification and
others. The collection is enabled when the screen is turned on and
is disabled after the phone is unlocked. The data is saved in a
protobuf file in internal storage in a directory called
"good_touches". There is also an option to collect events which
end with the screen turning off. These are saved in the
"bad_touches" file. Everything is hidden behind the
ENABLE_ANALYTICS flag which is set by default to false and can be
turned on only if Build.IS_DEBUGGABLE is true. Also
behind the ENFORCE_BOUNCER flag the class shows the bouncer before
expanding a notification, showing quick settings or launching an
affordance from one of the bottom corners.
Change-Id: Iaeae0fb7a0d9c707daf7a270201fa5b1cd84c74a
Ideally, we would also do incremental builds on userdebug targets,
but this introduces a risk that userdebug builds would be different
to user builds. So we only do it on eng builds for now.
Change-Id: I2778d270052cf26e6c767f1847991a425d8bbd12
Setting the environment variable EXCLUDE_SYSTEMUI_TESTS to something
excludes the tests package during building. Saves a few seconds for
incremental changes in SystemUI for fast UI iteration changes.
Change-Id: I596a0273133c8a8bece0cc364e2ec61fdea45116
This change achieves a couple of things:
- Let Keyguard be a library, so we can use it in SystemUI.
- Introduce FLAG_KEYGUARD for windows and deprecate TYPE_KEYGUARD. Make
all the TYPE_KEYGUARD behaviour dependant on the flag.
- Implement a new KeyguardService in SystemUI, and bind that service
from PhoneWindowManager.
- Introduce BaseStatusBar.setKeyguardState and inflate
KeyguardSimpleHostView there and use FLAG_KEYGUARD for the window, such
that the status bar window essentially gets the Keyguard.
Bug: 13635952
Change-Id: I059d80d8b9b9818a778ab685f4672ea2694def63
"signatureOrSystem" permissions are no longer available to all apps
residing en the /system partition. Instead, there is a new /system/priv-app
directory, and only apps whose APKs are in that directory are allowed
to use signatureOrSystem permissions without sharing the platform cert.
This will reduce the surface area for possible exploits of system-
bundled applications to try to gain access to permission-guarded
operations.
The ApplicationInfo.FLAG_SYSTEM flag continues to mean what it is
says in the documentation: it indicates that the application apk was
bundled on the /system partition. A new hidden flag FLAG_PRIVILEGED
has been introduced that reflects the actual right to access these
permissions.
At some point the "system" permission category will be
renamed to "privileged".
Bug 8765951
Change-Id: I6f0fd9cdb9170e076dfc66d83ecea76f8dd7335d
These have been created to reduce the size and complexity
of frameworks/base.
mms-common was created by moving all of
frameworks/base/core/java/com/google/android/mms
to:
frameworks/opt/mms
telephony-common was created by moving some of
frameworks/base/telephony
to:
frameworks/opt/telephony
Change-Id: If6cb3c6ff952767fc10210f923dc0e4b343cd4ad
