diff options
| -rw-r--r-- | src/devices/graphics/arch-sh.jd | 4 | ||||
| -rw-r--r-- | src/devices/storage/config.jd | 4 | ||||
| -rw-r--r-- | src/security/selinux/implement.jd | 10 |
3 files changed, 9 insertions, 9 deletions
diff --git a/src/devices/graphics/arch-sh.jd b/src/devices/graphics/arch-sh.jd index 2ef6c3c4..5b96763b 100644 --- a/src/devices/graphics/arch-sh.jd +++ b/src/devices/graphics/arch-sh.jd @@ -61,7 +61,9 @@ hardware-accelerate the Canvas API. As you can see from the charts on the Acceleration</a> page, this was a bit of a bumpy ride. Note in particular that while the Canvas provided to a View's <code>onDraw()</code> method may be hardware-accelerated, the Canvas -obtained when an app locks a Surface directly with <code>lockCanvas()</code> never is.</p> +obtained when an app locks a Surface directly with <code>lockCanvas()</code> never is. +As of API 23, a hardware-accelerated Canvas can be obtained from a Surface using +<code>lockHardwareCanvas()</code> instead.</p> <p>When you lock a Surface for Canvas access, the "CPU renderer" connects to the producer side of the BufferQueue and does not disconnect until the Surface is diff --git a/src/devices/storage/config.jd b/src/devices/storage/config.jd index 6db706c1..c398d58b 100644 --- a/src/devices/storage/config.jd +++ b/src/devices/storage/config.jd @@ -21,7 +21,7 @@ page.title=Device Configuration </div> <p>External storage is managed by a combination of the <code>vold</code> init -service and <code>MountService</code> system service. Mounting of physical +service and <code>StorageManagerService</code> system service. Mounting of physical external storage volumes is handled by <code>vold</code>, which performs staging operations to prepare the media before exposing it to apps.</p> @@ -64,7 +64,7 @@ Other possible flags are <code>nonremovable</code>, <h2 id=configuration_details>Configuration details</h2> <p>External storage interactions at and above the framework level are handled -through <code>MountService</code>. +through <code>StorageManagerService</code>. Due to configuration changes in Android 6.0 (like the removal of the storage_list.xml resource overlay), the configuration details are split into two categories. diff --git a/src/security/selinux/implement.jd b/src/security/selinux/implement.jd index f5f605bf..30cb28f8 100644 --- a/src/security/selinux/implement.jd +++ b/src/security/selinux/implement.jd @@ -107,17 +107,15 @@ labels may also be assigned to specific mounts such as vfat using the context= mount option. <li><em>property_contexts</em> - Located in the sepolicy subdirectory. This file assigns labels to Android system properties to control what processes can -set them. This configuration is read by the init process during startup and -whenever the selinux.reload_policy property is set to 1. +set them. This configuration is read by the init process during startup. <li><em>service_contexts</em> - Located in the sepolicy subdirectory. This file assigns labels to Android binder services to control what processes can add (register) and find (lookup) a binder reference for the service. This -configuration is read by the servicemanager process during startup and whenever -the selinux.reload_policy property is set to 1. +configuration is read by the servicemanager process during startup. <li><em>seapp_contexts</em> - Located in the sepolicy subdirectory. This file assigns labels to app processes and /data/data directories. This configuration -is read by the zygote process on each app launch and by installd during startup -and whenever the selinux.reload_policy property is set to 1. +is read by the zygote process on each app launch and by installd during +startup. <li><em>mac_permissions.xml</em> - Located in the sepolicy subdirectory. This file assigns a seinfo tag to apps based on their signature and optionally their package name. The seinfo tag can then be used as a key in the seapp_contexts |