AppSearchSession

abstract void close()

Closes the AppSearchSession to persist all schema and document updates, additions, and deletes to disk.

@RequiresFeature(enforcement = "androidx.appsearch.app.Features#isFeatureSupported", name = Features.BLOB_STORAGE)
@ExperimentalAppSearchApi
default @NonNull ListenableFuture<CommitBlobResponse> commitBlobAsync(@NonNull Set<AppSearchBlobHandle> handles)

Commits the blobs to make it retrievable and immutable.

After this call, the blob is readable via openBlobForReadAsync. Any change to the content or rewrite via openBlobForWriteAsync of this blob won't be allowed.

If the blob is already stored in AppSearch and committed. A failed AppSearchResult with error code RESULT_ALREADY_EXISTS will be associated with the AppSearchBlobHandle.

If the blob content doesn't match the digest in AppSearchBlobHandle, a failed AppSearchResult with error code RESULT_INVALID_ARGUMENT will be associated with the AppSearchBlobHandle. The pending Blob file will be removed from AppSearch.

Pending blobs won't be lost or auto-commit if AppSearchSession closed. Pending blobs will store in disk rather than memory. You can re-open AppSearchSession and re-write the pending blobs.

The default time to recycle pending and orphan blobs is 1 week. A blob will be considered as an orphan if no GenericDocument references it.

Both pending blob files and committed blob files can be manually removed via removeBlobAsync.

abstract @NonNull ListenableFuture<AppSearchBatchResult<String, GenericDocument>> getByDocumentIdAsync(@NonNull GetByDocumentIdRequest request)

Gets GenericDocument objects by document IDs in a namespace from the AppSearchSession database.

abstract @NonNull Features getFeatures()

Returns the Features to check for the availability of certain features for this session.

abstract @NonNull ListenableFuture<Set<String>> getNamespacesAsync()

Retrieves the set of all namespaces in the current database with at least one document.

abstract @NonNull ListenableFuture<GetSchemaResponse> getSchemaAsync()

Retrieves the schema most recently successfully provided to setSchemaAsync.

abstract @NonNull ListenableFuture<StorageInfo> getStorageInfoAsync()

Gets the storage info for this AppSearchSession database.

This may take time proportional to the number of documents and may be inefficient to call repeatedly.

@RequiresFeature(enforcement = "androidx.appsearch.app.Features#isFeatureSupported", name = Features.BLOB_STORAGE)
@ExperimentalAppSearchApi
default @NonNull ListenableFuture<OpenBlobForReadResponse> openBlobForReadAsync(@NonNull Set<AppSearchBlobHandle> handles)

Opens a batch of AppSearch Blobs for reading.

Only blobs committed via commitBlobAsync are available for reading.

The returned OpenBlobForReadResponse must be closed after use to avoid resource leaks. Failing to close it will result in system file descriptor exhaustion.

@RequiresFeature(enforcement = "androidx.appsearch.app.Features#isFeatureSupported", name = Features.BLOB_STORAGE)
@ExperimentalAppSearchApi
default @NonNull ListenableFuture<OpenBlobForWriteResponse> openBlobForWriteAsync(@NonNull Set<AppSearchBlobHandle> handles)

Opens a batch of AppSearch Blobs for writing.

A "blob" is a large binary object. It is used to store a significant amount of data that is not searchable, such as images, videos, audio files, or other binary data. Unlike other fields in AppSearch, blobs are stored as blob files on disk rather than in memory, and use android.os.ParcelFileDescriptor to read and write. This allows for efficient handling of large, non-searchable content.

Once done writing, call commitBlobAsync to commit blob files.

This call will create a empty blob file for each given AppSearchBlobHandle, and a android.os.ParcelFileDescriptor of that blob file will be returned in the OpenBlobForWriteResponse.

If the blob file is already stored in AppSearch and committed. A failed AppSearchResult with error code RESULT_ALREADY_EXISTS will be associated with the AppSearchBlobHandle.

If the blob file is already stored in AppSearch but not committed. A android.os.ParcelFileDescriptor of that blob file will be returned for continue writing.

For given duplicate AppSearchBlobHandle, the same android.os.ParcelFileDescriptor pointing to the same blob file will be returned.

Pending blob files won't be lost or auto-commit if AppSearchSession closed. Pending blob files will be stored in disk rather than memory. You can re-open AppSearchSession and re-write the pending blob files.

A committed blob file will be considered as an orphan if no GenericDocument references it. Uncommitted pending blob files and orphan blobs files will be cleaned up if they has been created for an extended period (default is 1 week).

Both pending blob files and committed blob files can be manually removed via removeBlobAsync.

The returned OpenBlobForWriteResponse must be closed after use to avoid resource leaks. Failing to close it will result in system file descriptor exhaustion.

abstract @NonNull ListenableFuture<AppSearchBatchResult<String, Void>> putAsync(@NonNull PutDocumentsRequest request)

Indexes documents into the AppSearchSession database.

Each GenericDocument object must have a schemaType field set to an AppSearchSchema type that has been previously registered by calling the setSchemaAsync method.

abstract @NonNull ListenableFuture<AppSearchBatchResult<String, Void>> removeAsync(@NonNull RemoveByDocumentIdRequest request)

Removes GenericDocument objects by document IDs in a namespace from the AppSearchSession database.

Removed documents will no longer be surfaced by search or getByDocumentIdAsync calls.

Once the database crosses the document count or byte usage threshold, removed documents will be deleted from disk.

abstract @NonNull ListenableFuture<Void> removeAsync(
    @NonNull String queryExpression,
    @NonNull SearchSpec searchSpec
)

Removes GenericDocuments from the index by Query. Documents will be removed if they match the queryExpression in given namespaces and schemaTypes which is set via addFilterNamespaces and addFilterSchemas.

An empty queryExpression matches all documents.

An empty set of namespaces or schemaTypes matches all namespaces or schemaTypes in the current database.

@RequiresFeature(enforcement = "androidx.appsearch.app.Features#isFeatureSupported", name = Features.BLOB_STORAGE)
@ExperimentalAppSearchApi
default @NonNull ListenableFuture<RemoveBlobResponse> removeBlobAsync(@NonNull Set<AppSearchBlobHandle> handles)

Removes the blob data from AppSearch.

After this call, the blob data is removed immediately and cannot be recovered. It will not accessible via openBlobForReadAsync. openBlobForWriteAsync could reopen and rewrite it.

This API can be used to remove pending blob data and committed blob data.

Removing a committed blob data that is still referenced by documents will leave those documents with no readable blob content. It is highly recommended to let AppSearch control the blob data's life cycle. AppSearch automatically recycles orphaned and pending blob data. The default time to recycle pending and orphan blob file is 1 week. A blob file will be considered as an orphan if no GenericDocument references it. If you want to remove a committed blob data, you should remove the reference documents first.

abstract @NonNull ListenableFuture<Void> reportUsageAsync(@NonNull ReportUsageRequest request)

Reports usage of a particular document by namespace and ID.

A usage report represents an event in which a user interacted with or viewed a document.

For each call to reportUsageAsync, AppSearch updates usage count and usage recency * metrics for that particular document. These metrics are used for ordering search results by the RANKING_STRATEGY_USAGE_COUNT and RANKING_STRATEGY_USAGE_LAST_USED_TIMESTAMP ranking strategies.

Reporting usage of a document is optional.

abstract @NonNull ListenableFuture<Void> requestFlushAsync()

Flush all schema and document updates, additions, and deletes to disk if possible.

The request is not guaranteed to be handled and may be ignored by some implementations of AppSearchSession.

abstract @NonNull SearchResults search(@NonNull String queryExpression, @NonNull SearchSpec searchSpec)

Retrieves documents from the open AppSearchSession that match a given query string and type of search provided.

Query strings can be empty, contain one term with no operators, or contain multiple terms and operators.

For query strings that are empty, all documents that match the SearchSpec will be returned.

For query strings with a single term and no operators, documents that match the provided query string and SearchSpec will be returned.

The following operators are supported:

• AND (implicit)

  AND is an operator that matches documents that contain all provided terms.

  NOTE: A space between terms is treated as an "AND" operator. Explicitly including "AND" in a query string will treat "AND" as a term, returning documents that also contain "AND".

  Example: "apple AND banana" matches documents that contain the terms "apple", "and", "banana".

  Example: "apple banana" matches documents that contain both "apple" and "banana".

  Example: "apple banana cherry" matches documents that contain "apple", "banana", and "cherry".

• OR

  OR is an operator that matches documents that contain any provided term.

  Example: "apple OR banana" matches documents that contain either "apple" or "banana".

  Example: "apple OR banana OR cherry" matches documents that contain any of "apple", "banana", or "cherry".

• Exclusion (-)

  Exclusion (-) is an operator that matches documents that do not contain the provided term.

  Example: "-apple" matches documents that do not contain "apple".

• Grouped Terms

  For queries that require multiple operators and terms, terms can be grouped into subqueries. Subqueries are contained within an open "(" and close ")" parenthesis.

  Example: "(donut OR bagel) (coffee OR tea)" matches documents that contain either "donut" or "bagel" and either "coffee" or "tea".

• Property Restricts

  For queries that require a term to match a specific AppSearchSchema property of a document, a ":" must be included between the property name and the term.

  Example: "subject:important" matches documents that contain the term "important" in the "subject" property.

The above description covers the query operators that are supported on all versions of AppSearch. Additional operators and their required features are described below.

LIST_FILTER_QUERY_LANGUAGE: This feature covers the expansion of the query language to conform to the definition of the list filters language (https://aip .dev/160). This includes:

• addition of explicit 'AND' and 'NOT' operators
• property restricts are allowed with groupings (ex. "prop:(a OR b)")
• addition of custom functions to control matching

The newly added custom functions covered by this feature are:

• createList(String...)
• search(String, List<String>)
• propertyDefined(String)

createList takes a variable number of strings and returns a list of strings. It is for use with search.

search takes a query string that will be parsed according to the supported query language and an optional list of strings that specify the properties to be restricted to. This exists as a convenience for multiple property restricts. So, for example, the query `(subject:foo OR body:foo) (subject:bar OR body:bar)` could be rewritten as `search("foo bar", createList("subject", "body"))`.

propertyDefined takes a string specifying the property of interest and matches all documents of any type that defines the specified property (ex. `propertyDefined("sender.name")`). Note that propertyDefined will match so long as the document's type defines the specified property. Unlike the "hasProperty" function below, this function does NOT require that the document actually hold any values for this property.

NUMERIC_SEARCH: This feature covers numeric search expressions. In the query language, the values of properties that have INDEXING_TYPE_RANGE set can be matched with a numeric search expression (the property, a supported comparator and an integer value). Supported comparators are <, <=, ==, >= and >.

Ex. `price <10` will match all documents that has a numeric value in its price property that is less than 10.

VERBATIM_SEARCH: This feature covers the verbatim string operator (quotation marks).

Ex. `"foo/bar" OR baz` will ensure that 'foo/bar' is treated as a single 'verbatim' token.

LIST_FILTER_HAS_PROPERTY_FUNCTION: This feature covers the "hasProperty" function in query expressions, which takes a string specifying the property of interest and matches all documents that hold values for this property. Not to be confused with the "propertyDefined" function, which checks whether a document's schema has defined the property, instead of whether a document itself has this property.

Ex. `foo hasProperty("sender.name")` will return all documents that have the term "foo" AND have values in the property "sender.name". Consider two documents, documentA and documentB, of the same schema with an optional property "sender.name". If documentA sets "foo" in this property but documentB does not, then `hasProperty("sender.name")` will only match documentA. However, `propertyDefined("sender.name")` will match both documentA and documentB, regardless of whether a value is actually set.

LIST_FILTER_MATCH_SCORE_EXPRESSION_FUNCTION: This feature covers the "matchScoreExpression" function in query expressions.

Usage: matchScoreExpression({score_expression}, {low}, {high})

• matchScoreExpression matches all documents with scores falling within the specified range. These scores are calculated using the provided score expression, which adheres to the syntax defined in setRankingStrategy.
• "score_expression" is a string value that specifies the score expression.
• "low" and "high" are floating point numbers that specify the score range. The "high" parameter is optional; if not provided, it defaults to positive infinity.

Ex. `matchScoreExpression("this.documentScore()", 3, 4)` will return all documents that have document scores from 3 to 4.

SCHEMA_EMBEDDING_PROPERTY_CONFIG: This feature covers the "semanticSearch" and "getEmbeddingParameter" functions in query expressions, which are used for semantic search.

Usage: semanticSearch(getEmbeddingParameter({embedding_index}), {low}, {high}, {metric})

• semanticSearch matches all documents that have at least one embedding vector with a matching model signature (see getModelSignature) and a similarity score within the range specified based on the provided metric.
• getEmbeddingParameter({embedding_index}) retrieves the embedding search passed in addEmbeddingParameters based on the index specified, which starts from 0.
• "low" and "high" are floating point numbers that specify the similarity score range. If omitted, they default to negative and positive infinity, respectively.
• "metric" is a string value that specifies how embedding similarities should be calculated. If omitted, it default