Name | Updated at | |
---|---|---|
framework | ||
service | ||
OWNERS | ||
README.md | ||
TEST_MAPPING |
Blob handle is the identifier of the data and it is what apps need to use for referring to the data blobs. Currently, this is made of following bits of information:
When comparing two Blob handles, the System will compare all the pieces of information above and only when two Blob handles are equal, the data blobs corresponding to those identifiers are considered equal.
Session is a way to allow apps to contribute data over multiple time intervals. Each session is associated with a unique Identifier that is created and obtained by the apps by calling BlobStoreManager#createSession. Apps can save the Identifier associated with a session and use it to open and close it multiple times for contributing the data. For example, if an app is downloading some content over the network, it can start a Session and start contributing this data to the System immediately and if the network connection is lost for any reason, the app can close this session. When the download resumes, the app can reopen the session and start contributing again. Note that once the entire data is contributed, the app has no reason to hold on to the Session Id.
Since a data blob can be contributed in a session over multiple time intervals, an app closing a session does not imply that the contribution is completed. So, commit is added as an explicit event / signal for the app to indicate that the contribution of the data blob is completed. At this point, the System can verify the data blob does indeed correspond to the Blob handle used by the app and prevent the app from making any further modifications to the data blob. Once the data blob is committed and verified by the System, it is available for other applications to access.
When an application contributes a data blob to the System, it can choose to specify how it would like the System to share this data blob with other applications. Access modes refer to the type of access that apps specified when contributing a data blob. As of Android S release, there are four access modes:
Leasing a blob is a way to specify that an application is interested in using a data blob and would like the System to not delete this data blob. Applications can also access a blob without holding a lease on it, in which case the System can choose to delete the data blob at any time. So, if an application wants to make sure a data blob is available for access for a certain period, it is recommended that the application acquire a lease on the data blob. Applications can either specify upfront how long they would like to hold the lease for (which is called the lease expiry time), or they can acquire a lease without specifying a time period and release the lease when they are done with the data blob.
By default, data blobs are only accessible to applications in the user in which the data blob was contributed, but if an application holds the permission ACCESS_BLOBS_ACROSS_USERS, then they are allowed to access blobs that are contributed by the applications in the other users. As of Android S, this permission is only available to following set of applications:
Note that the access modes that applications choose while committing the data blobs still apply
when these data blobs are accessed across users. So for example, if appA contributed a
data blob in user0 and specified to share this data blob with only a specific set of
applications [appB, appC], then appD on user10 will not be able to access this data blob
even if the app is granted the ACCESS_BLOBS_ACROSS_USERS
permission.
When apps that are allowed to access blobs across users
(i.e. those holding the permission ACCESS_BLOBS_ACROSS_USERS
) try to access a data blob,
they can do so as if it is any other data blob. In other words, the applications don’t need to
know where the data blob is contributed, because the System will automatically check and will
allow access if this data blob is available either on the user in which the calling application
is running in or other users.