Vendor Implementation Guide: SmartDock DFC
This guide provides exhaustive documentation for Original Equipment Manufacturers (OEMs) and AOSP integrators to integrate and pre-configure SmartDock DFC.
1. Integration Instructions
Source Placement
Extract your licensed SmartDock DFC distribution tarball into your AOSP source tree at the following location:
vendor/agp-apps/smartdock
Inclusion in Product Build
To include SmartDock DFC, its associated system overlays, and permission whitelists in your build, add the following line to your main product makefile (e.g., device/vendor/model/product.mk):
$(call inherit-product, vendor/agp-apps/smartdock/SmartDock.mk)
Overriding Default Configuration
SmartDock DFC is designed to be highly flexible. While SmartDock.mk provides a set of sensible defaults in PRODUCT_PROPERTY_OVERRIDES, you can override any of these flags in your target device's specific makefile or build.prop to achieve the desired combination of features for your hardware.
Boot-time Secure Settings (init.rc)
For critical system integrations, such as enabling accessibility services and notification listeners from boot, configuring settings via an init.rc script is the most robust method in AOSP. This ensures settings are applied at a high privilege level during the early boot sequence, before the application starts.
SmartDock ships smartdock_dfc_init.rc and smartdock_grant_permissions.sh under aosp/. SmartDock.mk installs them to:
/vendor/etc/init/smartdock_dfc_init.rc/vendor/bin/smartdock_grant_permissions.sh
On sys.boot_completed, smartdock_dfc_init.rc only enables overlay settings (safe before unlock).
On sys.user.0.ce_available=1, init enables the accessibility service, starts DockService, and runs smartdock_grant_permissions. Both DockService and NotificationService defer CE-dependent initialization (SharedPreferences, dock UI) until credential storage is unlocked.
The oneshot service smartdock_grant_permissions waits for CE storage (sys.user.0.ce_available or cmd user is-unlocked), then applies:
pm grantandappops set(overlay, usage stats, secure settings, etc.)- Notification Listener (
enabled_notification_listeners+cmd notification allow_listener) - Device Administrator via
dpm set-active-admin
sys.user.0.ce_available=1 starts the grant script and enables accessibility / DockService. After grants complete, the script restarts SmartDock so the notification listener binds without a stale crashed state.
Note on Placement & SELinux:
- Files are copied via
SmartDock.mkPRODUCT_COPY_FILES(see above paths). - You will almost certainly need to adjust your SELinux policies to permit
init(or other relevant domains likesystem_server) to write toSettings.Secure. This usually involves adding rules to.tefiles in your device'ssepolicydirectory.
2. Comprehensive Property Directory
Core Shell Behavior
Visuals & Theming
App Menu Configuration
System Overlays (Visual Modification)
Advanced Window Type Overrides
These properties allow for direct control over the WindowManager.LayoutParams.type value used for SmartDock's windows. This is an advanced configuration option primarily for AOSP integrators to fine-tune layering behavior or resolve conflicts with other system UI components. Values are integers corresponding to WindowManager.LayoutParams.TYPE_ constants.
Common Window Types for Overlays:
Functional Restrictions & Production Lock-down
Navigation & Display
Input & Advanced Interaction
3. Deployment Check-list
- Priv-App Status: Ensure SmartDock is in
/product/priv-app/. - Permissions: Verify
privapp-permissions-smartdock.xmlis in/product/etc/permissions/. - Stability: Verify
sysconfig-smartdock.xmlis in/product/etc/sysconfig/. - Boot-time Settings: Ensure
smartdock_dfc_init.rcis correctly placed and configured as per the "Boot-time Secure Settings" section to grant critical permissions early in the boot process. - Other Properties: Add any other desired defaults to
build.propusing the tables above.