AutofillService
abstract class AutofillService : Service
An AutofillService
is a service used to automatically fill the contents of the screen on behalf of a given user - for more information about autofill, read Autofill Framework.
An AutofillService
is only bound to the Android System for autofill purposes if:
- It requires the
android.permission.BIND_AUTOFILL_SERVICE
permission in its manifest.
- The user explicitly enables it using Android Settings (the
Settings#ACTION_REQUEST_SET_AUTOFILL_SERVICE
intent can be used to launch such Settings screen).
Basic usage
The basic autofill process is defined by the workflow below:
- User focus an editable
View
.
- View calls
AutofillManager#notifyViewEntered(android.view.View)
.
- A
ViewStructure
representing all views in the screen is created.
- The Android System binds to the service and calls
onConnected()
.
- The service receives the view structure through the
onFillRequest(android.service.autofill.FillRequest,android.os.CancellationSignal,android.service.autofill.FillCallback)
.
- The service replies through
FillCallback#onSuccess(FillResponse)
.
- The Android System calls
onDisconnected()
and unbinds from the AutofillService
.
- The Android System displays an autofill UI with the options sent by the service.
- The user picks an option.
- The proper views are autofilled.
This workflow was designed to minimize the time the Android System is bound to the service; for each call, it: binds to service, waits for the reply, and unbinds right away. Furthermore, those calls are considered stateless: if the service needs to keep state between calls, it must do its own state management (keeping in mind that the service's process might be killed by the Android System when unbound; for example, if the device is running low in memory).
Typically, the onFillRequest(android.service.autofill.FillRequest,android.os.CancellationSignal,android.service.autofill.FillCallback)
will:
- Parse the view structure looking for autofillable views (for example, using
android.app.assist.AssistStructure.ViewNode#getAutofillHints()
.
- Match the autofillable views with the user's data.
- Create a
Dataset
for each set of user's data that match those fields.
- Fill the dataset(s) with the proper
AutofillId
s and AutofillValue
s.
- Add the dataset(s) to the
FillResponse
passed to FillCallback#onSuccess(FillResponse)
.
For example, for a login screen with username and password views where the user only has one account in the service, the response could be:
new FillResponse.Builder()
.addDataset(new Dataset.Builder()
.setValue(id1, AutofillValue.forText("homer"), createPresentation("homer"))
.setValue(id2, AutofillValue.forText("D'OH!"), createPresentation("password for homer"))
.build())
.build();
But if the user had 2 accounts instead, the response could be:
new FillResponse.Builder()
.addDataset(new Dataset.Builder()
.setValue(id1, AutofillValue.forText("homer"), createPresentation("homer"))
.setValue(id2, AutofillValue.forText("D'OH!"), createPresentation("password for homer"))
.build())
.addDataset(new Dataset.Builder()
.setValue(id1, AutofillValue.forText("flanders"), createPresentation("flanders"))
.setValue(id2, AutofillValue.forText("OkelyDokelyDo"), createPresentation("password for flanders"))
.build())
.build();
If the service does not find any autofillable view in the view structure, it should pass null
to FillCallback#onSuccess(FillResponse)
; if the service encountered an error processing the request, it should call FillCallback#onFailure(CharSequence)
. For performance reasons, it's paramount that the service calls either FillCallback#onSuccess(FillResponse)
or FillCallback#onFailure(CharSequence)
for each onFillRequest(android.service.autofill.FillRequest,android.os.CancellationSignal,android.service.autofill.FillCallback)
received - if it doesn't, the request will eventually time out and be discarded by the Android System.
Saving user data
If the service is also interested on saving the data filled by the user, it must set a SaveInfo
object in the FillResponse
. See SaveInfo
for more details and examples.
User authentication
The service can provide an extra degree of security by requiring the user to authenticate before an app can be autofilled. The authentication is typically required in 2 scenarios:
When using authentication, it is recommended to encrypt only the sensitive data and leave labels unencrypted, so they can be used on presentation views. For example, if the user has a home and a work address, the Home
and Work
labels should be stored unencrypted (since they don't have any sensitive data) while the address data per se could be stored in an encrypted storage. Then when the user chooses the Home
dataset, the platform starts the authentication flow, and the service can decrypt the sensitive data.
The authentication mechanism can also be used in scenarios where the service needs multiple steps to determine the datasets that can fill a screen. For example, when autofilling a financial app where the user has accounts for multiple banks, the workflow could be:
- The first
FillResponse
contains datasets with the credentials for the financial app, plus a "fake" dataset whose presentation says "Tap here for banking apps credentials".
- When the user selects the fake dataset, the service displays a dialog with available banking apps.
- When the user select a banking app, the service replies with a new
FillResponse
containing the datasets for that bank.
Another example of multiple-steps dataset selection is when the service stores the user credentials in "vaults": the first response would contain fake datasets with the vault names, and the subsequent response would contain the app credentials stored in that vault.
Data partitioning
The autofillable views in a screen should be grouped in logical groups called "partitions". Typical partitions are:
- Credentials (username/email address, password).
- Address (street, city, state, zip code, etc).
- Payment info (credit card number, expiration date, and verification code).
For security reasons, when a screen has more than one partition, it's paramount that the contents of a dataset do not spawn multiple partitions, specially when one of the partitions contains data that is not specific to the application being autofilled. For example, a dataset should not contain fields for username, password, and credit card information. The reason for this rule is that a malicious app could draft a view structure where the credit card fields are not visible, so when the user selects a dataset from the username UI, the credit card info is released to the application without the user knowledge. Similarly, it's recommended to always protect a dataset that contains sensitive information by requiring dataset authentication (see Dataset.Builder#setAuthentication(android.content.IntentSender)
), and to include info about the "primary" field of the partition in the custom presentation for "secondary" fields—that would prevent a malicious app from getting the "primary" fields without the user realizing they're being released (for example, a malicious app could have fields for a credit card number, verification code, and expiration date crafted in a way that just the latter is visible; by explicitly indicating the expiration date is related to a given credit card number, the service would be providing a visual clue for the users to check what would be released upon selecting that field).
When the service detects that a screen has multiple partitions, it should return a FillResponse
with just the datasets for the partition that originated the request (i.e., the partition that has the android.app.assist.AssistStructure.ViewNode
whose android.app.assist.AssistStructure.ViewNode#isFocused()
returns true
); then if the user selects a field from a different partition, the Android System will make another onFillRequest(android.service.autofill.FillRequest,android.os.CancellationSignal,android.service.autofill.FillCallback)
call for that partition, and so on.
Notice that when the user autofill a partition with the data provided by the service and the user did not change these fields, the autofilled value is sent back to the service in the subsequent calls (and can be obtained by calling android.app.assist.AssistStructure.ViewNode#getAutofillValue()
). This is useful in the cases where the service must create datasets for a partition based on the choice made in a previous partition. For example, the 1st response for a screen that have credentials and address partitions could be:
new FillResponse.Builder()
.addDataset(new Dataset.Builder() // partition 1 (credentials)
.setValue(id1, AutofillValue.forText("homer"), createPresentation("homer"))
.setValue(id2, AutofillValue.forText("D'OH!"), createPresentation("password for homer"))
.build())
.addDataset(new Dataset.Builder() // partition 1 (credentials)
.setValue(id1, AutofillValue.forText("flanders"), createPresentation("flanders"))
.setValue(id2, AutofillValue.forText("OkelyDokelyDo"), createPresentation("password for flanders"))
.build())
.setSaveInfo(new SaveInfo.Builder(SaveInfo.SAVE_DATA_TYPE_PASSWORD,
new AutofillId[] { id1, id2 })
.build())
.build();
Then if the user selected flanders
, the service would get a new onFillRequest(android.service.autofill.FillRequest,android.os.CancellationSignal,android.service.autofill.FillCallback)
call, with the values of the fields id1
and id2
prepopulated, so the service could then fetch the address for the Flanders account and return the following FillResponse
for the address partition:
new FillResponse.Builder()
.addDataset(new Dataset.Builder() // partition 2 (address)
.setValue(id3, AutofillValue.forText("744 Evergreen Terrace"), createPresentation("744 Evergreen Terrace")) // street
.setValue(id4, AutofillValue.forText("Springfield"), createPresentation("Springfield")) // city
.build())
.setSaveInfo(new SaveInfo.Builder(SaveInfo.SAVE_DATA_TYPE_PASSWORD | SaveInfo.SAVE_DATA_TYPE_ADDRESS,
new AutofillId[] { id1, id2 }) // username and password
.setOptionalIds(new AutofillId[] { id3, id4 }) // state and zipcode
.build())
.build();
When the service returns multiple FillResponse
, the last one overrides the previous; that's why the SaveInfo
in the 2nd request above has the info for both partitions.
Package verification
When autofilling app-specific data (like username and password), the service must verify the authenticity of the request by obtaining all signing certificates of the app being autofilled, and only fulfilling the request when they match the values that were obtained when the data was first saved — such verification is necessary to avoid phishing attempts by apps that were sideloaded in the device with the same package name of another app. Here's an example on how to achieve that by hashing the signing certificates:
private String getCertificatesHash(String packageName) throws Exception {
PackageManager pm = mContext.getPackageManager();
PackageInfo info = pm.getPackageInfo(packageName, PackageManager.GET_SIGNATURES);
ArrayList<string>
hashes = new ArrayList<>(info.signatures.length);
for (Signature sig : info.signatures) {
byte[] cert = sig.toByteArray();
MessageDigest md = MessageDigest.getInstance("SHA-256");
md.update(cert);
hashes.add(toHexString(md.digest()));
}
Collections.sort(hashes);
StringBuilder hash = new StringBuilder();
for (int i = 0; i < hashes.size(); i++) {
hash.append(hashes.get(i));
}
return hash.toString();
}
</string>
If the service did not store the signing certificates data the first time the data was saved — for example, because the data was created by a previous version of the app that did not use the Autofill Framework — the service should warn the user that the authenticity of the app cannot be confirmed (see an example on how to show such warning in the Web security section below), and if the user agrees, then the service could save the data from the signing ceriticates for future use.
Ignoring views
If the service find views that cannot be autofilled (for example, a text field representing the response to a Captcha challenge), it should mark those views as ignored by calling FillResponse.Builder#setIgnoredIds(AutofillId...)
so the system does not trigger a new onFillRequest(android.service.autofill.FillRequest,android.os.CancellationSignal,android.service.autofill.FillCallback)
when these views are focused.
Web security
When handling autofill requests that represent web pages (typically view structures whose root's android.app.assist.AssistStructure.ViewNode#getClassName()
is a android.webkit.WebView
), the service should take the following steps to verify if the structure can be autofilled with the data associated with the app requesting it:
- Use the
android.app.assist.AssistStructure.ViewNode#getWebDomain()
to get the source of the document.
- Get the canonical domain using the Public Suffix List (see example below).
- Use Digital Asset Links to obtain the package name and certificate fingerprint of the package corresponding to the canonical domain.
- Make sure the certificate fingerprint matches the value returned by Package Manager (see "Package verification" section above).
Here's an example on how to get the canonical domain using Guava:
private static String getCanonicalDomain(String domain) {
InternetDomainName idn = InternetDomainName.from(domain);
while (idn != null && !idn.isTopPrivateDomain()) {
idn = idn.parent();
}
return idn == null ? null : idn.toString();
}
If the association between the web domain and app package cannot be verified through the steps above, but the service thinks that it is appropriate to fill persisted credentials that are stored for the web domain, the service should warn the user about the potential data leakage first, and ask for the user to confirm. For example, the service could:
- Create a dataset that requires
authentication
to unlock.
- Include the web domain in the custom presentation for the
dataset value
.
- When the user selects that dataset, show a disclaimer dialog explaining that the app is requesting credentials for a web domain, but the service could not verify if the app owns that domain. If the user agrees, then the service can unlock the dataset.
- Similarly, when adding a
SaveInfo
object for the request, the service should include the above disclaimer in the SaveInfo.Builder#setDescription(CharSequence)
.
This same procedure could also be used when the autofillable data is contained inside an IFRAME
, in which case the WebView generates a new autofill context when a node inside the IFRAME
is focused, with the root node containing the IFRAME
's src
attribute on android.app.assist.AssistStructure.ViewNode#getWebDomain()
. A typical and legitimate use case for this scenario is a financial app that allows the user to login on different bank accounts. For example, a financial app my_financial_app
could use a WebView that loads contents from banklogin.my_financial_app.com
, which contains an IFRAME
node whose src
attribute is login.some_bank.com
. When fulfilling that request, the service could add an authenticated dataset
whose presentation displays "Username for some_bank.com" and "Password for some_bank.com". Then when the user taps one of these options, the service shows the disclaimer dialog explaining that selecting that option would release the login.some_bank.com
credentials to the my_financial_app
; if the user agrees, then the service returns an unlocked dataset with the some_bank.com
credentials.
Note: The autofill service could also add well-known browser apps into an allowlist and skip the verifications above, as long as the service can verify the authenticity of the browser app by checking its signing certificate.
Saving when data is split in multiple screens
Apps often split the user data in multiple screens in the same activity, specially in activities used to create a new user account. For example, the first screen asks for a username, and if the username is available, it moves to a second screen, which asks for a password.
It's tricky to handle save for autofill in these situations, because the autofill service must wait until the user enters both fields before the autofill save UI can be shown. But it can be done by following the steps below:
- In the first
fill request
, the service adds a client state bundle
in the response, containing the autofill ids of the partial fields present in the screen.
- In the second
fill request
, the service retrieves the client state bundle
, gets the autofill ids set in the previous request from the client state, and adds these ids and the SaveInfo#FLAG_SAVE_ON_ALL_VIEWS_INVISIBLE
to the SaveInfo
used in the second response.
- In the
save request
, the service uses the proper fill contexts
to get the value of each field (there is one fill context per fill request).
For example, in an app that uses 2 steps for the username and password fields, the workflow would be:
// On first fill request
AutofillId usernameId = // parse from AssistStructure;
Bundle clientState = new Bundle();
clientState.putParcelable("usernameId", usernameId);
fillCallback.onSuccess(
new FillResponse.Builder()
.setClientState(clientState)
.setSaveInfo(new SaveInfo
.Builder(SaveInfo.SAVE_DATA_TYPE_USERNAME, new AutofillId[] {usernameId})
.build())
.build());
// On second fill request
Bundle clientState = fillRequest.getClientState();
AutofillId usernameId = clientState.getParcelable("usernameId");
AutofillId passwordId = // parse from AssistStructure
clientState.putParcelable("passwordId", passwordId);
fillCallback.onSuccess(
new FillResponse.Builder()
.setClientState(clientState)
.setSaveInfo(new SaveInfo
.Builder(SaveInfo.SAVE_DATA_TYPE_USERNAME | SaveInfo.SAVE_DATA_TYPE_PASSWORD,
new AutofillId[] {usernameId, passwordId})
.setFlags(SaveInfo.FLAG_SAVE_ON_ALL_VIEWS_INVISIBLE)
.build())
.build());
// On save request
Bundle clientState = saveRequest.getClientState();
AutofillId usernameId = clientState.getParcelable("usernameId");
AutofillId passwordId = clientState.getParcelable("passwordId");
List<fillcontext>
fillContexts = saveRequest.getFillContexts();
FillContext usernameContext = fillContexts.get(0);
ViewNode usernameNode = findNodeByAutofillId(usernameContext.getStructure(), usernameId);
AutofillValue username = usernameNode.getAutofillValue().getTextValue().toString();
FillContext passwordContext = fillContexts.get(1);
ViewNode passwordNode = findNodeByAutofillId(passwordContext.getStructure(), passwordId);
AutofillValue password = passwordNode.getAutofillValue().getTextValue().toString();
save(username, password);
</fillcontext>
Privacy
The onFillRequest(android.service.autofill.FillRequest,android.os.CancellationSignal,android.service.autofill.FillCallback)
method is called without the user content. The Android system strips some properties of the view nodes
passed to this call, but not all of them. For example, the data provided in the android.view.ViewStructure.HtmlInfo
objects set by android.webkit.WebView
is never stripped out.
Because this data could contain PII (Personally Identifiable Information, such as username or email address), the service should only use it locally (i.e., in the app's process) for heuristics purposes, but it should not be sent to external servers.
Metrics and field classification
The service can call getFillEventHistory()
to get metrics representing the user actions, and then use these metrics to improve its heuristics.
Prior to Android android.os.Build.VERSION_CODES#P
, the metrics covered just the scenarios where the service knew how to autofill an activity, but Android android.os.Build.VERSION_CODES#P
introduced a new mechanism called field classification, which allows the service to dynamically classify the meaning of fields based on the existing user data known by the service.
Typically, field classification can be used to detect fields that can be autofilled with user data that is not associated with a specific app—such as email and physical address. Once the service identifies that a such field was manually filled by the user, the service could use this signal to improve its heuristics on subsequent requests (for example, by infering which resource ids are associated with known fields).
The field classification workflow involves 4 steps:
- Set the user data through
AutofillManager#setUserData(UserData)
. This data is cached until the system restarts (or the service is disabled), so it doesn't need to be set for all requests.
- Identify which fields should be analysed by calling
FillResponse.Builder#setFieldClassificationIds(AutofillId...)
.
- Verify the results through
FillEventHistory.Event#getFieldsClassification()
.
- Use the results to dynamically create
Dataset
or SaveInfo
objects in subsequent requests.
The field classification is an expensive operation and should be used carefully, otherwise it can reach its rate limit and get blocked by the Android System. Ideally, it should be used just in cases where the service could not determine how an activity can be autofilled, but it has a strong suspicious that it could. For example, if an activity has four or more fields and one of them is a list, chances are that these are address fields (like address, city, state, and zip code).
Compatibility mode
Apps that use standard Android widgets support autofill out-of-the-box and need to do very little to improve their user experience (annotating autofillable views and providing autofill hints). However, some apps (typically browsers) do their own rendering and the rendered content may contain semantic structure that needs to be surfaced to the autofill framework. The platform exposes APIs to achieve this, however it could take some time until these apps implement autofill support.
To enable autofill for such apps the platform provides a compatibility mode in which the platform would fall back to the accessibility APIs to generate the state reported to autofill services and fill data. This mode needs to be explicitly requested for a given package up to a specified max version code allowing clean migration path when the target app begins to support autofill natively. Note that enabling compatibility may degrade performance for the target package and should be used with caution. The platform supports creating an allowlist for including which packages can be targeted in compatibility mode to ensure this mode is used only when needed and as long as needed.
You can request compatibility mode for packages of interest in the meta-data resource associated with your service. Below is a sample service declaration:
<service android:name=".MyAutofillService"
android:permission="android.permission.BIND_AUTOFILL_SERVICE">
<intent-filter>
<action android:name="android.service.autofill.AutofillService" />
</intent-filter>
<meta-data android:name="android.autofill" android:resource="@xml/autofillservice" />
</service>
In the XML file you can specify one or more packages for which to enable compatibility mode. Below is a sample meta-data declaration:
<autofill-service xmlns:android="http://schemas.android.com/apk/res/android">
<compatibility-package android:name="foo.bar.baz" android:maxLongVersionCode="1000000000"/>
</autofill-service>
Notice that compatibility mode has limitations such as:
- No manual autofill requests. Hence, the
FillRequest
flags
never have the FillRequest#FLAG_MANUAL_REQUEST
flag.
- The value of password fields are most likely masked—for example,
****
instead of 1234
. Hence, you must be careful when using these values to avoid updating the user data with invalid input. For example, when you parse the FillRequest
and detect a password field, you could check if its input type
has password flags and if so, don't add it to the SaveInfo
object.
- The autofill context is not always
committed
when an HTML form is submitted. Hence, you must use other mechanisms to trigger save, such as setting the SaveInfo#FLAG_SAVE_ON_ALL_VIEWS_INVISIBLE
flag on SaveInfo.Builder#setFlags(int)
or using SaveInfo.Builder#setTriggerId(AutofillId)
.
- Browsers often provide their own autofill management system. When both the browser and the platform render an autofill dialog at the same time, the result can be confusing to the user. Such browsers typically offer an option for users to disable autofill, so your service should also allow users to disable compatiblity mode for specific apps. That way, it is up to the user to decide which autofill mechanism—the browser's or the platform's—should be used.
Summary
Constants |
static String |
Name of the FillResponse extra used to return a delayed fill response.
|
static String |
The Intent that must be declared as handled by the service.
|
static String |
Name under which a AutoFillService component publishes information about itself.
|
Inherited constants |
From class Context
String |
ACCESSIBILITY_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.view.accessibility.AccessibilityManager for giving the user feedback for UI events through the registered event listeners.
|
String |
ACCOUNT_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.accounts.AccountManager for receiving intents at a time of your choosing.
|
String |
ACTIVITY_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.app.ActivityManager for interacting with the global system state.
|
String |
ALARM_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.app.AlarmManager for receiving intents at a time of your choosing.
|
String |
APPWIDGET_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.appwidget.AppWidgetManager for accessing AppWidgets.
|
String |
APP_OPS_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.app.AppOpsManager for tracking application operations on the device.
|
String |
APP_SEARCH_SERVICE
Use with getSystemService(java.lang.String) to retrieve an android.app.appsearch.AppSearchManager for indexing and querying app data managed by the system.
|
String |
AUDIO_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.media.AudioManager for handling management of volume, ringer modes and audio routing.
|
String |
BATTERY_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.os.BatteryManager for managing battery state.
|
Int |
BIND_ABOVE_CLIENT
Flag for #bindService: indicates that the client application binding to this service considers the service to be more important than the app itself. When set, the platform will try to have the out of memory killer kill the app before it kills the service it is bound to, though this is not guaranteed to be the case.
|
Int |
BIND_ADJUST_WITH_ACTIVITY
Flag for #bindService: If binding from an activity, allow the target service's process importance to be raised based on whether the activity is visible to the user, regardless whether another flag is used to reduce the amount that the client process's overall importance is used to impact it.
|
Int |
BIND_ALLOW_ACTIVITY_STARTS
Flag for #bindService: If binding from an app that is visible, the bound service is allowed to start an activity from background. This was the default behavior before SDK version android.os.Build.VERSION_CODES#UPSIDE_DOWN_CAKE . Since then, the default behavior changed to disallow the bound service to start a background activity even if the app bound to it is in foreground, unless this flag is specified when binding.
|
Int |
BIND_ALLOW_OOM_MANAGEMENT
Flag for #bindService: allow the process hosting the bound service to go through its normal memory management. It will be treated more like a running service, allowing the system to (temporarily) expunge the process if low on memory or for some other whim it may have, and being more aggressive about making it a candidate to be killed (and restarted) if running for a long time.
|
Int |
BIND_AUTO_CREATE
Flag for #bindService: automatically create the service as long as the binding exists. Note that while this will create the service, its android.app.Service#onStartCommand method will still only be called due to an explicit call to startService . Even without that, though, this still provides you with access to the service object while the service is created.
Note that prior to android.os.Build.VERSION_CODES#ICE_CREAM_SANDWICH , not supplying this flag would also impact how important the system consider's the target service's process to be. When set, the only way for it to be raised was by binding from a service in which case it will only be important when that activity is in the foreground. Now to achieve this behavior you must explicitly supply the new flag BIND_ADJUST_WITH_ACTIVITY . For compatibility, old applications that don't specify BIND_AUTO_CREATE will automatically have the flags BIND_WAIVE_PRIORITY and BIND_ADJUST_WITH_ACTIVITY set for them in order to achieve the same result.
|
Int |
BIND_DEBUG_UNBIND
Flag for #bindService: include debugging help for mismatched calls to unbind. When this flag is set, the callstack of the following unbindService call is retained, to be printed if a later incorrect unbind call is made. Note that doing this requires retaining information about the binding that was made for the lifetime of the app, resulting in a leak -- this should only be used for debugging.
|
Int |
BIND_EXTERNAL_SERVICE
Flag for #bindService: The service being bound is an isolated , external service. This binds the service into the calling application's package, rather than the package in which the service is declared.
When using this flag, the code for the service being bound will execute under the calling application's package name and user ID. Because the service must be an isolated process, it will not have direct access to the application's data, though. The purpose of this flag is to allow applications to provide services that are attributed to the app using the service, rather than the application providing the service.
This flag is NOT compatible with BindServiceFlags . If you need to use BindServiceFlags , you must use BIND_EXTERNAL_SERVICE_LONG instead.
|
Long |
BIND_EXTERNAL_SERVICE_LONG
Works in the same way as BIND_EXTERNAL_SERVICE , but it's defined as a long value that is compatible to BindServiceFlags .
|
Int |
BIND_IMPORTANT
Flag for #bindService: this service is very important to the client, so should be brought to the foreground process level when the client is. Normally a process can only be raised to the visibility level by a client, even if that client is in the foreground.
|
Int |
BIND_INCLUDE_CAPABILITIES
Flag for #bindService: If binding from an app that has specific capabilities due to its foreground state such as an activity or foreground service, then this flag will allow the bound app to get the same capabilities, as long as it has the required permissions as well. If binding from a top app and its target SDK version is at or above android.os.Build.VERSION_CODES#R , the app needs to explicitly use BIND_INCLUDE_CAPABILITIES flag to pass all capabilities to the service so the other app can have while-in-use access such as location, camera, microphone from background. If binding from a top app and its target SDK version is below android.os.Build.VERSION_CODES#R , BIND_INCLUDE_CAPABILITIES is implicit.
|
Int |
BIND_NOT_FOREGROUND
Flag for #bindService: don't allow this binding to raise the target service's process to the foreground scheduling priority. It will still be raised to at least the same memory priority as the client (so that its process will not be killable in any situation where the client is not killable), but for CPU scheduling purposes it may be left in the background. This only has an impact in the situation where the binding client is a foreground process and the target service is in a background process.
|
Int |
BIND_NOT_PERCEPTIBLE
Flag for #bindService: If binding from an app that is visible or user-perceptible, lower the target service's importance to below the perceptible level. This allows the system to (temporarily) expunge the bound process from memory to make room for more important user-perceptible processes.
|
Int |
BIND_PACKAGE_ISOLATED_PROCESS
Flag for #bindIsolatedService: Bind the service into a shared isolated process, but only with other isolated services from the same package that declare the same process name.
Specifying this flag allows multiple isolated services defined in the same package to be running in a single shared isolated process. This shared isolated process must be specified since this flag will not work with the default application process.
This flag is different from BIND_SHARED_ISOLATED_PROCESS since it only allows binding services from the same package in the same shared isolated process. This also means the shared package isolated process is global, and not scoped to each potential calling app.
The shared isolated process instance is identified by the "android:process" attribute defined by the service. This flag cannot be used without this attribute set.
|
Int |
BIND_SHARED_ISOLATED_PROCESS
Flag for #bindIsolatedService: Bind the service into a shared isolated process. Specifying this flag allows multiple isolated services to be running in a single shared isolated process. The shared isolated process instance is identified by the instanceName parameter in bindIsolatedService(android.content.Intent,int,java.lang.String,java.util.concurrent.Executor,android.content.ServiceConnection) . Subsequent calls to #bindIsolatedService with the same instanceName will cause the isolated service to be co-located in the same shared isolated process. Note that the shared isolated process is scoped to the calling app; once created, only the calling app can bind additional isolated services into the shared process. However, the services themselves can come from different APKs and therefore different vendors. Only services that set the android.R.attr#allowSharedIsolatedProcess attribute to true are allowed to be bound into a shared isolated process.
|
Int |
BIND_WAIVE_PRIORITY
Flag for #bindService: don't impact the scheduling or memory management priority of the target service's hosting process. Allows the service's process to be managed on the background LRU list just like a regular application process in the background.
|
String |
BIOMETRIC_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.hardware.biometrics.BiometricManager for handling biometric and PIN/pattern/password authentication.
|
String |
BLOB_STORE_SERVICE
Use with getSystemService(java.lang.String) to retrieve a for contributing and accessing data blobs from the blob store maintained by the system.
|
String |
BLUETOOTH_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.bluetooth.BluetoothManager for using Bluetooth.
|
String |
BUGREPORT_SERVICE
Service to capture a bugreport.
|
String |
CAMERA_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.hardware.camera2.CameraManager for interacting with camera devices.
|
String |
CAPTIONING_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.view.accessibility.CaptioningManager for obtaining captioning properties and listening for changes in captioning preferences.
|
String |
CARRIER_CONFIG_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.telephony.CarrierConfigManager for reading carrier configuration values.
|
String |
CLIPBOARD_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.content.ClipboardManager for accessing and modifying the contents of the global clipboard.
|
String |
COMPANION_DEVICE_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.companion.CompanionDeviceManager for managing companion devices
|
String |
CONNECTIVITY_DIAGNOSTICS_SERVICE
Use with getSystemService(java.lang.String) to retrieve a for performing network connectivity diagnostics as well as receiving network connectivity information from the system.
|
String |
CONNECTIVITY_SERVICE
Use with getSystemService(java.lang.String) to retrieve a for handling management of network connections.
|
String |
CONSUMER_IR_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.hardware.ConsumerIrManager for transmitting infrared signals from the device.
|
String |
CONTACT_KEYS_SERVICE
Use with getSystemService(java.lang.String) to retrieve a E2eeContactKeysManager to managing contact keys.
|
Int |
CONTEXT_IGNORE_SECURITY
Flag for use with createPackageContext : ignore any security restrictions on the Context being requested, allowing it to always be loaded. For use with CONTEXT_INCLUDE_CODE to allow code to be loaded into a process even when it isn't safe to do so. Use with extreme care!
|
Int |
CONTEXT_INCLUDE_CODE
Flag for use with createPackageContext : include the application code with the context. This means loading code into the caller's process, so that getClassLoader() can be used to instantiate the application's classes. Setting this flags imposes security restrictions on what application context you can access; if the requested application can not be safely loaded into your process, java.lang.SecurityException will be thrown. If this flag is not set, there will be no restrictions on the packages that can be loaded, but getClassLoader will always return the default system class loader.
|
Int |
CONTEXT_RESTRICTED
Flag for use with createPackageContext : a restricted context may disable specific features. For instance, a View associated with a restricted context would ignore particular XML attributes.
|
String |
CREDENTIAL_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.credentials.CredentialManager to authenticate a user to your app.
|
String |
CROSS_PROFILE_APPS_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.content.pm.CrossProfileApps for cross profile operations.
|
Int |
DEVICE_ID_DEFAULT
The default device ID, which is the ID of the primary (non-virtual) device.
|
Int |
DEVICE_ID_INVALID
Invalid device ID.
|
String |
DEVICE_LOCK_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.devicelock.DeviceLockManager .
|
String |
DEVICE_POLICY_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.app.admin.DevicePolicyManager for working with global device policy management.
|
String |
DISPLAY_HASH_SERVICE
Use with getSystemService(java.lang.String) to access android.view.displayhash.DisplayHashManager to handle display hashes.
|
String |
DISPLAY_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.hardware.display.DisplayManager for interacting with display devices.
|
String |
DOMAIN_VERIFICATION_SERVICE
Use with getSystemService(java.lang.String) to access android.content.pm.verify.domain.DomainVerificationManager to retrieve approval and user state for declared web domains.
|
String |
DOWNLOAD_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.app.DownloadManager for requesting HTTP downloads.
|
String |
DROPBOX_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.os.DropBoxManager instance for recording diagnostic logs.
|
String |
EUICC_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.telephony.euicc.EuiccManager to manage the device eUICC (embedded SIM).
|
String |
FILE_INTEGRITY_SERVICE
Use with getSystemService(java.lang.String) to retrieve an android.security.FileIntegrityManager .
|
String |
FINGERPRINT_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.hardware.fingerprint.FingerprintManager for handling management of fingerprints.
|
String |
GAME_SERVICE
Use with getSystemService(java.lang.String) to retrieve a GameManager .
|
String |
GRAMMATICAL_INFLECTION_SERVICE
Use with getSystemService(java.lang.String) to retrieve a GrammaticalInflectionManager .
|
String |
HARDWARE_PROPERTIES_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.os.HardwarePropertiesManager for accessing the hardware properties service.
|
String |
HEALTHCONNECT_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.health.connect.HealthConnectManager .
|
String |
INPUT_METHOD_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.view.inputmethod.InputMethodManager for accessing input methods.
|
String |
INPUT_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.hardware.input.InputManager for interacting with input devices.
|
String |
IPSEC_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.net.IpSecManager for encrypting Sockets or Networks with IPSec.
|
String |
JOB_SCHEDULER_SERVICE
Use with getSystemService(java.lang.String) to retrieve a instance for managing occasional background tasks.
|
String |
KEYGUARD_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.app.KeyguardManager for controlling keyguard.
|
String |
LAUNCHER_APPS_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.content.pm.LauncherApps for querying and monitoring launchable apps across profiles of a user.
|
String |
LAYOUT_INFLATER_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.view.LayoutInflater for inflating layout resources in this context.
|
String |
LOCALE_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.app.LocaleManager .
|
String |
LOCATION_SERVICE
Use with getSystemService(java.lang.String) to retrieve a for controlling location updates.
|
String |
MEDIA_COMMUNICATION_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.media.MediaCommunicationManager for managing android.media.MediaSession2 .
|
String |
MEDIA_METRICS_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.media.metrics.MediaMetricsManager for interacting with media metrics on the device.
|
String |
MEDIA_PROJECTION_SERVICE
Use with getSystemService(java.lang.String) to retrieve a instance for managing media projection sessions.
|
String |
MEDIA_ROUTER_SERVICE
Use with #getSystemService to retrieve a android.media.MediaRouter for controlling and managing routing of media.
|
String |
MEDIA_SESSION_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.media.session.MediaSessionManager for managing media Sessions.
|
String |
MIDI_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.media.midi.MidiManager for accessing the MIDI service.
|
Int |
MODE_APPEND
File creation mode: for use with openFileOutput , if the file already exists then write data to the end of the existing file instead of erasing it.
|
Int |
MODE_ENABLE_WRITE_AHEAD_LOGGING
Database open flag: when set, the database is opened with write-ahead logging enabled by default.
|
Int |
MODE_MULTI_PROCESS
SharedPreference loading flag: when set, the file on disk will be checked for modification even if the shared preferences instance is already loaded in this process. This behavior is sometimes desired in cases where the application has multiple processes, all writing to the same SharedPreferences file. Generally there are better forms of communication between processes, though.
This was the legacy (but undocumented) behavior in and before Gingerbread (Android 2.3) and this flag is implied when targeting such releases. For applications targeting SDK versions greater than Android 2.3, this flag must be explicitly set if desired.
|
Int |
MODE_NO_LOCALIZED_COLLATORS
Database open flag: when set, the database is opened without support for localized collators.
|
Int |
MODE_PRIVATE
File creation mode: the default mode, where the created file can only be accessed by the calling application (or all applications sharing the same user ID).
|
Int |
MODE_WORLD_READABLE
File creation mode: allow all other applications to have read access to the created file.
Starting from android.os.Build.VERSION_CODES#N , attempting to use this mode throws a SecurityException .
|
Int |
MODE_WORLD_WRITEABLE
File creation mode: allow all other applications to have write access to the created file.
Starting from android.os.Build.VERSION_CODES#N , attempting to use this mode will throw a SecurityException .
|
String |
NETWORK_STATS_SERVICE
Use with getSystemService(java.lang.String) to retrieve a for querying network usage stats.
|
String |
NFC_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.nfc.NfcManager for using NFC.
|
String |
NOTIFICATION_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.app.NotificationManager for informing the user of background events.
|
String |
NSD_SERVICE
Use with getSystemService(java.lang.String) to retrieve a for handling management of network service discovery
|
String |
OVERLAY_SERVICE
Use with getSystemService(java.lang.String) to retrieve a for managing overlay packages.
|
String |
PEOPLE_SERVICE
Use with getSystemService(java.lang.String) to access a PeopleManager to interact with your published conversations.
|
String |
PERFORMANCE_HINT_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.os.PerformanceHintManager for accessing the performance hinting service.
|
String |
PERSISTENT_DATA_BLOCK_SERVICE
Use with getSystemService(java.lang.String) to retrieve a instance for interacting with a storage device that lives across factory resets.
|
String |
POWER_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.os.PowerManager for controlling power management, including "wake locks," which let you keep the device on while you're running long tasks.
|
String |
PRINT_SERVICE
android.print.PrintManager for printing and managing printers and print tasks.
|
String |
PROFILING_SERVICE
Use with getSystemService(java.lang.String) to retrieve an android.os.ProfilingManager .
|
Int |
RECEIVER_EXPORTED
Flag for #registerReceiver: The receiver can receive broadcasts from other Apps. Has the same behavior as marking a statically registered receiver with "exported=true"
|
Int |
RECEIVER_NOT_EXPORTED
Flag for #registerReceiver: The receiver cannot receive broadcasts from other Apps. Has the same behavior as marking a statically registered receiver with "exported=false"
|
Int |
RECEIVER_VISIBLE_TO_INSTANT_APPS
Flag for #registerReceiver: The receiver can receive broadcasts from Instant Apps.
|
String |
RESTRICTIONS_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.content.RestrictionsManager for retrieving application restrictions and requesting permissions for restricted operations.
|
String |
ROLE_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.app.role.RoleManager for managing roles.
|
String |
SEARCH_SERVICE
Use with getSystemService(java.lang.String) to retrieve a for handling searches.
Configuration#UI_MODE_TYPE_WATCH does not support android.app.SearchManager .
|
String |
SECURITY_STATE_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.os.SecurityStateManager for accessing the security state manager service.
|
String |
SENSOR_SERVICE
Use with getSystemService(java.lang.String) to retrieve a for accessing sensors.
|
String |
SHORTCUT_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.content.pm.ShortcutManager for accessing the launcher shortcut service.
|
String |
STATUS_BAR_SERVICE
Use with getSystemService(java.lang.String) to retrieve a for interacting with the status bar and quick settings.
|
String |
STORAGE_SERVICE
Use with getSystemService(java.lang.String) to retrieve a for accessing system storage functions.
|
String |
STORAGE_STATS_SERVICE
Use with getSystemService(java.lang.String) to retrieve a for accessing system storage statistics.
|
String |
SYSTEM_HEALTH_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.os.health.SystemHealthManager for accessing system health (battery, power, memory, etc) metrics.
|
String |
TELECOM_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.telecom.TelecomManager to manage telecom-related features of the device.
|
String |
TELEPHONY_IMS_SERVICE
Use with getSystemService(java.lang.String) to retrieve an android.telephony.ims.ImsManager .
|
String |
TELEPHONY_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.telephony.TelephonyManager for handling management the telephony features of the device.
|
String |
TELEPHONY_SUBSCRIPTION_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.telephony.SubscriptionManager for handling management the telephony subscriptions of the device.
|
String |
TEXT_CLASSIFICATION_SERVICE
Use with getSystemService(java.lang.String) to retrieve a TextClassificationManager for text classification services.
|
String |
TEXT_SERVICES_MANAGER_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.view.textservice.TextServicesManager for accessing text services.
|
String |
TV_INPUT_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.media.tv.TvInputManager for interacting with TV inputs on the device.
|
String |
TV_INTERACTIVE_APP_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.media.tv.interactive.TvInteractiveAppManager for interacting with TV interactive applications on the device.
|
String |
UI_MODE_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.app.UiModeManager for controlling UI modes.
|
String |
USAGE_STATS_SERVICE
Use with getSystemService(java.lang.String) to retrieve a for querying device usage stats.
|
String |
USB_SERVICE
Use with getSystemService(java.lang.String) to retrieve a for access to USB devices (as a USB host) and for controlling this device's behavior as a USB device.
|
String |
USER_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.os.UserManager for managing users on devices that support multiple users.
|
String |
VIBRATOR_MANAGER_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.os.VibratorManager for accessing the device vibrators, interacting with individual ones and playing synchronized effects on multiple vibrators.
|
String |
VIBRATOR_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.os.Vibrator for interacting with the vibration hardware.
|
String |
VIRTUAL_DEVICE_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.companion.virtual.VirtualDeviceManager for managing virtual devices. On devices without PackageManager#FEATURE_COMPANION_DEVICE_SETUP system feature the getSystemService(java.lang.String) will return null .
|
String |
VPN_MANAGEMENT_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.net.VpnManager to manage profiles for the platform built-in VPN.
|
String |
WALLPAPER_SERVICE
Use with getSystemService(java.lang.String) to retrieve a com.android.server.WallpaperService for accessing wallpapers.
|
String |
WIFI_AWARE_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.net.wifi.aware.WifiAwareManager for handling management of Wi-Fi Aware.
|
String |
WIFI_P2P_SERVICE
Use with getSystemService(java.lang.String) to retrieve a for handling management of Wi-Fi peer-to-peer connections.
|
String |
WIFI_RTT_RANGING_SERVICE
Use with getSystemService(java.lang.String) to retrieve a for ranging devices with wifi.
|
String |
WIFI_SERVICE
Use with getSystemService(java.lang.String) to retrieve a for handling management of Wi-Fi access.
|
String |
WINDOW_SERVICE
Use with getSystemService(java.lang.String) to retrieve a android.view.WindowManager for accessing the system's window manager.
|
|
From class Service
Int |
START_CONTINUATION_MASK
Bits returned by onStartCommand describing how to continue the service if it is killed. May be START_STICKY , START_NOT_STICKY , START_REDELIVER_INTENT , or START_STICKY_COMPATIBILITY .
|
Int |
START_FLAG_REDELIVERY
This flag is set in onStartCommand if the Intent is a re-delivery of a previously delivered intent, because the service had previously returned START_REDELIVER_INTENT but had been killed before calling stopSelf(int) for that Intent.
|
Int |
START_FLAG_RETRY
This flag is set in onStartCommand if the Intent is a retry because the original attempt never got to or returned from onStartCommand(android.content.Intent,int,int) .
|
Int |
START_NOT_STICKY
Constant to return from onStartCommand : if this service's process is killed while it is started (after returning from onStartCommand ), and there are no new start intents to deliver to it, then take the service out of the started state and don't recreate until a future explicit call to Context.startService(Intent) . The service will not receive a onStartCommand(android.content.Intent,int,int) call with a null Intent because it will not be restarted if there are no pending Intents to deliver.
This mode makes sense for things that want to do some work as a result of being started, but can be stopped when under memory pressure and will explicit start themselves again later to do more work. An example of such a service would be one that polls for data from a server: it could schedule an alarm to poll every N minutes by having the alarm start its service. When its onStartCommand is called from the alarm, it schedules a new alarm for N minutes later, and spawns a thread to do its networking. If its process is killed while doing that check, the service will not be restarted until the alarm goes off.
|
Int |
START_REDELIVER_INTENT
Constant to return from onStartCommand : if this service's process is killed while it is started (after returning from onStartCommand ), then it will be scheduled for a restart and the last delivered Intent re-delivered to it again via onStartCommand . This Intent will remain scheduled for redelivery until the service calls stopSelf(int) with the start ID provided to onStartCommand . The service will not receive a onStartCommand(android.content.Intent,int,int) call with a null Intent because it will only be restarted if it is not finished processing all Intents sent to it (and any such pending events will be delivered at the point of restart).
|
Int |
START_STICKY
Constant to return from onStartCommand : if this service's process is killed while it is started (after returning from onStartCommand ), then leave it in the started state but don't retain this delivered intent. Later the system will try to re-create the service. Because it is in the started state, it will guarantee to call onStartCommand after creating the new service instance; if there are not any pending start commands to be delivered to the service, it will be called with a null intent object, so you must take care to check for this.
This mode makes sense for things that will be explicitly started and stopped to run for arbitrary periods of time, such as a service performing background music playback.
Since Android version Build.VERSION_CODES#S , apps targeting Build.VERSION_CODES#S or above are disallowed to start a foreground service from the background, but the restriction doesn't impact restarts of a sticky foreground service. However, when apps start a sticky foreground service from the background, the same restriction still applies.
|
Int |
START_STICKY_COMPATIBILITY
Constant to return from onStartCommand : compatibility version of START_STICKY that does not guarantee that onStartCommand will be called again after being killed.
|
Int |
STOP_FOREGROUND_DETACH
Selector for stopForeground(int) : if set, the notification previously supplied to #startForeground will be detached from the service's lifecycle. The notification will remain shown even after the service is stopped and destroyed.
|
Int |
STOP_FOREGROUND_LEGACY
Selector for stopForeground(int) : equivalent to passing false to the legacy API stopForeground(boolean) .
|
Int |
STOP_FOREGROUND_REMOVE
Selector for stopForeground(int) : if supplied, the notification previously supplied to #startForeground will be cancelled and removed from display.
|
|
From class ComponentCallbacks2
Int |
TRIM_MEMORY_BACKGROUND
Level for onTrimMemory(int) : the process has gone on to the LRU list. This is a good opportunity to clean up resources that can efficiently and quickly be re-built if the user returns to the app.
|
Int |
TRIM_MEMORY_COMPLETE
Level for onTrimMemory(int) : the process is nearing the end of the background LRU list, and if more memory isn't found soon it will be killed.
|
Int |
TRIM_MEMORY_MODERATE
Level for onTrimMemory(int) : the process is around the middle of the background LRU list; freeing memory can help the system keep other processes running later in the list for better overall performance.
|
Int |
TRIM_MEMORY_RUNNING_CRITICAL
Level for onTrimMemory(int) : the process is not an expendable background process, but the device is running extremely low on memory and is about to not be able to keep any background processes running. Your running process should free up as many non-critical resources as it can to allow that memory to be used elsewhere. The next thing that will happen after this is onLowMemory() called to report that nothing at all can be kept in the background, a situation that can start to notably impact the user.
|
Int |
TRIM_MEMORY_RUNNING_LOW
Level for onTrimMemory(int) : the process is not an expendable background process, but the device is running low on memory. Your running process should free up unneeded resources to allow that memory to be used elsewhere.
|
Int |
TRIM_MEMORY_RUNNING_MODERATE
Level for onTrimMemory(int) : the process is not an expendable background process, but the device is running moderately low on memory. Your running process may want to release some unneeded resources for use elsewhere.
|
Int |
TRIM_MEMORY_UI_HIDDEN
Level for onTrimMemory(int) : the process had been showing a user interface, and is no longer doing so. Large allocations with the UI should be released at this point to allow memory to be better managed.
|
|
Public methods |
FillEventHistory? |
Gets the events that happened after the last AutofillService#onFillRequest(FillRequest, android.os.CancellationSignal, FillCallback) call.
|
IBinder? |
|
open Unit |
Called when the Android system connects to service.
|
open Unit |
Called by the system when the service is first created.
|
open Unit |
Called when the Android system disconnects from the service.
|
abstract Unit |
Called by the Android system do decide if a screen can be autofilled by the service.
|
abstract Unit |
Called when the user requests the service to save the contents of a screen.
|
open Unit |
Called from system settings to display information about the datasets the user saved to this service.
|
Inherited functions |
From class Service
Unit |
attachBaseContext(newBase: Context!)
|
Unit |
dump(fd: FileDescriptor!, writer: PrintWriter!, args: Array<String!>!)
Print the Service's state into the given stream. This gets invoked if you run "adb shell dumpsys activity service <yourservicename>" (note that for this command to work, the service must be running, and you must specify a fully-qualified service name). This is distinct from "dumpsys <servicename>", which only works for named system services and which invokes the IBinder#dump method on the IBinder interface registered with ServiceManager.
|
Application! |
getApplication()
Return the application that owns this service.
|
Int |
getForegroundServiceType()
If the service has become a foreground service by calling startForeground(int,android.app.Notification) or startForeground(int,android.app.Notification,int) , getForegroundServiceType() returns the current foreground service type.
If there is no foregroundServiceType specified in manifest, ServiceInfo#FOREGROUND_SERVICE_TYPE_NONE is returned.
If the service is not a foreground service, ServiceInfo#FOREGROUND_SERVICE_TYPE_NONE is returned.
|
Unit |
onConfigurationChanged(newConfig: Configuration)
|
Unit |
onDestroy()
Called by the system to notify a Service that it is no longer used and is being removed. The service should clean up any resources it holds (threads, registered receivers, etc) at this point. Upon return, there will be no more calls in to this Service object and it is effectively dead. Do not call this method directly.
|
Unit |
onLowMemory()
|
Unit |
onRebind(intent: Intent!)
Called when new clients have connected to the service, after it had previously been notified that all had disconnected in its onUnbind . This will only be called if the implementation of onUnbind was overridden to return true.
|
Unit |
onStart(intent: Intent!, startId: Int)
|
Int |
onStartCommand(intent: Intent!, flags: Int, startId: Int)
Called by the system every time a client explicitly starts the service by calling android.content.Context#startService , providing the arguments it supplied and a unique integer token representing the start request. Do not call this method directly.
For backwards compatibility, the default implementation calls onStart and returns either START_STICKY or START_STICKY_COMPATIBILITY .
Note that the system calls this on your service's main thread. A service's main thread is the same thread where UI operations take place for Activities running in the same process. You should always avoid stalling the main thread's event loop. When doing long-running operations, network calls, or heavy disk I/O, you should kick off a new thread, or use android.os.AsyncTask .
|
Unit |
onTaskRemoved(rootIntent: Intent!)
This is called if the service is currently running and the user has removed a task that comes from the service's application. If you have set ServiceInfo.FLAG_STOP_WITH_TASK then you will not receive this callback; instead, the service will simply be stopped.
|
Unit |
onTimeout(startId: Int)
Callback called on timeout for ServiceInfo#FOREGROUND_SERVICE_TYPE_SHORT_SERVICE . See ServiceInfo#FOREGROUND_SERVICE_TYPE_SHORT_SERVICE for more details.
If the foreground service of type ServiceInfo#FOREGROUND_SERVICE_TYPE_SHORT_SERVICE doesn't finish even after it's timed out, the app will be declared an ANR after a short grace period of several seconds.
Starting from Android version android.os.Build.VERSION_CODES#VANILLA_ICE_CREAM , onTimeout(int,int) will also be called when a foreground service of type ServiceInfo#FOREGROUND_SERVICE_TYPE_SHORT_SERVICE times out. Developers do not need to implement both of the callbacks on android.os.Build.VERSION_CODES#VANILLA_ICE_CREAM and onwards.
Note, even though ServiceInfo#FOREGROUND_SERVICE_TYPE_SHORT_SERVICE was added on Android version android.os.Build.VERSION_CODES#UPSIDE_DOWN_CAKE , it can be also used on on prior android versions (just like other new foreground service types can be used). However, because android.app.Service#onTimeout(int) did not exist on prior versions, it will never called on such versions. Because of this, developers must make sure to stop the foreground service even if android.app.Service#onTimeout(int) is not called on such versions.
|
Unit |
onTimeout(startId: Int, fgsType: Int)
Callback called when a particular foreground service type has timed out.
This callback is meant to give the app a small grace period of a few seconds to finish the foreground service of the associated type - if it fails to do so, the app will crash.
The foreground service of the associated type can be stopped within the time limit by android.app.Service#stopSelf() , android.content.Context#stopService(android.content.Intent) or their overloads. android.app.Service#stopForeground(int) can be used as well, which demotes the service to a "background" service, which will soon be stopped by the system.
The specific time limit for each type (if one exists) is mentioned in the documentation for that foreground service type. See dataSync for example.
Note: time limits are restricted to a rolling 24-hour window - for example, if a foreground service type has a time limit of 6 hours, that time counter begins as soon as the foreground service starts. This time limit will only be reset once every 24 hours or if the app comes into the foreground state.
|
Unit |
onTrimMemory(level: Int)
|
Boolean |
onUnbind(intent: Intent!)
Called when all clients have disconnected from a particular interface published by the service. The default implementation does nothing and returns false.
|
Unit |
startForeground(id: Int, notification: Notification!)
If your service is started (running through Context#startService(Intent) ), then also make this service run in the foreground, supplying the ongoing notification to be shown to the user while in this state. By default started services are background, meaning that their process won't be given foreground CPU scheduling (unless something else in that process is foreground) and, if the system needs to kill them to reclaim more memory (such as to display a large page in a web browser), they can be killed without too much harm. You use #startForeground if killing your service would be disruptive to the user, such as if your service is performing background music playback, so the user would notice if their music stopped playing.
Note that calling this method does not put the service in the started state itself, even though the name sounds like it. You must always call startService(android.content.Intent) first to tell the system it should keep the service running, and then use this method to tell it to keep it running harder.
Apps targeting API android.os.Build.VERSION_CODES#P or later must request the permission android.Manifest.permission#FOREGROUND_SERVICE in order to use this API.
Apps built with SDK version android.os.Build.VERSION_CODES#Q or later can specify the foreground service types using attribute android.R.attr#foregroundServiceType in service element of manifest file. The value of attribute android.R.attr#foregroundServiceType can be multiple flags ORed together.
Note: Beginning with SDK Version android.os.Build.VERSION_CODES#S , apps targeting SDK Version android.os.Build.VERSION_CODES#S or higher are not allowed to start foreground services from the background. See Behavior changes: Apps targeting Android 12 for more details.
Note: Beginning with SDK Version android.os.Build.VERSION_CODES#UPSIDE_DOWN_CAKE , apps targeting SDK Version android.os.Build.VERSION_CODES#UPSIDE_DOWN_CAKE or higher are not allowed to start foreground services without specifying a valid foreground service type in the manifest attribute android.R.attr#foregroundServiceType . See Behavior changes: Apps targeting Android 14 for more details.
|
Unit |
startForeground(id: Int, notification: Notification, foregroundServiceType: Int)
An overloaded version of startForeground(int,android.app.Notification) with additional foregroundServiceType parameter.
Apps built with SDK version android.os.Build.VERSION_CODES#Q or later can specify the foreground service types using attribute android.R.attr#foregroundServiceType in service element of manifest file. The value of attribute android.R.attr#foregroundServiceType can be multiple flags ORed together.
The foregroundServiceType parameter must be a subset flags of what is specified in manifest attribute android.R.attr#foregroundServiceType , if not, an IllegalArgumentException is thrown. Specify foregroundServiceType parameter as android.content.pm.ServiceInfo#FOREGROUND_SERVICE_TYPE_MANIFEST to use all flags that is specified in manifest attribute foregroundServiceType.
Note: Beginning with SDK Version android.os.Build.VERSION_CODES#S , apps targeting SDK Version android.os.Build.VERSION_CODES#S or higher are not allowed to start foreground services from the background. See Behavior changes: Apps targeting Android 12 for more details.
Note: Beginning with SDK Version android.os.Build.VERSION_CODES#UPSIDE_DOWN_CAKE , apps targeting SDK Version android.os.Build.VERSION_CODES#UPSIDE_DOWN_CAKE or higher are not allowed to start foreground services without specifying a valid foreground service type in the manifest attribute android.R.attr#foregroundServiceType , and the parameter foregroundServiceType here must not be the ServiceInfo#FOREGROUND_SERVICE_TYPE_NONE . See Behavior changes: Apps targeting Android 14 for more details.
|
Unit |
stopForeground(removeNotification: Boolean)
Legacy version of stopForeground(int) .
|
Unit |
stopForeground(notificationBehavior: Int)
Remove this service from foreground state, allowing it to be killed if more memory is needed. This does not stop the service from running (for that you use stopSelf() or related methods), just takes it out of the foreground state.
If STOP_FOREGROUND_REMOVE is supplied, the service's associated notification will be cancelled immediately.
If STOP_FOREGROUND_DETACH is supplied, the service's association with the notification will be severed. If the notification had not yet been shown, due to foreground-service notification deferral policy, it is immediately posted when stopForeground(STOP_FOREGROUND_DETACH) is called. In all cases, the notification remains shown even after this service is stopped fully and destroyed.
If zero is passed as the argument, the result will be the legacy behavior as defined prior to Android L: the notification will remain posted until the service is fully stopped, at which time it will automatically be cancelled.
|
Unit |
stopSelf()
Stop the service, if it was previously started. This is the same as calling android.content.Context#stopService for this particular service.
|
Unit |
stopSelf(startId: Int)
Old version of stopSelfResult that doesn't return a result.
|
Boolean |
stopSelfResult(startId: Int)
Stop the service if the most recent time it was started was startId. This is the same as calling android.content.Context#stopService for this particular service but allows you to safely avoid stopping if there is a start request from a client that you haven't yet seen in onStart .
Be careful about ordering of your calls to this function.. If you call this function with the most-recently received ID before you have called it for previously received IDs, the service will be immediately stopped anyway. If you may end up processing IDs out of order (such as by dispatching them on separate threads), then you are responsible for stopping them in the same order you received them.
|
|
From class ContextWrapper
Boolean |
bindIsolatedService(service: Intent, flags: Int, instanceName: String, executor: Executor, conn: ServiceConnection)
|
Boolean |
bindService(service: Intent, conn: ServiceConnection, flags: Int)
|
Boolean |
bindService(service: Intent, conn: ServiceConnection, flags: Context.BindServiceFlags)
See bindService(android.content.Intent,android.content.ServiceConnection,int) Call BindServiceFlags#of(long) to obtain a BindServiceFlags object.
|
Boolean |
bindService(service: Intent, flags: Int, executor: Executor, conn: ServiceConnection)
|
Boolean |
bindService(service: Intent, flags: Context.BindServiceFlags, executor: Executor, conn: ServiceConnection)
See bindService(android.content.Intent,int,java.util.concurrent.Executor,android.content.ServiceConnection) Call BindServiceFlags#of(long) to obtain a BindServiceFlags object.
|
Int |
checkCallingOrSelfPermission(permission: String)
|
Int |
checkCallingOrSelfUriPermission(uri: Uri!, modeFlags: Int)
|
IntArray |
checkCallingOrSelfUriPermissions(uris: MutableList<Uri!>, modeFlags: Int)
Determine whether the calling process of an IPC or you has been granted permission to access a list of URIs. This is the same as checkCallingUriPermission , except it grants your own permissions if you are not currently processing an IPC. Use with care!
|
Int |
checkCallingPermission(permission: String)
|
Int |
checkCallingUriPermission(uri: Uri!, modeFlags: Int)
|
IntArray |
checkCallingUriPermissions(uris: MutableList<Uri!>, modeFlags: Int)
Determine whether the calling process and uid has been granted permission to access a list of URIs. This is basically the same as calling checkUriPermissions(java.util.List,int,int,int) with the pid and uid returned by android.os.Binder#getCallingPid and android.os.Binder#getCallingUid . One important difference is that if you are not currently processing an IPC, this function will always fail.
|
Int |
checkContentUriPermissionFull(uri: Uri, pid: Int, uid: Int, modeFlags: Int)
Determine whether a particular process and uid has been granted permission to access a specific content URI.
Unlike checkUriPermission(android.net.Uri,int,int,int) , this method checks for general access to the URI's content provider, as well as explicitly granted permissions.
Note, this check will throw an IllegalArgumentException for non-content URIs.
|
Int |
checkPermission(permission: String, pid: Int, uid: Int)
|
Int |
checkSelfPermission(permission: String)
|
Int |
checkUriPermission(uri: Uri!, pid: Int, uid: Int, modeFlags: Int)
|
Int |
checkUriPermission(uri: Uri?, readPermission: String?, writePermission: String?, pid: Int, uid: Int, modeFlags: Int)
Check both a Uri and normal permission. This allows you to perform both checkPermission and #checkUriPermission in one call.
|
IntArray |
checkUriPermissions(uris: MutableList<Uri!>, pid: Int, uid: Int, modeFlags: Int)
Determine whether a particular process and uid has been granted permission to access a list of URIs. This only checks for permissions that have been explicitly granted -- if the given process/uid has more general access to the URI's content provider then this check will always fail. Note: On SDK Version android.os.Build.VERSION_CODES#S , calling this method from a secondary-user's context will incorrectly return PackageManager#PERMISSION_DENIED for all {code uris}.
|
Unit |
clearWallpaper()
|
Context |
createAttributionContext(attributionTag: String?)
Return a new Context object for the current Context but attribute to a different tag. In complex apps attribution tagging can be used to distinguish between separate logical parts.
|
Context! |
createConfigurationContext(overrideConfiguration: Configuration)
|
Context |
createContext(contextParams: ContextParams)
Creates a context with specific properties and behaviors.
|
Context |
createDeviceContext(deviceId: Int)
Returns a new Context object from the current context but with device association given by the deviceId . Each call to this method returns a new instance of a context object. Context objects are not shared; however, common state (such as the ClassLoader and other resources for the same configuration) can be shared, so the Context itself is lightweight.
Applications that run on virtual devices may use this method to access the default device capabilities and functionality (by passing Context#DEVICE_ID_DEFAULT . Similarly, applications running on the default device may access the functionality of virtual devices.
Note that the newly created instance will be associated with the same display as the parent Context, regardless of the device ID passed here.
|
Context! |
createDeviceProtectedStorageContext()
|
Context! |
createDisplayContext(display: Display)
|
Context! |
createPackageContext(packageName: String!, flags: Int)
|
Context |
createWindowContext(type: Int, options: Bundle?)
Creates a Context for a non-activity window.
A window context is a context that can be used to add non-activity windows, such as android.view.WindowManager.LayoutParams#TYPE_APPLICATION_OVERLAY . A window context must be created from a context that has an associated Display , such as Activity or a context created with createDisplayContext(android.view.Display) .
The window context is created with the appropriate Configuration for the area of the display that the windows created with it can occupy; it must be used when inflating views, such that they can be inflated with proper Resources . Below is a sample code to add an application overlay window on the primary display:
...
final DisplayManager dm = anyContext.getSystemService(DisplayManager.class);
final Display primaryDisplay = dm.getDisplay(DEFAULT_DISPLAY);
final Context windowContext = anyContext.createDisplayContext(primaryDisplay)
.createWindowContext(TYPE_APPLICATION_OVERLAY, null);
final View overlayView = Inflater.from(windowContext).inflate(someLayoutXml, null);
// WindowManager.LayoutParams initialization
...
// The types used in addView and createWindowContext must match.
mParams.type = TYPE_APPLICATION_OVERLAY;
...
windowContext.getSystemService(WindowManager.class).addView(overlayView, mParams);
This context's configuration and resources are adjusted to an area of the display where the windows with provided type will be added. Note that all windows associated with the same context will have an affinity and can only be moved together between different displays or areas on a display. If there is a need to add different window types, or non-associated windows, separate Contexts should be used.
Creating a window context is an expensive operation. Misuse of this API may lead to a huge performance drop. The best practice is to use the same window context when possible. An approach is to create one window context with specific window type and display and use it everywhere it's needed.
After Build.VERSION_CODES#S , window context provides the capability to receive configuration changes for existing token by overriding the token of the android.view.WindowManager.LayoutParams passed in WindowManager#addView(View, LayoutParams) . This is useful when an application needs to attach its window to an existing activity for window token sharing use-case.
Note that the window context in Build.VERSION_CODES#R didn't have this capability. This is a no-op for the window context in Build.VERSION_CODES#R .
Below is sample code to attach an existing token to a window context:
final DisplayManager dm = anyContext.getSystemService(DisplayManager.class);
final Display primaryDisplay = dm.getDisplay(DEFAULT_DISPLAY);
final Context windowContext = anyContext.createWindowContext(primaryDisplay,
TYPE_APPLICATION, null);
// Get an existing token.
final IBinder existingToken = activity.getWindow().getAttributes().token;
// The types used in addView() and createWindowContext() must match.
final WindowManager.LayoutParams params = new WindowManager.LayoutParams(TYPE_APPLICATION);
params.token = existingToken;
// After WindowManager#addView(), the server side will extract the provided token from
// LayoutParams#token (existingToken in the sample code), and switch to propagate
// configuration changes from the node associated with the provided token.
windowContext.getSystemService(WindowManager.class).addView(overlayView, mParams);
After Build.VERSION_CODES#S , window context provides the capability to listen to its Configuration changes by calling registerComponentCallbacks(android.content.ComponentCallbacks) , while other kinds of Context will register the ComponentCallbacks to its . Note that window context only propagate ComponentCallbacks#onConfigurationChanged(Configuration) callback. ComponentCallbacks#onLowMemory() or other callbacks in ComponentCallbacks2 won't be invoked.
Note that using android.app.Application or android.app.Service context for UI-related queries may result in layout or continuity issues on devices with variable screen sizes (e.g. foldables) or in multi-window modes, since these non-UI contexts may not reflect the Configuration changes for the visual container.
|
Context |
createWindowContext(display: Display, type: Int, options: Bundle?)
Creates a Context for a non-activity window on the given Display .
Similar to createWindowContext(int,android.os.Bundle) , but the display is passed in, instead of implicitly using the original Context's Display .
|
Array<String!>! |
databaseList()
|
Boolean |
deleteDatabase(name: String!)
|
Boolean |
deleteFile(name: String!)
|
Boolean |
deleteSharedPreferences(name: String!)
|
Unit |
enforceCallingOrSelfPermission(permission: String, message: String?)
If neither you nor the calling process of an IPC you are handling has been granted a particular permission, throw a SecurityException . This is the same as enforceCallingPermission , except it grants your own permissions if you are not currently processing an IPC. Use with care!
|
Unit |
enforceCallingOrSelfUriPermission(uri: Uri!, modeFlags: Int, message: String!)
|
Unit |
enforceCallingPermission(permission: String, message: String?)
If the calling process of an IPC you are handling has not been granted a particular permission, throw a SecurityException . This is basically the same as calling enforcePermission(java.lang.String,int,int,java.lang.String) with the pid and uid returned by android.os.Binder#getCallingPid and android.os.Binder#getCallingUid . One important difference is that if you are not currently processing an IPC, this function will always throw the SecurityException. This is done to protect against accidentally leaking permissions; you can use enforceCallingOrSelfPermission to avoid this protection.
|
Unit |
enforceCallingUriPermission(uri: Uri!, modeFlags: Int, message: String!)
|
Unit |
enforcePermission(permission: String, pid: Int, uid: Int, message: String?)
If the given permission is not allowed for a particular process and user ID running in the system, throw a SecurityException .
|
Unit |
enforceUriPermission(uri: Uri!, pid: Int, uid: Int, modeFlags: Int, message: String!)
|
Unit |
enforceUriPermission(uri: Uri?, readPermission: String?, writePermission: String?, pid: Int, uid: Int, modeFlags: Int, message: String?)
Enforce both a Uri and normal permission. This allows you to perform both enforcePermission and #enforceUriPermission in one call.
|
Array<String!>! |
fileList()
|
Context! |
getApplicationContext()
|
ApplicationInfo! |
getApplicationInfo()
|
AssetManager! |
getAssets()
|
AttributionSource |
getAttributionSource()
|
Context! |
getBaseContext()
|
File! |
getCacheDir()
|
ClassLoader! |
getClassLoader()
|
File! |
getCodeCacheDir()
|
ContentResolver! |
getContentResolver()
|
File! |
getDataDir()
|
File! |
getDatabasePath(name: String!)
|
Int |
getDeviceId()
|
File! |
getDir(name: String!, mode: Int)
|
Display! |
getDisplay()
Get the display this context is associated with. Applications should use this method with android.app.Activity or a context associated with a Display via createDisplayContext(android.view.Display) to get a display object associated with a Context, or android.hardware.display.DisplayManager#getDisplay to get a display object by id.
|
File? |
getExternalCacheDir()
Returns absolute path to application-specific directory on the primary shared/external storage device where the application can place cache files it owns. These files are internal to the application, and not typically visible to the user as media.
This is like getCacheDir() in that these files will be deleted when the application is uninstalled, however there are some important differences:
If a shared storage device is emulated (as determined by Environment#isExternalStorageEmulated(File) ), its contents are backed by a private user data partition, which means there is little benefit to storing data here instead of the private directory returned by getCacheDir() .
Starting in android.os.Build.VERSION_CODES#KITKAT , no permissions are required to read or write to the returned path; it's always accessible to the calling app. This only applies to paths generated for package name of the calling application. To access paths belonging to other packages, android.Manifest.permission#WRITE_EXTERNAL_STORAGE and/or android.Manifest.permission#READ_EXTERNAL_STORAGE are required.
On devices with multiple users (as described by UserManager ), each user has their own isolated shared storage. Applications only have access to the shared storage for the user they're running as.
The returned path may change over time if different shared storage media is inserted, so only relative paths should be persisted.
|
Array<File!>! |
getExternalCacheDirs()
|
File? |
getExternalFilesDir(type: String?)
Returns the absolute path to the directory on the primary shared/external storage device where the application can place persistent files it owns. These files are internal to the applications, and not typically visible to the user as media.
This is like getFilesDir() in that these files will be deleted when the application is uninstalled, however there are some important differences:
If a shared storage device is emulated (as determined by Environment#isExternalStorageEmulated(File) ), its contents are backed by a private user data partition, which means there is little benefit to storing data here instead of the private directories returned by getFilesDir() , etc.
Starting in android.os.Build.VERSION_CODES#KITKAT , no permissions are required to read or write to the returned path; it's always accessible to the calling app. This only applies to paths generated for package name of the calling application. To access paths belonging to other packages, android.Manifest.permission#WRITE_EXTERNAL_STORAGE and/or android.Manifest.permission#READ_EXTERNAL_STORAGE are required.
On devices with multiple users (as described by UserManager ), each user has their own isolated shared storage. Applications only have access to the shared storage for the user they're running as.
The returned path may change over time if different shared storage media is inserted, so only relative paths should be persisted.
Here is an example of typical code to manipulate a file in an application's shared storage:
If you supply a non-null type to this function, the returned file will be a path to a sub-directory of the given type. Though these files are not automatically scanned by the media scanner, you can explicitly add them to the media database with MediaScannerConnection.scanFile . Note that this is not the same as Environment.getExternalStoragePublicDirectory() , which provides directories of media shared by all applications. The directories returned here are owned by the application, and their contents will be removed when the application is uninstalled. Unlike Environment.getExternalStoragePublicDirectory() , the directory returned here will be automatically created for you.
Here is an example of typical code to manipulate a picture in an application's shared storage and add it to the media database:
|
Array<File!>! |
getExternalFilesDirs(type: String!)
|
Array<File!>! |
getExternalMediaDirs()
|
File! |
getFileStreamPath(name: String!)
|
File! |
getFilesDir()
|
Executor! |
getMainExecutor()
|
Looper! |
getMainLooper()
|
File! |
getNoBackupFilesDir()
|
File! |
getObbDir()
|
Array<File!>! |
getObbDirs()
|
String! |
getPackageCodePath()
|
PackageManager! |
getPackageManager()
|
String! |
getPackageName()
|
String! |
getPackageResourcePath()
|
ContextParams? |
getParams()
Return the set of parameters which this Context was created with, if it was created via createContext(android.content.ContextParams) .
|
Resources! |
getResources()
|
SharedPreferences! |
getSharedPreferences(name: String!, mode: Int)
|
Any! |
getSystemService(name: String)
|
String? |
getSystemServiceName(serviceClass: Class<*>)
|
Resources.Theme! |
getTheme()
|
Drawable! |
getWallpaper()
|
Int |
getWallpaperDesiredMinimumHeight()
|
Int |
getWallpaperDesiredMinimumWidth()
|
Unit |
grantUriPermission(toPackage: String!, uri: Uri!, modeFlags: Int)
|
Boolean |
isDeviceProtectedStorage()
|
Boolean |
isRestricted()
|
Boolean |
moveDatabaseFrom(sourceContext: Context!, name: String!)
|
Boolean |
moveSharedPreferencesFrom(sourceContext: Context!, name: String!)
|
FileInputStream! |
openFileInput(name: String!)
|
FileOutputStream! |
openFileOutput(name: String!, mode: Int)
|
SQLiteDatabase! |
openOrCreateDatabase(name: String!, mode: Int, factory: SQLiteDatabase.CursorFactory!)
|
SQLiteDatabase! |
openOrCreateDatabase(name: String!, mode: Int, factory: SQLiteDatabase.CursorFactory!, errorHandler: DatabaseErrorHandler?)
Open a new private SQLiteDatabase associated with this Context's application package. Creates the database file if it doesn't exist.
Accepts input param: a concrete instance of DatabaseErrorHandler to be used to handle corruption when sqlite reports database corruption.
|
Drawable! |
peekWallpaper()
|
Unit |
registerComponentCallbacks(callback: ComponentCallbacks!)
Add a new ComponentCallbacks to the base application of the Context, which will be called at the same times as the ComponentCallbacks methods of activities and other components are called. Note that you must be sure to use unregisterComponentCallbacks when appropriate in the future; this will not be removed for you.
After Build.VERSION_CODES#TIRAMISU , the ComponentCallbacks will be registered to the base Context , and can be only used after attachBaseContext(android.content.Context) . Users can still call to getApplicationContext().registerComponentCallbacks(ComponentCallbacks) to add ComponentCallbacks to the base application.
|
Unit |
registerDeviceIdChangeListener(executor: Executor, listener: IntConsumer)
Adds a new device ID changed listener to the Context , which will be called when the device association is changed by the system.
The callback can be called when an app is moved to a different device and the Context is not explicitly associated with a specific device.
When an application receives a device id update callback, this Context is guaranteed to also have an updated display ID(if any) and Configuration .
|
Intent? |
registerReceiver(receiver: BroadcastReceiver?, filter: IntentFilter!)
Register a BroadcastReceiver to be run in the main activity thread. The receiver will be called with any broadcast Intent that matches filter, in the main application thread.
The system may broadcast Intents that are "sticky" -- these stay around after the broadcast has finished, to be sent to any later registrations. If your IntentFilter matches one of these sticky Intents, that Intent will be returned by this function and sent to your receiver as if it had just been broadcast.
There may be multiple sticky Intents that match filter, in which case each of these will be sent to receiver. In this case, only one of these can be returned directly by the function; which of these that is returned is arbitrarily decided by the system.
If you know the Intent your are registering for is sticky, you can supply null for your receiver. In this case, no receiver is registered -- the function simply returns the sticky Intent that matches filter. In the case of multiple matches, the same rules as described above apply.
See BroadcastReceiver for more information on Intent broadcasts.
As of android.os.Build.VERSION_CODES#UPSIDE_DOWN_CAKE , the system can place context-registered broadcasts in a queue while the app is in the cached state. When the app leaves the cached state, such as returning to the foreground, the system delivers any queued broadcasts. Multiple instances of certain broadcasts might be merged into one broadcast.
As of android.os.Build.VERSION_CODES#ICE_CREAM_SANDWICH , receivers registered with this method will correctly respect the Intent#setPackage(String) specified for an Intent being broadcast. Prior to that, it would be ignored and delivered to all matching registered receivers. Be careful if using this for security.
For apps targeting android.os.Build.VERSION_CODES#UPSIDE_DOWN_CAKE , either RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED must be specified if the receiver is not being registered for system broadcasts or a SecurityException will be thrown. See registerReceiver(android.content.BroadcastReceiver,android.content.IntentFilter,int) to register a receiver with flags.
Note: this method cannot be called from a BroadcastReceiver component; that is, from a BroadcastReceiver that is declared in an application's manifest. It is okay, however, to call this method from another BroadcastReceiver that has itself been registered at run time with #registerReceiver, since the lifetime of such a registered BroadcastReceiver is tied to the object that registered it.
|
Intent? |
registerReceiver(receiver: BroadcastReceiver?, filter: IntentFilter!, flags: Int)
Register to receive intent broadcasts, with the receiver optionally being exposed to Instant Apps. See registerReceiver(android.content.BroadcastReceiver,android.content.IntentFilter) for more information. By default Instant Apps cannot interact with receivers in other applications, this allows you to expose a receiver that Instant Apps can interact with.
See BroadcastReceiver for more information on Intent broadcasts.
As of android.os.Build.VERSION_CODES#UPSIDE_DOWN_CAKE , the system can place context-registered broadcasts in a queue while the app is in the cached state. When the app leaves the cached state, such as returning to the foreground, the system delivers any queued broadcasts. Multiple instances of certain broadcasts might be merged into one broadcast.
As of android.os.Build.VERSION_CODES#ICE_CREAM_SANDWICH , receivers registered with this method will correctly respect the Intent#setPackage(String) specified for an Intent being broadcast. Prior to that, it would be ignored and delivered to all matching registered receivers. Be careful if using this for security.
|
Intent? |
registerReceiver(receiver: BroadcastReceiver?, filter: IntentFilter!, broadcastPermission: String?, scheduler: Handler?)
Register to receive intent broadcasts, to run in the context of scheduler. See registerReceiver(android.content.BroadcastReceiver,android.content.IntentFilter) for more information. This allows you to enforce permissions on who can broadcast intents to your receiver, or have the receiver run in a different thread than the main application thread.
See BroadcastReceiver for more information on Intent broadcasts.
As of android.os.Build.VERSION_CODES#UPSIDE_DOWN_CAKE , the system can place context-registered broadcasts in a queue while the app is in the cached state. When the app leaves the cached state, such as returning to the foreground, the system delivers any queued broadcasts. Multiple instances of certain broadcasts might be merged into one broadcast.
As of android.os.Build.VERSION_CODES#ICE_CREAM_SANDWICH , receivers registered with this method will correctly respect the Intent#setPackage(String) specified for an Intent being broadcast. Prior to that, it would be ignored and delivered to all matching registered receivers. Be careful if using this for security.
For apps targeting android.os.Build.VERSION_CODES#UPSIDE_DOWN_CAKE , either RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED must be specified if the receiver is not being registered for system broadcasts or a SecurityException will be thrown. See registerReceiver(android.content.BroadcastReceiver,android.content.IntentFilter,java.lang.String,android.os.Handler,int) to register a receiver with flags.
|
Intent? |
registerReceiver(receiver: BroadcastReceiver?, filter: IntentFilter!, broadcastPermission: String?, scheduler: Handler?, flags: Int)
Register to receive intent broadcasts, to run in the context of scheduler. See registerReceiver(android.content.BroadcastReceiver,android.content.IntentFilter,int) and registerReceiver(android.content.BroadcastReceiver,android.content.IntentFilter,java.lang.String,android.os.Handler) for more information.
See BroadcastReceiver for more information on Intent broadcasts.
As of android.os.Build.VERSION_CODES#UPSIDE_DOWN_CAKE , the system can place context-registered broadcasts in a queue while the app is in the cached state. When the app leaves the cached state, such as returning to the foreground, the system delivers any queued broadcasts. Multiple instances of certain broadcasts might be merged into one broadcast.
As of android.os.Build.VERSION_CODES#ICE_CREAM_SANDWICH , receivers registered with this method will correctly respect the Intent#setPackage(String) specified for an Intent being broadcast. Prior to that, it would be ignored and delivered to all matching registered receivers. Be careful if using this for security.
|
Unit |
removeStickyBroadcast(intent: Intent!)
|
Unit |
removeStickyBroadcastAsUser(intent: Intent!, user: UserHandle!)
|
Unit |
revokeSelfPermissionsOnKill(permissions: MutableCollection<String!>)
Triggers the revocation of one or more permissions for the calling package. A package is only able to revoke runtime permissions. If a permission is not currently granted, it is ignored and will not get revoked (even if later granted by the user). Ultimately, you should never make assumptions about a permission status as users may grant or revoke them at any time.
Background permissions which have no corresponding foreground permission still granted once the revocation is effective will also be revoked.
The revocation happens asynchronously and kills all processes running in the calling UID. It will be triggered once it is safe to do so. In particular, it will not be triggered as long as the package remains in the foreground, or has any active manifest components (e.g. when another app is accessing a content provider in the package).
If you want to revoke the permissions right away, you could call System.exit() in Handler.postDelayed with a delay to allow completion of async IPC, But System.exit() could affect other apps that are accessing your app at the moment. For example, apps accessing a content provider in your app will all crash.
Note that the settings UI shows a permission group as granted as long as at least one permission in the group is granted. If you want the user to observe the revocation in the settings, you should revoke every permission in the target group. To learn the current list of permissions in a group, you may use PackageManager#getGroupOfPlatformPermission(String, Executor, Consumer) and PackageManager#getPlatformPermissionsForGroup(String, Executor, Consumer) . This list of permissions may evolve over time, so it is recommended to check whether it contains any permission you wish to retain before trying to revoke an entire group.
|
Unit |
revokeUriPermission(uri: Uri!, modeFlags: Int)
|
Unit |
revokeUriPermission(targetPackage: String!, uri: Uri!, modeFlags: Int)
|
Unit |
sendBroadcast(intent: Intent!)
|
Unit |
sendBroadcast(intent: Intent!, receiverPermission: String?)
Broadcast the given intent to all interested BroadcastReceivers, allowing an optional required permission to be enforced. This call is asynchronous; it returns immediately, and you will continue executing while the receivers are run. No results are propagated from receivers and receivers can not abort the broadcast. If you want to allow receivers to propagate results or abort the broadcast, you must send an ordered broadcast using sendOrderedBroadcast(android.content.Intent,java.lang.String) .
See BroadcastReceiver for more information on Intent broadcasts.
|
Unit |
sendBroadcast(intent: Intent, receiverPermission: String?, options: Bundle?)
Broadcast the given intent to all interested BroadcastReceivers, allowing an optional required permission to be enforced. This call is asynchronous; it returns immediately, and you will continue executing while the receivers are run. No results are propagated from receivers and receivers can not abort the broadcast. If you want to allow receivers to propagate results or abort the broadcast, you must send an ordered broadcast using sendOrderedBroadcast(android.content.Intent,java.lang.String) .
See BroadcastReceiver for more information on Intent broadcasts.
|
Unit |
sendBroadcastAsUser(intent: Intent!, user: UserHandle!)
|
Unit |
sendBroadcastAsUser(intent: Intent!, user: UserHandle!, receiverPermission: String?)
|
Unit |
sendOrderedBroadcast(intent: Intent!, receiverPermission: String?)
Broadcast the given intent to all interested BroadcastReceivers, delivering them one at a time to allow more preferred receivers to consume the broadcast before it is delivered to less preferred receivers. This call is asynchronous; it returns immediately, and you will continue executing while the receivers are run.
See BroadcastReceiver for more information on Intent broadcasts.
|
Unit |
sendOrderedBroadcast(intent: Intent, receiverPermission: String?, options: Bundle?)
Broadcast the given intent to all interested BroadcastReceivers, delivering them one at a time to allow more preferred receivers to consume the broadcast before it is delivered to less preferred receivers. This call is asynchronous; it returns immediately, and you will continue executing while the receivers are run.
See BroadcastReceiver for more information on Intent broadcasts.
|
Unit |
sendOrderedBroadcast(intent: Intent, receiverPermission: String?, resultReceiver: BroadcastReceiver?, scheduler: Handler?, initialCode: Int, initialData: String?, initialExtras: Bundle?)
Version of sendBroadcast(android.content.Intent) that allows you to receive data back from the broadcast. This is accomplished by supplying your own BroadcastReceiver when calling, which will be treated as a final receiver at the end of the broadcast -- its BroadcastReceiver#onReceive method will be called with the result values collected from the other receivers. The broadcast will be serialized in the same way as calling sendOrderedBroadcast(android.content.Intent,java.lang.String) .
Like sendBroadcast(android.content.Intent) , this method is asynchronous; it will return before resultReceiver.onReceive() is called.
See BroadcastReceiver for more information on Intent broadcasts.
|
Unit |
sendOrderedBroadcast(intent: Intent, receiverPermission: String?, options: Bundle?, resultReceiver: BroadcastReceiver?, scheduler: Handler?, initialCode: Int, initialData: String?, initialExtras: Bundle?)
Version of sendBroadcast(android.content.Intent) that allows you to receive data back from the broadcast. This is accomplished by supplying your own BroadcastReceiver when calling, which will be treated as a final receiver at the end of the broadcast -- its BroadcastReceiver#onReceive method will be called with the result values collected from the other receivers. The broadcast will be serialized in the same way as calling sendOrderedBroadcast(android.content.Intent,java.lang.String) .
Like sendBroadcast(android.content.Intent) , this method is asynchronous; it will return before resultReceiver.onReceive() is called.
See BroadcastReceiver for more information on Intent broadcasts.
|
Unit |
sendOrderedBroadcast(intent: Intent, receiverPermission: String?, receiverAppOp: String?, resultReceiver: BroadcastReceiver?, scheduler: Handler?, initialCode: Int, initialData: String?, initialExtras: Bundle?)
Version of sendOrderedBroadcast(android.content.Intent,java.lang.String,android.content.BroadcastReceiver,android.os.Handler,int,java.lang.String,android.os.Bundle) that allows you to specify the App Op to enforce restrictions on which receivers the broadcast will be sent to.
See BroadcastReceiver for more information on Intent broadcasts.
|
Unit |
sendOrderedBroadcast(intent: Intent, initialCode: Int, receiverPermission: String?, receiverAppOp: String?, resultReceiver: BroadcastReceiver?, scheduler: Handler?, initialData: String?, initialExtras: Bundle?, options: Bundle?)
|
Unit |
sendOrderedBroadcastAsUser(intent: Intent!, user: UserHandle!, receiverPermission: String?, resultReceiver: BroadcastReceiver?, scheduler: Handler?, initialCode: Int, initialData: String?, initialExtras: Bundle?)
Version of sendOrderedBroadcast(android.content.Intent,java.lang.String,android.content.BroadcastReceiver,android.os.Handler,int,java.lang.String,android.os.Bundle) that allows you to specify the user the broadcast will be sent to. This is not available to applications that are not pre-installed on the system image.
See BroadcastReceiver for more information on Intent broadcasts. Requires android.Manifest.permission.INTERACT_ACROSS_USERS
|
Unit |
sendStickyBroadcast(intent: Intent!)
|
Unit |
sendStickyBroadcast(intent: Intent, options: Bundle?)
Perform a sendBroadcast(android.content.Intent) that is "sticky," meaning the Intent you are sending stays around after the broadcast is complete, so that others can quickly retrieve that data through the return value of registerReceiver(android.content.BroadcastReceiver,android.content.IntentFilter) . In all other ways, this behaves the same as sendBroadcast(android.content.Intent) .
|
Unit |
sendStickyBroadcastAsUser(intent: Intent!, user: UserHandle!)
|
Unit |
sendStickyOrderedBroadcast(intent: Intent!, resultReceiver: BroadcastReceiver?, scheduler: Handler?, initialCode: Int, initialData: String?, initialExtras: Bundle?)
Version of #sendStickyBroadcast that allows you to receive data back from the broadcast. This is accomplished by supplying your own BroadcastReceiver when calling, which will be treated as a final receiver at the end of the broadcast -- its BroadcastReceiver#onReceive method will be called with the result values collected from the other receivers. The broadcast will be serialized in the same way as calling sendOrderedBroadcast(android.content.Intent,java.lang.String) .
Like sendBroadcast(android.content.Intent) , this method is asynchronous; it will return before resultReceiver.onReceive() is called. Note that the sticky data stored is only the data you initially supply to the broadcast, not the result of any changes made by the receivers.
See BroadcastReceiver for more information on Intent broadcasts. Requires android.Manifest.permission#BROADCAST_STICKY
|
Unit |
sendStickyOrderedBroadcastAsUser(intent: Intent!, user: UserHandle!, resultReceiver: BroadcastReceiver?, scheduler: Handler?, initialCode: Int, initialData: String?, initialExtras: Bundle?)
Version of sendStickyOrderedBroadcast(android.content.Intent,android.content.BroadcastReceiver,android.os.Handler,int,java.lang.String,android.os.Bundle) that allows you to specify the user the broadcast will be sent to. This is not available to applications that are not pre-installed on the system image.
See BroadcastReceiver for more information on Intent broadcasts. Requires android.Manifest.permission.INTERACT_ACROSS_USERS and android.Manifest.permission#BROADCAST_STICKY
|
Unit |
setTheme(resid: Int)
|
Unit |
setWallpaper(bitmap: Bitmap!)
|
Unit |
setWallpaper(data: InputStream!)
|
Unit |
startActivities(intents: Array<Intent!>!)
|
Unit |
startActivities(intents: Array<Intent!>!, options: Bundle?)
Launch multiple new activities. This is generally the same as calling startActivity(android.content.Intent) for the first Intent in the array, that activity during its creation calling startActivity(android.content.Intent) for the second entry, etc. Note that unlike that approach, generally none of the activities except the last in the array will be created at this point, but rather will be created when the user first visits them (due to pressing back from the activity on top).
This method throws ActivityNotFoundException if there was no Activity found for any given Intent. In this case the state of the activity stack is undefined (some Intents in the list may be on it, some not), so you probably want to avoid such situations.
|
Unit |
startActivity(intent: Intent!)
|
Unit |
startActivity(intent: Intent!, options: Bundle?)
Launch a new activity. You will not receive any information about when the activity exits.
Note that if this method is being called from outside of an android.app.Activity Context, then the Intent must include the Intent#FLAG_ACTIVITY_NEW_TASK launch flag. This is because, without being started from an existing Activity, there is no existing task in which to place the new activity and thus it needs to be placed in its own separate task.
This method throws ActivityNotFoundException if there was no Activity found to run the given Intent.
|
ComponentName? |
startForegroundService(service: Intent!)
Similar to startService(android.content.Intent) , but with an implicit promise that the Service will call startForeground(int, android.app.Notification) once it begins running. The service is given an amount of time comparable to the ANR interval to do this, otherwise the system will automatically crash the process, in which case an internal exception ForegroundServiceDidNotStartInTimeException is logged on logcat on devices running SDK Version android.os.Build.VERSION_CODES#S or later. On older Android versions, an internal exception RemoteServiceException is logged instead, with a corresponding message.
Unlike the ordinary startService(android.content.Intent) , this method can be used at any time, regardless of whether the app hosting the service is in a foreground state.
Note: Beginning with SDK Version android.os.Build.VERSION_CODES#S , apps targeting SDK Version android.os.Build.VERSION_CODES#S or higher are not allowed to start foreground services from the background. See Behavior changes: Apps targeting Android 12 for more details.
|
Boolean |
startInstrumentation(className: ComponentName, profileFile: String?, arguments: Bundle?)
Start executing an android.app.Instrumentation class. The given Instrumentation component will be run by killing its target application (if currently running), starting the target process, instantiating the instrumentation component, and then letting it drive the application.
This function is not synchronous -- it returns as soon as the instrumentation has started and while it is running.
Instrumentation is normally only allowed to run against a package that is either unsigned or signed with a signature that the the instrumentation package is also signed with (ensuring the target trusts the instrumentation).
|
Unit |
startIntentSender(intent: IntentSender!, fillInIntent: Intent?, flagsMask: Int, flagsValues: Int, extraFlags: Int)
Same as startIntentSender(android.content.IntentSender,android.content.Intent,int,int,int,android.os.Bundle) with no options specified.
|
Unit |
startIntentSender(intent: IntentSender!, fillInIntent: Intent?, flagsMask: Int, flagsValues: Int, extraFlags: Int, options: Bundle?)
Like startActivity(android.content.Intent,android.os.Bundle) , but taking a IntentSender to start. If the IntentSender is for an activity, that activity will be started as if you had called the regular startActivity(android.content.Intent) here; otherwise, its associated action will be executed (such as sending a broadcast) as if you had called android.content.IntentSender#sendIntent on it.
|
ComponentName? |
startService(service: Intent!)
Request that a given application service be started. The Intent should either contain the complete class name of a specific service implementation to start, or a specific package name to target. If the Intent is less specified, it logs a warning about this. In this case any of the multiple matching services may be used. If this service is not already running, it will be instantiated and started (creating a process for it if needed); if it is running then it remains running.
Every call to this method will result in a corresponding call to the target service's android.app.Service#onStartCommand method, with the intent given here. This provides a convenient way to submit jobs to a service without having to bind and call on to its interface.
Using startService() overrides the default service lifetime that is managed by #bindService: it requires the service to remain running until stopService is called, regardless of whether any clients are connected to it. Note that calls to startService() do not nest: no matter how many times you call startService(), a single call to stopService will stop it.
The system attempts to keep running services around as much as possible. The only time they should be stopped is if the current foreground application is using so many resources that the service needs to be killed. If any errors happen in the service's process, it will automatically be restarted.
This function will throw SecurityException if you do not have permission to start the given service.
Note: Each call to startService() results in significant work done by the system to manage service lifecycle surrounding the processing of the intent, which can take multiple milliseconds of CPU time. Due to this cost, startService() should not be used for frequent intent delivery to a service, and only for scheduling significant work. Use #bindService for high frequency calls.
Beginning with SDK Version android.os.Build.VERSION_CODES#O , apps targeting SDK Version android.os.Build.VERSION_CODES#O or higher are not allowed to start background services from the background. See Background Execution Limits for more details.
Note: Beginning with SDK Version android.os.Build.VERSION_CODES#S , apps targeting SDK Version android.os.Build.VERSION_CODES#S or higher are not allowed to start foreground services from the background. See Behavior changes: Apps targeting Android 12 for more details.
|
Boolean |
stopService(name: Intent!)
|
Unit |
unbindService(conn: ServiceConnection)
|
Unit |
unregisterComponentCallbacks(callback: ComponentCallbacks!)
Remove a ComponentCallbacks object that was previously registered with registerComponentCallbacks(android.content.ComponentCallbacks) .
After Build.VERSION_CODES#TIRAMISU , the ComponentCallbacks will be unregistered to the base Context , and can be only used after attachBaseContext(android.content.Context)
|
Unit |
unregisterDeviceIdChangeListener(listener: IntConsumer)
Removes a device ID changed listener from the Context. It's a no-op if the listener is not already registered.
|
Unit |
unregisterReceiver(receiver: BroadcastReceiver!)
|
Unit |
updateServiceGroup(conn: ServiceConnection, group: Int, importance: Int)
|
|
From class Context
Boolean |
bindIsolatedService(service: Intent, flags: Context.BindServiceFlags, instanceName: String, executor: Executor, conn: ServiceConnection)
See bindIsolatedService(android.content.Intent,int,java.lang.String,java.util.concurrent.Executor,android.content.ServiceConnection) Call BindServiceFlags#of(long) to obtain a BindServiceFlags object.
|
Int |
getColor(id: Int)
Returns a color associated with a particular resource ID and styled for the current theme.
|
ColorStateList |
getColorStateList(id: Int)
Returns a color state list associated with a particular resource ID and styled for the current theme.
|
Drawable? |
getDrawable(id: Int)
Returns a drawable object associated with a particular resource ID and styled for the current theme.
|
String |
getString(resId: Int)
Returns a localized string from the application's package's default string table.
|
String |
getString(resId: Int, vararg formatArgs: Any!)
Returns a localized formatted string from the application's package's default string table, substituting the format arguments as defined in java.util.Formatter and java.lang.String#format.
|
T |
getSystemService(serviceClass: Class<T>)
Return the handle to a system-level service by class.
Currently available classes are: android.view.WindowManager , android.view.LayoutInflater , android.app.ActivityManager , android.os.PowerManager , android.app.AlarmManager , android.app.NotificationManager , android.app.KeyguardManager , android.location.LocationManager , android.app.SearchManager , android.os.Vibrator , android.net.ConnectivityManager , android.net.wifi.WifiManager , android.media.AudioManager , android.media.MediaRouter , android.telephony.TelephonyManager , android.telephony.SubscriptionManager , android.view.inputmethod.InputMethodManager , android.app.UiModeManager , android.app.DownloadManager , android.os.BatteryManager , android.app.job.JobScheduler , android.app.usage.NetworkStatsManager , android.content.pm.verify.domain.DomainVerificationManager , android.view.displayhash.DisplayHashManager .
Note: System services obtained via this API may be closely associated with the Context in which they are obtained from. In general, do not share the service objects between various different contexts (Activities, Applications, Services, Providers, etc.)
Note: Instant apps, for which PackageManager#isInstantApp() returns true, don't have access to the following system services: DEVICE_POLICY_SERVICE , FINGERPRINT_SERVICE , KEYGUARD_SERVICE , SHORTCUT_SERVICE , USB_SERVICE , WALLPAPER_SERVICE , WIFI_P2P_SERVICE , WIFI_SERVICE , WIFI_AWARE_SERVICE . For these services this method will return null . Generally, if you are running as an instant app you should always check whether the result of this method is null .
|
CharSequence |
getText(resId: Int)
Return a localized, styled CharSequence from the application's package's default string table.
|
TypedArray |
obtainStyledAttributes(attrs: IntArray)
Retrieve styled attribute information in this Context's theme. See android.content.res.Resources.Theme#obtainStyledAttributes(int[]) for more information.
|
TypedArray |
obtainStyledAttributes(resid: Int, attrs: IntArray)
Retrieve styled attribute information in this Context's theme. See android.content.res.Resources.Theme#obtainStyledAttributes(int, int[]) for more information.
|
TypedArray |
obtainStyledAttributes(set: AttributeSet?, attrs: IntArray)
Retrieve styled attribute information in this Context's theme. See android.content.res.Resources.Theme#obtainStyledAttributes(AttributeSet, int[], int, int) for more information.
|
TypedArray |
obtainStyledAttributes(set: AttributeSet?, attrs: IntArray, defStyleAttr: Int, defStyleRes: Int)
Retrieve styled attribute information in this Context's theme. See android.content.res.Resources.Theme#obtainStyledAttributes(AttributeSet, int[], int, int) for more information.
|
Unit |
revokeSelfPermissionOnKill(permName: String)
Triggers the asynchronous revocation of a runtime permission. If the permission is not currently granted, nothing happens (even if later granted by the user).
|
Unit |
sendBroadcastWithMultiplePermissions(intent: Intent, receiverPermissions: Array<String!>)
Broadcast the given intent to all interested BroadcastReceivers, allowing an array of required permissions to be enforced. This call is asynchronous; it returns immediately, and you will continue executing while the receivers are run. No results are propagated from receivers and receivers can not abort the broadcast. If you want to allow receivers to propagate results or abort the broadcast, you must send an ordered broadcast using sendOrderedBroadcast(android.content.Intent,java.lang.String) .
See BroadcastReceiver for more information on Intent broadcasts.
|
|
From class ComponentCallbacks
Unit |
onConfigurationChanged(newConfig: Configuration)
Called by the system when the device configuration changes while your component is running. Note that, unlike activities, other components are never restarted when a configuration changes: they must always deal with the results of the change, such as by re-retrieving resources.
At the time that this function has been called, your Resources object will have been updated to return resource values matching the new configuration.
For more information, read Handling Runtime Changes.
|
Unit |
onLowMemory()
This is called when the overall system is running low on memory, and actively running processes should trim their memory usage. While the exact point at which this will be called is not defined, generally it will happen when all background process have been killed. That is, before reaching the point of killing processes hosting service and foreground UI that we would like to avoid killing.
|
|
Constants
SERVICE_INTERFACE
static val SERVICE_INTERFACE: String
The Intent
that must be declared as handled by the service. To be supported, the service must also require the android.Manifest.permission#BIND_AUTOFILL_SERVICE
permission so that other applications can not abuse it.
Value: "android.service.autofill.AutofillService"
static val SERVICE_META_DATA: String
Name under which a AutoFillService component publishes information about itself. This meta-data should reference an XML resource containing a <autofill-service
>
tag. This is a a sample XML file configuring an AutoFillService:
<autofill-service
android:settingsActivity="foo.bar.SettingsActivity"
. . .
/>
Value: "android.autofill"
Public constructors
AutofillService
AutofillService()
Public methods
onBind
fun onBind(intent: Intent!): IBinder?
Parameters |
intent |
Intent!: The Intent that was used to bind to this service, as given to android.content.Context#bindService. Note that any extras that were included with the Intent at that point will not be seen here. |
Return |
IBinder? |
Return an IBinder through which clients can call on to the service. |
onConnected
open fun onConnected(): Unit
Called when the Android system connects to service.
You should generally do initialization here rather than in onCreate
.
onCreate
open fun onCreate(): Unit
Called by the system when the service is first created. Do not call this method directly. If you override this method you must call through to the superclass implementation.
onDisconnected
open fun onDisconnected(): Unit
Called when the Android system disconnects from the service.
At this point this service may no longer be an active AutofillService
. It should not make calls on AutofillManager
that requires the caller to be the current service.
onSavedDatasetsInfoRequest
open fun onSavedDatasetsInfoRequest(callback: SavedDatasetsInfoCallback): Unit
Called from system settings to display information about the datasets the user saved to this service.
There is no timeout for the request, but it's recommended to return the result within a few seconds, or the user may navigate away from the activity that would display the result.