Android Q features and APIs

Android Q introduces great new features and capabilities for users and developers. This document highlights what's new for developers.

To learn about the new APIs, read the API diff report or visit the Android API reference — new APIs are highlighted to make them easy to see. Also be sure to check out Android Q behavior changes (for apps targeting Q and for all apps), as well as privacy changes, to learn about areas where platform changes may affect your apps.

Security enhancements

Android Q introduces a number of security features, which the following sections summarize.

Improved biometric authentication dialogs

Android Q introduces the following improvements to the unified biometric authentication dialogs added in Android 9:

Specify user confirmation requirements

You can now provide a hint that tells the system not to require user confirmation after the user has authenticated using an implicit biometric modality. For example, you could tell the system that no further confirmation should be required after a user has authenticated using Face authentication.

By default, the system requires user confirmation. Typically, users want to confirm sensitive or high-risk actions (for example, making a purchase). However, if you have certain low-risk actions for your app, you can provide a hint to not require user confirmation by passing false to the setRequireConfirmation() method. Because this flag is passed as a hint to the system, the system may ignore the value if the user has changed their system settings for biometric authentication.

Improved fallback support for device credentials

You can now tell the system to allow a user to authenticate using their device PIN, pattern, or password if they cannot authenticate using their biometric input for some reason. To enable this fallback support, use the setAllowDeviceCredential() method.

If your app currently uses createConfirmDeviceCredentialIntent() to fall back to device credentials, switch to using the new method instead.

Check device for biometric capability

You can now check if a device supports biometric authentication prior to invoking BiometricPrompt by using the canAuthenticate() method in the BiometricManager class.

Run embedded DEX code directly from APK

You can now tell the platform to run embedded DEX code directly from your app’s APK file. This option can help prevent an attack if an attacker ever managed to tamper with the locally compiled code on the device.

To enable this feature, set the value of the android:useEmbeddedDex attribute to true in the <application> element of your app’s manifest file. You must also build an APK that contains uncompressed DEX code that ART can access directly. Add the following options to your Gradle or Bazel configuration file to build an APK with uncompressed DEX code:


aaptOptions {
   noCompress 'dex'


   nocompress_extensions = [“.dex”],

TLS 1.3 support

The platform's TLS implementation now supports TLS 1.3. TLS 1.3 is a major revision to the TLS standard that includes performance benefits and enhanced security. Our benchmarks indicate that secure connections can be established as much as 40% faster with TLS 1.3 compared to TLS 1.2.

TLS 1.3 is enabled by default for all TLS connections. You can obtain an SSLContext that has TLS 1.3 disabled by calling SSLContext.getInstance("TLSv1.2"). You can also enable or disable protocol versions on a per-connection basis by calling setEnabledProtocols() on an appropriate object.

Here are a few important details about our TLS 1.3 implementation:

  • The TLS 1.3 cipher suites cannot be customized. The supported TLS 1.3 cipher suites are always enabled when TLS 1.3 is enabled, and any attempt to disable them via a call to setEnabledCipherSuites() is ignored.
  • When TLS 1.3 is negotiated, HandshakeCompletedListeners are called before sessions are added to the session cache (which is the opposite of TLS 1.2 and other previous versions).
  • SSLEngine instances will throw an SSLProtocolException in some circumstances where they would have thrown an SSLHandshakeException previously.
  • 0-RTT mode is not supported.

Public Conscrypt API

The Conscrypt security provider now includes a public API for TLS functionality. In the past, users could access this functionality via reflection. However, due to restrictions on calling non-public APIs added in P, this has been greylisted in Q and will be further restricted in future releases.

This update adds a collection of classes under that contain static methods to access functionality not available from the generic APIs. The names for these classes can be inferred as the plural of the associated class. For example, code that operates on instances can use methods from the new class.

Connectivity features

Android Q includes several improvements related to networking and connectivity.

Wi-Fi network connection API

Android Q adds support for peer-to-peer connections. This feature enables your app to prompt the user to change the access point that the device is connected to by using WifiNetworkSpecifier to describe properties of a requested network. The peer-to-peer connection is used for non-network-providing purposes, such as bootstrapping configuration for secondary devices like Chromecast and Google Home hardware.

You will use the following flow when using this API:

  1. Create a Wi-Fi network specifier using WifiNetworkSpecifier.Builder.

  2. Set a network filter to match networks to connect to, along with required credentials.

  3. Decide on a combination of SSID, SSID pattern, BSSID, and BSSID pattern to set the network filter in each request, subject to the following requirements:

    • Each request should provide at least one of SSID, SSID pattern, BSSID, or BSSID pattern
    • Each request can set only one of SSID or SSID pattern
    • Each request can set only one of BSSID or BSSID pattern
  4. Add the specifiers to the network request along with a NetworkCallback instance to track the status of the request.

    If the user accepts the request and the connection to the network is successful, NetworkCallback.onAvailable() is invoked on the callback object. If the user denies the request or if the connection to the network is unsuccessful, NetworkCallback.onUnavailable() is invoked on the callback object.

Peer-to-peer connections do not require Location or Wi-Fi permissions. Initiating the request to connect to a peer device launches a dialog box on the same device, from which that device's user can accept the connection request.

Bypassing user approval

Once the user approves a network to connect to in response to a request from a specific app, the device stores the approval for the particular access point. If the app makes a specific request to connect to that access point again, the device will skip the user approval phase and automatically connect to the network. If the user chooses to forget the network while connected to a network requested by the API, then this stored approval for that combination of app and network is removed, and any future request from the app will need to be approved by the user again. If the app makes a non-specific (such as with an SSID or BSSID pattern) request, then the user will need to approve the request.

Code sample

The following code sample shows how to connect to an open network with a SSID prefix of "test" and a BSSID OUI of "10:03:23":


val specifier = WifiNetworkSpecifier.Builder()
    .setSsidPattern(PatternMatcher("test", PatternMatcher.PATTERN_PREFIX))
    .setBssidPattern(MacAddress.fromString("10:03:23:00:00:00"), MacAddress.fromString("ff:ff:ff:00:00:00"))

val request = NetworkRequest.Builder()

val connectivityManager = context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager

val networkCallback = object : ConnectivityManager.NetworkCallback() {
    override fun onAvailable(network: Network?) {
        // do success processing here..

    override fun onUnavailable() {
        // do failure processing here..
connectivityManager.requestNetwork(request, networkCallback)
// Release the request when done.


final NetworkSpecifier specifier =
  new WifiNetworkSpecifier.Builder()
  .setSsidPattern(new PatternMatcher("test", PatterMatcher.PATTERN_PREFIX))
  .setBssidPattern(MacAddress.fromString("10:03:23:00:00:00"), MacAddress.fromString("ff:ff:ff:00:00:00"))

final NetworkRequest request =
  new NetworkRequest.Builder()

final ConnectivityManager connectivityManager = (ConnectivityManager)

final NetworkCallback networkCallback = new NetworkCallback() {
  void onAvailable(...) {
      // do success processing here..

  void onUnavailable(...) {
      // do failure processing here..
connectivityManager.requestNetwork(request, networkCallback);
// Release the request when done.

Wi-Fi network suggestion API

Android Q adds support for your app to add network credentials for a device to auto-connect to a Wi-Fi access point. You can supply suggestions for which network to connect to using WifiNetworkSuggestion. The platform ultimately chooses which access point to accept based on the input from your app and others.

The following code sample shows how to provide credentials for one open, one WPA2, and one WPA3 network:


val suggestion1 = WifiNetworkSuggestion.Builder()
        .setIsAppInteractionRequired() // Optional (Needs location permission)

val suggestion2 = WifiNetworkSuggestion.Builder()
        .setIsAppInteractionRequired() // Optional (Needs location permission)

val suggestion3 = WifiNetworkSuggestion.Builder()
        .setIsAppInteractionRequired() // Optional (Needs location permission)

val suggestionsList = listOf(suggestion1, suggestion2, suggestion3)

val wifiManager = context.getSystemService(Context.WIFI_SERVICE) as WifiManager

val status = wifiManager.addNetworkSuggestions(suggestionsList);
    // do error handling here

// Optional (Wait for post connection broadcast to one of your suggestions)
val intentFilter = IntentFilter(WifiManager.ACTION_WIFI_NETWORK_SUGGESTION_POST_CONNECTION);

val broadcastReceiver = object : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        if (!intent.action.equals(WifiManager.ACTION_WIFI_NETWORK_SUGGESTION_POST_CONNECTION)) {
        // do post connect processing here
context.registerReceiver(broadcastReceiver, intentFilter);


final WifiNetworkSuggestion suggestion1 =
  new WifiNetworkSuggestion.Builder()
  .setIsAppInteractionRequired() // Optional (Needs location permission)

final WifiNetworkSuggestion suggestion2 =
  new WifiNetworkSuggestion.Builder()
  .setIsAppInteractionRequired() // Optional (Needs location permission)

final WifiNetworkSuggestion suggestion3 =
  new WifiNetworkSuggestion.Builder()
  .setIsAppInteractionRequired() // Optional (Needs location permission)

final List suggestionsList =
  new ArrayList {{

final WifiManager wifiManager =
  (WifiManager) context.getSystemService(Context.WIFI_SERVICE);

final int status = wifiManager.addNetworkSuggestions(suggestionsList);
// do error handling here…

// Optional (Wait for post connection broadcast to one of your suggestions)
final IntentFilter intentFilter =

final BroadcastReceiver broadcastReceiver = new BroadcastReceiver() {
  public void onReceive(Context context, Intent intent) {
    if (!intent.getAction().equals(
    // do post connect processing here..
context.registerReceiver(broadcastReceiver, intentFilter);

The suggestions from the app must be approved by the user before the platform initiates a connection to them. This approval is provided by the user in response to a notification the first time the platform finds a network matching one of the suggestions from the app in scan results. When the platform connects to one of the network suggestions, the settings will show text that attributes the network connection to the corresponding suggester app.

Improvements to Wi-Fi high-performance and low-latency modes

Android Q allows you to provide a hint to the underlying modem to minimize latency.

Android Q extends the Wi-Fi lock API to effectively support high-performance mode and low-latency mode. Wi-Fi power save is disabled for high-performance and low-latency mode, and further latency optimization may be enabled in low-latency mode, depending on modem support.

Low-latency mode is only enabled when the application acquiring the lock is running in the foreground and the screen is on. The low-latency mode is especially helpful for real-time mobile gaming applications.

Specialized lookups in DNS resolver

Android Q adds native support for both DNS over TLS and for specialized DNS lookups. Previously, platform DNS resolver supported type A resolutions, which would resolve an IP address against a domain name with no specifics about services offered at that IP. With this update, the SRV & NAPTR lookups are now also supported.

Android Q provides developers both standard cleartext lookups and a DNS-over-TLS mode.

Wi-Fi Easy Connect

Android Q enables you to use Easy Connect to provision Wi-Fi credentials to a peer device, as a replacement of WPS which has been deprecated. Apps can integrate Easy Connect into their setup and provisioning flow by using the ACTION_PROCESS_WIFI_EASY_CONNECT_URI intent. This intent requires a URI. The calling app can retrieve the URI through various methods, including scanning a QR code from a sticker or display, or through scanning Bluetooth LE or NFC advertisements.

Once the URI is available, you can provision the peer device’s Wi-Fi credentials with the ACTION_PROCESS_WIFI_EASY_CONNECT_URI intent. This allows the user to select a Wi-Fi network to share and securely transfers the credentials.

Easy Connect does not require Location or Wi-Fi permissions.

Wi-Fi Direct connection API

The WifiP2pConfig and WifiP2pManager API classes have updates in Android Q to support fast connection establishment capabilities to Wi-Fi Direct using predetermined information. This information is shared via a side channel, such as Bluetooth or NFC.

The following code sample shows how to create a group using predetermined information:


val manager = getSystemService(Context.WIFI_P2P_SERVICE) as WifiP2pManager
val channel = manager.initialize(this, mainLooper, null)

// prefer 5G band for this group
val config = WifiP2pConfig.Builder()

// create a non-persistent group on 5GHz
manager.createGroup(channel, config, null)


WifiP2pManager manager = (WifiP2pManager) getSystemService(Context.WIFI_P2P_SERVICE);
Channel channel = manager.initialize(this, getMainLooper(), null);

// prefer 5G band for this group
WifiP2pConfig config = new WifiP2pConfig.Builder()

// create a non-persistent group on 5GHz
manager.createGroup(channel, config, null);

To join a group using credentials, replace manager.createGroup() with the following:


manager.connect(channel, config, null)


manager.connect(channel, config, null);

Bluetooth LE Connection Oriented Channels (CoC)

Android Q enables your app to use BLE CoC connections to transfer larger data streams between two BLE devices. This interface abstracts Bluetooth and connectivity mechanics to simplify implementation.

Telephony features

Android Q includes several improvements related to telephony.

Call quality improvements

Android Q adds the ability to collect information about the quality of ongoing IP Multimedia Subsystem (IMS) calls, including quality to and from the network, on devices that support the feature.

Call screening and caller ID

Android Q provides your app with a means to identify calls not in the user's address book as potential spam calls, and to have spam calls silently rejected on behalf of the user. Information about these blocked calls is logged as blocked calls in the call log to provide greater transparency to the user when they are missing calls. Use of this new API eliminates the requirement to obtain READ_CALL_LOG permissions from the user to provide call screening and caller ID functionality.

You can also configure your app to provide information about inbound callers (such as business name, Facebook contact info, and so on) which is displayed in the platform dialer app.

Call redirection service API

Android Q changes how call intents are handled. The NEW_OUTGOING_CALL broadcast is deprecated and is replaced with the CallRedirectionService API. The CallRedirectionService API provides interfaces for you to modify outgoing calls made by the Android platform. For example, third-party apps might cancel calls and reroute them over VoIP.

Media and graphics

Android Q introduces the following new media and graphics features and APIs:


The Android Native MIDI API (AMidi) gives application developers the ability to send and receive MIDI data with C/C++code, integrating more closely with their C/C++ audio/control logic and minimizing the need for JNI.

For more information, see Android Native MIDI API.

MediaCodecInfo improvements

There are new methods in MediaCodecInfo that reveal more information about a codec:

Returns true if the codec runs in software only. Software codecs make no guarantees about rendering performance.
Returns true if a codec is accelerated by hardware.
Returns true if the codec is provided by the device vendor or false if provided by the Android platform.
MediaCodecList may contain additional entries for the same underlying codec using an alternate codec name/s (alias/es). This method returns true if the codec in this entry is an alias for another codec.

In addition, MediaCodec.getCanonicalName() returns the underlying codec name for codecs created via an alias.

Performance Points

A performance point represents a codec's ability to render video at a specific height, width and frame rate. For example, the UHD_60 performance point represents Ultra High Definition video (3840x2160 pixels) rendered at 60 frames per second.

The method MediaCodecInfo.VideoCapabilities.getSupportedPerformancePoints() returns a list of PerformancePoint entries that the codec can render or capture.

You can check whether a given PerformancePoint covers another by calling PerformancePoint.covers(PerformancePoint). For example, UHD_60.covers(UHD_50) returns true.

A list of performance points is provided for all hardware-accelerated codecs. This could be an empty list if the codec does not meet even the lowest standard performance point.

Note that devices which have been upgraded to Q without updating the vendor image will not have performance point data, because this data comes from the vendor HAL. In this case, getSupportedPerformancePoints() returns null.

Monochrome camera support

Android 9 (API level 28) first introduced monochrome camera capability. Android Q adds several enhancements to monochrome camera support:

  • New Y8 stream format support to improve memory efficiency.
  • Support for monochrome raw DNG capture.
  • Introduction of MONO and NIR CFA enumerations to distinguish between regular monochrome camera and near infrared cameras.

You may use this feature to capture a native monochrome image. A logical multi-camera device may use a monochrome camera as a physical sub-camera to achieve better low-light image quality.

Dynamic Depth Format

Starting in Android Q, cameras can store the depth data for an image in a separate file, using a new schema called Dynamic Depth Format (DDF). Apps can request both the JPG image and its depth metadata, using that information to apply any blur they want in post-processing without modifying the original image data.

To read the specification for the new format, see Dynamic Depth Format.


With the release of Android Q, Android developers and partners have the option to run using ANGLE, a project in the Chrome organization that layers ES on top of Vulkan, instead of using the vendor-provided ES driver.

For details, see ANGLE.

Accessibility services API

Android Q introduces the following new accessibility service features and APIs:

AccessibilityNodeInfo entry key flag

In Android Q, AccessibilityNodeInfo has been enhanced with a new flag designating whether it represents a text entry key. You can access this flag using the method AccessibilityNodeInfo.isTextEntryKey().

Accessibility dialog spoken feedback

When an accessibility service requires the user to repeat the accessibility shortcut to start the service, the dialog can now be accompanied by a text-to-speech prompt if the service requests it.

Accessibility shortcut for physical keyboards

In Android Q, users can now trigger the accessibility shortcut on a physical keyboard by pressing Control+Alt+Z.

Soft keyboard controller enhancement

In Android Q, accessibility services can now request that the soft keyboard be displayed even when the device detects a hard keyboard attached. Users can override this behavior.

User-defined accessibility timeouts

Android Q introduces the API method AccessibilityManager.getRecommendedTimeoutMillis(), providing support for user-defined timeouts for interactive and non-interactive Accessibility UI elements. The return value is influenced by both user preferences and accessibility service APIs.

Autofill improvements

Android Q contains the following improvements to the autofill service.

You can now use the FillRequest.FLAG_COMPATIBILITY_MODE_REQUEST flag to determine whether an autofill request was generated via compatibility mode.

Save username and password simultaneously

You can now support cases where an application uses multiple activities to display username, password, and other fields by using the SaveInfo.FLAG_DELAY_SAVE flag.

User interaction with the Save UI

You can now show and hide a password field in a save dialog by setting an action listener on the dialog and changing the visibility of the corresponding password remote view.

Support for updating datasets

Autofill can now update existing passwords. For example, if a user has already stored a password, and they save a new password, Autofill now prompts the user to update the existing password instead of saving a new one.

Field Classification improvements

Android Q contains the following improvements to the Field Classification API.

UserData.Builder constructor

The UserData.Builder constructor has changed to better align to the Builder pattern.

Allow a Value to be mapped to multiple types of Category IDs

When using UserData.Builder in Android Q, you can now map a value to multiple types of category IDs. In previous releases, an exception was thrown if a value was added more than once.

Improved support for credit card numbers

Field classification can now detect four-digit numbers as the last four digits of a credit card number.

Support for app-specific field classification

Android Q adds FillResponse.setUserData(), which allows you to set app-specific user data for the duration of the session. This helps the autofill service detect types for fields with app-specific content.

UI and system controls

Android Q provides the following user-interface improvements:

Support JVMTI PopFrame caps

Android Q adds support for the can_pop_frames capability in the Android JVMTI implementation. When debugging, this feature allows you to re-run functions after pausing at a breakpoint and adjusting locals, globals, or implementation of a function. For more information, see Oracle's Pop Frame reference page.

Surface control API

Android Q provides a SurfaceControl API for low-level access to the system-compositor (SurfaceFlinger). For most users, SurfaceView is the correct way to leverage the compositor. The SurfaceControl API can be useful in certain cases, for example:

  • Synchronization of multiple surfaces
  • Cross-process surface embedding
  • Lower-level lifetime management

The SurfaceControl API is available in both SDK and NDK bindings. The NDK implementation includes an API for manual exchange of buffers with the compositor. This provides an alternative for users who have run up against the limitations of BufferQueue.

WebView hung renderer detection

Android Q introduces a new WebViewRendererClient abstract class, which apps can use to detect if a WebView has become unresponsive. To use this class:

  1. Define your own subclass and implement its onRendererResponsive() and onRendererUnresponsive() methods.
  2. Attach an instance of your WebViewRendererClient to one or more WebView objects.
  3. If the WebView becomes unresponsive, the system calls the client's onRendererUnresponsive() method, passing the WebView and WebViewRenderer. (If the WebView is single-process, the WebViewRenderer parameter is null.) Your app can take appropriate action, such as showing a dialog box to the user asking if they want to halt the rendering process.

If the WebView remains unresponsive, the system calls onRendererUnresponsive() periodically (no more than once every five seconds), but takes no other action. If the WebView becomes responsive again, the system calls onRendererResponsive() just once.

Settings panels

Android Q introduces Settings Panels, an API which allows apps to show settings to users in the context of their app. This prevents users from needing to go into Settings to change things like NFC or Mobile data in order to use the app.

Figure 1. The user tries to open a web page while the device is not connected to the network. Chrome pops up the Internet Connectivity settings panel...

Figure 2. The user can turn on Wi-Fi and select a network without leaving the Chrome app.

For example, suppose a user opens a web browser while their device is in airplane mode. Prior to Android Q, the app could only display a generic message asking the user to open Settings to restore connectivity. With Android Q, the browser app can display an inline panel showing key connectivity settings such as airplane mode, Wi-Fi (including nearby networks), and mobile data. With this panel, users can restore connectivity without leaving the app.

To display a settings panel, fire an intent with the one of the new Settings.Panel actions:


val panelIntent = Intent(Settings.Panel.settings_panel_type)


Intent panelIntent = new Intent(Settings.Panel.settings_panel_type);

settings_panel_type can be one of:

Shows settings related to internet connectivity, such as Airplane mode, Wi-Fi, and Mobile Data.
Shows Wi-Fi settings, but not the other connectivity settings. This is useful for apps that need a Wi-Fi connection to perform large uploads or downloads.
Shows all settings related to near-field communication (NFC).
Shows volume settings for all audio streams.

We are planning to introduce an AndroidX wrapper for this functionality. When called on devices running Android 9 (API level 28) or lower, the wrapper will open the most-appropriate page in the Settings app.

Sharing improvements

Android Q provides a number of improvements to sharing. For full information, see Sharing improvements in Android Q.


Android Q includes the following updates for Kotlin development.

Nullability annotations for libcore APIs

Android Q improves the coverage of nullability annotations in the SDK for libcore APIs. These annotations enable app developers who are using either Kotlin or Java nullability analysis in Android Studio to get nullness information when interacting with these APIs.

Normally, nullability contract violations in Kotlin result in compilation errors. To ensure compatibility with your existing code, any new annotations are limited to @RecentlyNullable and @RecentlyNonNull. This means that nullability violations result in warnings instead of errors.

In addition, any @RecentlyNullable or @RecentlyNonNull annotations that were added in Android 9 are changing to @Nullable and @NonNull, respectively. This means that nullability violations now lead to errors instead of warnings.

For more information about annotation changes, see Android Pie SDK is now more Kotlin-friendly on the Android Developers Blog.


Android Q includes the following NDK changes.

Improved debugging of file descriptor ownership

Android Q adds fdsan, which helps you find and fix file descriptor ownership issues more easily.

Bugs related to mishandling of file descriptor ownership, which tend to manifest as use-after-close and double-close, are analogous to the memory allocation use-after-free and double-free bugs, but tend to be much more difficult to diagnose and fix. fdsan attempts to detect and/or prevent file descriptor mismanagement by enforcing file descriptor ownership.

For more information about crashes related to these issues, see Error detected by fdsan. For more information about fdsan, see the Googlesource page on fdsan.


Applications built using the NDK with a minimum API level 29 no longer need to use emutls, but can instead use ELF TLS. Dynamic and static linker support has been added to support the new method of handling thread-local variables.

For apps built for API level 28 and lower, improvements have been implemented for libgcc/compiler-rt to work around some emutls issues.

For more information, see Android changes for NDK developers.


Android Q includes the following runtime change.

Mallinfo-based garbage collection triggering

When small platform Java objects reference huge objects in the C++ heap, the C++ objects can often be reclaimed only when the Java object is collected and, for example, finalized. In previous releases, the platform estimated the sizes of many C++ objects associated with Java objects. This estimation was not always accurate and occasionally resulted in greatly increased memory usage, as the platform failed to garbage collect when it should have.

In Q, the garbage collector (GC) tracks the total size of the heap allocated by system malloc(), ensuring that large malloc() allocations are always included in GC-triggering calculations. Apps interleaving large numbers of C++ allocations with Java execution might see an increase in garbage collection frequency as a result. Other apps might see a small decrease.

Testing and debugging

Android Q includes the following improvements for testing and debugging.

Improvements for on-device system tracing

You can now specify limits for the size and duration of a trace when you perform an on-device system trace. When you specify either value, the system performs a long trace, periodically copying the trace buffer to the destination file while the trace is recorded. The trace completes when the size or duration limits that you specified are reached.

Use these additional parameters to test different use cases than you would test with a standard trace. For example, you might be diagnosing a performance bug that only occurs after your app has been running for a long period of time. In this case, you could record a long trace over an entire day, and then analyze the CPU scheduler, disk activity, app threads, and other data in the report to help you determine the cause of the bug.