From f4269f59b52b8acc83239e62f07898bcd380cbcf Mon Sep 17 00:00:00 2001 From: Android Partner Docs Date: Thu, 13 Apr 2017 21:37:05 -0700 Subject: Docs: Changes to source.android.com - 153141633 Update link to Security bug template in preparation for l... by daroberts - 153141624 Update bug reporting links to Issue Tracker by daroberts - 153130270 Typo fix, submitted by YOUNG HO CHA by blamb - 153128486 Fix next wave of broken links from migration by claym PiperOrigin-RevId: 153141633 Change-Id: I04448bdc8953376ade5328af97f868f0b3670cfb --- en/compatibility/index.html | 2 +- en/devices/audio/index.html | 2 +- en/devices/audio/terminology.html | 2 +- en/devices/audio/usb.html | 2 +- en/devices/automotive.html | 2 +- en/devices/sensors/sensor-stack.html | 4 +- en/devices/tech/ota/tools.html | 15 +- .../tradefed/fundamentals/lifecycle.html | 14 +- en/security/overview/acknowledgements.html | 4 +- en/security/overview/app-security.html | 29 +- en/security/overview/updates-resources.html | 15 +- en/source/community.html | 2 - en/source/life-of-a-bug.html | 231 ++++++-------- en/source/report-bugs.html | 335 +++++++++++++++++---- 14 files changed, 423 insertions(+), 236 deletions(-) diff --git a/en/compatibility/index.html b/en/compatibility/index.html index 26ec785f..e6bc9959 100644 --- a/en/compatibility/index.html +++ b/en/compatibility/index.html @@ -76,7 +76,7 @@ to your hardware. (PDF, HTML). The CDD enumerates the software and hardware requirements of a compatible Android device. -
  • Pass the Compatibility +
  • Pass the Compatibility Test Suite (CTS). Use the CTS as an ongoing aid to evaluate compatibility during the development process.
    • diff --git a/en/devices/audio/index.html b/en/devices/audio/index.html index 77aba3bf..e016b929 100644 --- a/en/devices/audio/index.html +++ b/en/devices/audio/index.html @@ -100,7 +100,7 @@ The HAL defines the standard interface that audio services call into and that you must implement for your audio hardware to function correctly. The audio HAL interfaces are located in hardware/libhardware/include/hardware. For details, see hardware/audio.h. +href="https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/audio.h">audio.h.
    diff --git a/en/devices/audio/terminology.html b/en/devices/audio/terminology.html index f84fa88b..14994d3c 100644 --- a/en/devices/audio/terminology.html +++ b/en/devices/audio/terminology.html @@ -427,7 +427,7 @@ on intra-device interconnections, refer to the following articles: In ALSA System on Chip (ASoC), these are collectively called -Digital Audio Interfaces +Digital Audio Interfaces (DAI).

    diff --git a/en/devices/audio/usb.html b/en/devices/audio/usb.html index e3d5fce7..f1c99ff6 100644 --- a/en/devices/audio/usb.html +++ b/en/devices/audio/usb.html @@ -554,7 +554,7 @@ In order to support USB digital audio, device OEMs and SoC vendors should:
  • enable generic USB host support at the framework level via the android.hardware.usb.host.xml feature flag
  • enable all kernel features needed: USB host mode, USB audio, isochronous transfer mode; -see Android Kernel Configuration
    • +see Android Kernel Configuration
  • keep up-to-date with recent kernel releases and patches; despite the noble goal of class compliance, there are extant audio peripherals with quirks, diff --git a/en/devices/automotive.html b/en/devices/automotive.html index 584fd7a4..d77e5645 100644 --- a/en/devices/automotive.html +++ b/en/devices/automotive.html @@ -183,7 +183,7 @@ such cases, use special values to represent such state.

    Example: get HVAC Temperature

    Vehicle HAL get HVAC example -

    Figure 2. Get HVAC temperature (CD = +

    Figure 2. Get HVAC temperature (CS = CarService, VNS = VehicleNetworkService, VHAL = Vehicle HAL)

    Set calls

    diff --git a/en/devices/sensors/sensor-stack.html b/en/devices/sensors/sensor-stack.html index cd4fcab1..8ec03204 100644 --- a/en/devices/sensors/sensor-stack.html +++ b/en/devices/sensors/sensor-stack.html @@ -127,7 +127,9 @@

    The interface is defined by Android and AOSP contributors, and the implementation is provided by the manufacturer of the device.

    The sensor HAL interface is located in hardware/libhardware/include/hardware. - See sensors.h for additional details.

    + See sensors.h + for additional details.

    Release cycle

    The HAL implementation specifies what version of the HAL interface it implements by setting your_poll_device.common.version. The existing HAL diff --git a/en/devices/tech/ota/tools.html b/en/devices/tech/ota/tools.html index 32eec985..1b26f918 100644 --- a/en/devices/tech/ota/tools.html +++ b/en/devices/tech/ota/tools.html @@ -23,11 +23,12 @@ -

    The ota_from_target_files tool provided in -build/tools/releasetools can build two types of package: full - and incremental. The tool takes the target-files .zip file -produced by the Android build system as input.

    +

    The ota_from_target_files +tool provided in build/tools/releasetools can build two types of +package: full and incremental. The tool takes the +target-files .zip file produced by the Android build system as +input.

    Full updates

    A full update is one where the entire final state of the device @@ -62,8 +63,8 @@ done.

    The ota_update.zip is now ready to be sent to test devices (everything is signed with the test key). For user devices, generate and use your own private -keys as detailed in Signing builds for release. +keys as detailed in Signing builds + for release.

    Incremental updates

    An incremental update contains a set of binary patches to be applied diff --git a/en/devices/tech/test_infra/tradefed/fundamentals/lifecycle.html b/en/devices/tech/test_infra/tradefed/fundamentals/lifecycle.html index f5c836d1..a46bb22c 100644 --- a/en/devices/tech/test_infra/tradefed/fundamentals/lifecycle.html +++ b/en/devices/tech/test_infra/tradefed/fundamentals/lifecycle.html @@ -26,17 +26,17 @@

    The lifecycle of a test executed using TradeFederation is composed of four separate stages, designed around formally defined interfaces.

      -
    • Build Provider: Provides a build to test, downloading appropriate files if necessary.
      • -
    • Target Preparer: Prepares the test environment, possibly including software installation and device configuration.
      • -
    • Test: Executes test(s) and gathers test results. This may be any JUnit Test, although our - IRemoteTest interface is specifically designed to work well in the Trade Federation environment.
      • -
    • Test Invocation Listener: Listens for test results, usually for the purpose of forwarding the test results to a repository or displaying them to the Test Runner.
    @@ -59,9 +59,9 @@ In short, an Invocation encompasses a complete TF test execution, across its ent

    Additional Components of a Configuration

      -
    • Device Recovery: mechanism to recover device communication if lost.
      • -
    • Logger: collects tradefed logging data.
      • +
    • Logger: collects tradefed logging data.
    diff --git a/en/security/overview/acknowledgements.html b/en/security/overview/acknowledgements.html index fd84ebd0..91b170c0 100644 --- a/en/security/overview/acknowledgements.html +++ b/en/security/overview/acknowledgements.html @@ -909,7 +909,7 @@ alt="Patch Symbol" title="This person contributed code that improved Android sec Indiana University Bloomington (xw7@indiana.edu)

    -

    Xiaoyong Zhou of Xiaoyong Zhou of Indiana University Bloomington
    (@xzhou, zhou.xiaoyong@gmail.com)

    @@ -967,7 +967,7 @@ at Urbana-Champaign

    Qualcomm Product Security Initiative

    -

    Roee Hay (@roeehay, +

    Roee Hay (@roeehay, roeehay@gmail.com)

    Robert Craig of diff --git a/en/security/overview/app-security.html b/en/security/overview/app-security.html index 6501c68f..ea20c611 100644 --- a/en/security/overview/app-security.html +++ b/en/security/overview/app-security.html @@ -33,33 +33,40 @@

    The main Android application building blocks are:

    • -

      AndroidManifest.xml: The AndroidManifest.xml file is the control file that tells the system what to do with +

      AndroidManifest.xml: The AndroidManifest.xml + file is the control file that tells the system what to do with all the top-level components (specifically activities, services, broadcast receivers, and content providers described below) in an application. This also specifies which permissions are required.

    • -

      Activities: An Activity is, generally, the code for a single, user-focused task. It usually +

      Activities: An Activity + is, generally, the code for a single, user-focused task. It usually includes displaying a UI to the user, but it does not have to -- some Activities never display UIs. Typically, one of the application's Activities is the entry point to an application.

    • -

      Services: A Service is a body of code that runs in the background. It can run in its own process, - or in the context of another application's process. Other components "bind" to +

      Services: A Service + is a body of code that runs in the background. It can run in its own + process, or in the context of another application's process. Other components "bind" to a Service and invoke methods on it via remote procedure calls. An example of a Service is a media player: even when the user quits the media-selection UI, the user probably still intends for music to keep playing. A Service keeps the music going even when the UI has completed.

    • -

      Broadcast Receiver: A BroadcastReceiver is an object that is instantiated when an IPC mechanism - known as an Intent is issued by the operating system or another application. An application may - register a receiver for the low battery message, for example, and change its - behavior based on that information.

      +

      Broadcast Receiver: A BroadcastReceiver + is an object that is instantiated when an IPC mechanism + known as an Intent + is issued by the operating system or another application. An application + may register a receiver for the low battery message, for example, and + change its behavior based on that information.

    The Android Permission Model: Accessing Protected APIs

    diff --git a/en/security/overview/updates-resources.html b/en/security/overview/updates-resources.html index 48a43340..c524b5ff 100644 --- a/en/security/overview/updates-resources.html +++ b/en/security/overview/updates-resources.html @@ -1,6 +1,6 @@ - Security updates and resources + Security Updates and Resources @@ -31,10 +31,9 @@ with Android devices.

    The Android security team finds security vulnerabilities through internal research and also responds to bugs reported by third parties. Sources of -external bugs include issues reported through the Android Open Source -Project (AOSP) Security -bug report template, published and pre-published academic research, +external bugs include issues reported through the Android +Security Issue template, published and pre-published academic research, upstream open source project maintainers, notifications from our device manufacturer partners, and publicly disclosed issues posted on blogs or social media.

    @@ -42,9 +41,9 @@ media.

    Reporting security issues

    Any developer, Android user, or security researcher can notify the Android -security team of potential security issues through the AOSP bug tracker Security -bug report template.

    +security team of potential security issues through the +Android Security Issue template.

    Bugs marked as security issues are not externally visible, but they may eventually be made visible after the issue is evaluated or resolved. If you diff --git a/en/source/community.html b/en/source/community.html index b2e414a4..2e78a9c8 100644 --- a/en/source/community.html +++ b/en/source/community.html @@ -68,8 +68,6 @@ page. For other information about Android, refer to the following resources.

    Send feedback
    Report AOSP bug
    -Suggest -a feature

    diff --git a/en/source/life-of-a-bug.html b/en/source/life-of-a-bug.html index 28140bcc..571b7cd6 100644 --- a/en/source/life-of-a-bug.html +++ b/en/source/life-of-a-bug.html @@ -27,170 +27,125 @@ can report bugs and request features for the core Android software stack. (For details on this issue tracker, please see the Reporting Bugs page). Reporting bugs is great (thank you!), but what happens to a bug report once -you file it? This page describes the Life of a Bug.

    +you file it? This page describes the life of a bug.

    -

    *Please note: the Android Open Source Project (AOSP) issue tracker is +

    The Android Open Source Project (AOSP) issue tracker is intended only for bugs and feature requests related to the core Android software stack, and is a technical tool for the Open Source community.

    -

    This is not a customer support forum. -You can find support for Nexus devices on -Google's Nexus support site. +

    This is not a customer support forum. For support information, see the +Nexus and +Pixel help centers. Support for other devices is provided by the device manufacturers or by the carriers selling those devices.

    Support for Google applications is through Google's support site. Support -for 3rd-party applications is with each application's developer, e.g. +for third-party applications is with each application's developer, e.g. through the contact information provided on Google Play.

    Here's the life of a bug, in a nutshell:

      -
    1. -

      A bug is filed, and has the state "New".

      -
      2. -
    2. -

      An AOSP maintainer periodically reviews and triages bugs. Bugs are -triaged into one of four "buckets": New, Open, No-Action, or Resolved.

      -
      3. -
    3. -

      Each bucket includes a number of states that provide more detail on the -fate of the issue.

      -
      4. -
    4. -

      Bugs in the "Resolved" bucket will eventually be included in a future -release of the Android software.

      -
      5. +
    5. A bug is filed, and has the state "New".
      6. +
    6. An AOSP maintainer periodically reviews and triages bugs. Bugs are +triaged into one of four buckets: New, Open, No-Action, or Resolved.
      7. +
    7. Each bucket includes a number of states that provide more detail on the +fate of the issue.
      8. +
    8. Bugs marked as "Resolved" will eventually be included in a future +release of the Android software.
    -

    Bucket Details

    -

    Here is some additional information on each bucket, what it means, and how -it's handled.

    -

    New Issues

    -

    New issues include bug reports that are not yet being acted upon. The two -states are:

    + + +

    Bucket details

    +

    +We use the Status field in Issue Tracker to specify the status +of an issue in the resolution process. This is consistent with the definitions +specified in the Issue + Tracker documentation. +

    +

    New issues

    +

    +New issues include bug reports that are not yet being acted upon. The two states +are: +

      -
    • -

      New: - The bug report has not yet been triaged (that is, reviewed by an AOSP maintainer.)

      -
      • -
    • -

      NeedsInfo: - The bug report has insufficient information to act -upon. The person who reported the bug needs to provide additional detail -before it can be triaged. If enough time passes and no new information is -provided, the bug may be closed by default, as one of the No-Action -states.

      -
      • +
    • New: The bug report has not yet been triaged (that is, + reviewed by an AOSP maintainer.)
      • +
    • New + Hotlist:NeedsInfo: The bug report has insufficient + information to act upon. The person who reported the bug needs to provide + additional detail before it can be triaged. If enough time passes and no new + information is provided, the bug may be closed by default, as one of the + No-Action states.
    -

    Open Issues

    -

    This bucket contains bugs that need action, but which are still -unresolved, pending a change to the source code.

    +

    Open issues

    +

    +This bucket contains bugs that need action, but which are still unresolved, +pending a change to the source code. +

      -
    • -

      Unassigned: - The bug report has been recognized as an adequately -detailed report of a legitimate issue, but has not yet been assigned to an -AOSP contributor to be fixed.

      -
      • -
    • -

      Assigned: - Like Unassigned, but the bug has been -actually assigned to a specific contributor to fix.

      -
      • +
    • Assigned: The bug report has been recognized as an + adequately detailed report of a legitimate issue and the bug has been assigned + to a specific contributor to assess and analyze.
      • +
    • Accepted: The assignee has acknowledged the issue and has + started to work on it.
    -

    Typically, a given bug will start in Unassigned, where it -will remain until someone intends to resolve it, at which -point it will enter Assigned. However, -note that this isn't a guarantee, and it's not uncommon for bugs to go from -Unassigned to one of the Resolved states.

    -

    In general, if a bug is in one of these Open states, the AOSP team has -recognized it as a legitimate issue, and a high-quality contribution fixing -that bug is likely to get accepted. However, it's impossible to guarantee a -fix in time for any particular release.

    - -

    No-Action Issues

    -

    This bucket contains bugs that have for one reason or another been -determined to not require any action.

    +

    +Typically, a bug starts in Assigned, and remains there until +someone intends to resolve it, at which point it enters +Accepted. However, note that this isn't a guarantee, and it's +not uncommon for bugs to go from Assigned to one of the +Resolved states. +

    +

    +In general, if a bug is in one of these Open states, the AOSP team has +recognized it as a legitimate issue, and a high-quality contribution fixing that +bug is likely to get accepted. However, it's impossible to guarantee a fix in +time for any particular release. +

    +

    No-Action issues

    +

    +This bucket contains bugs that are deemed to not require any action. +

      -
    • -

      Spam: - A kind soul sent us some delicious pork products, that we, -regrettably, do not want.

      -
      • -
    • -

      Duplicate: - There was already an identical report in the issue tracker. Any actual -action will be reported on that report.

      -
      • -
    • -

      Unreproducible: - An AOSP contributor attempted to reproduce the -behavior described, and was unable to do so. This sometimes means that the bug -is legitimate but simply rare or difficult to reproduce, and sometimes means -that the bug was fixed in a later release.

      -
      • -
    • -

      Obsolete: - Similar to Unreproducible, but with a reasonable certainty -that the bug did exist in the reported version but was already fixed in -a later release.

      -
      • -
    • -

      WorkingAsIntended: - An AOSP maintainer has determined that the -behavior described isn't a bug, but is the intended behavior. This state is -also commonly referred to as "WAI".

      -
      • -
    • -

      Declined: - This is like WorkingAsIntended, except -typically used for feature requests instead of bugs. That is, an AOSP -maintainer has determined that the request is not going to be implemented in -Android.

      -
      • -
    • -

      NotEnoughInformation: - The report didn't have enough information to be able to take any action.

      -
      • -
    • -

      UserError: - The report was the result of a user making a mistake while using Android, -e.g. typing a wrong password and therefore not being able to connect to a -server.

      -
      • -
    • -

      WrongForum: - The report cannot be handled in AOSP, typically because it is related -to a customized device or to an external application.

      -
      • -
    • -

      Question: - Someone mistook the issue tracker for a help forum.

      -
      • +
    • Won't Fix (Not reproducible): An AOSP contributor attempted + to reproduce the behavior described, and was unable to do so. This sometimes + means that the bug is legitimate but simply rare or difficult to reproduce, or + there was not enough information to fix the issue.
      • +
    • Won't Fix (Intended behavior): An AOSP maintainer has + determined that the behavior described isn't a bug, but is the intended + behavior. This state is also commonly referred to as working as + intended (WAI). For feature requests, an AOSP maintainer has determined + that the request is not going to be implemented in Android.
      • +
    • Won't Fix (Obsolete): The issue is no longer relevant due + to changes in the product.
      • +
    • Won't Fix (Infeasible): The changes that are needed to + address the issue are not reasonably possible. This status is also used for + issues reported that cannot be handled in AOSP, typically because it is related + to a customized device or to an external application, or the reporter mistook + this tracker as a help forum.
      • +
    • Duplicate: There was already an identical report in the + issue tracker. Any actual action will be reported on that report.
    -

    Resolved Issues

    -

    This bucket contains bugs that have had action taken, and are now -considered resolved.

    +

    Resolved issues

    +

    +This bucket contains bugs that have had action taken, and are now considered +resolved. +

      -
    • -

      Released: - This bug has been fixed, and is included in a formal release. -When this state is set, we try to also set a -property indicating which release it was fixed in.

      -
      • -
    • -

      FutureRelease: - This bug has been fixed (or feature implemented) in -a source tree, but has not yet been included in a formal release.

      -
      • +
    • Fixed (verified): This bug has been fixed, and is included + in a formal release. When this state is set, we try to also set a property + indicating which release it was fixed in.
      • +
    • Fixed: This bug has been fixed (or feature implemented) in + a source tree, but might not yet been included in a formal release.
    -

    Other Stuff

    -

    The states and lifecycle above are how we generally try to track software. +

    Other stuff

    +

    +The states and lifecycle above are how we generally try to track software. However, Android contains a lot of software and gets a correspondingly large number of bugs. As a result, sometimes bugs don't make it through all the states in a formal progression. We do try to keep the system up to date, but we tend to do so in periodic "bug sweeps" where we review the database and make updates.

    - diff --git a/en/source/report-bugs.html b/en/source/report-bugs.html index e6077744..8c7e55f6 100644 --- a/en/source/report-bugs.html +++ b/en/source/report-bugs.html @@ -20,62 +20,287 @@ See the License for the specific language governing permissions and limitations under the License. --> +

    +Thank you for your interest in Android! You can help improve Android by +reporting issues and feature requests in +Issue +Tracker. The Android Issue Tracker contains a list of pending technical +tasks across a variety of topics, information relevant to those tasks, and +information about progress on those tasks, including which ones might get worked +on in the short term. +

    +

    +Issue Tracker is not a customer support forum. For support information, see the +Nexus and +Pixel help centers. Support for +other devices is provided by the device manufacturers or by the carriers selling +those devices. +

    +

    +Support for Google applications is through +Google's support site. Support for +third-party applications is provided by the application's developer, e.g. +through the contact information provided on Google Play. For a list of more +Android support resources, see our Community page. +

    +

    +There are no guarantees that any particular bug can be fixed in any particular +release. To see what happens to your bug once you report it, read +Life of a Bug. +

    +

    Filing a bug

    +
      +
    1. Search +for your bug to see if anyone has already reported it. Don't forget to +search for all issues, not just open ones, as your issue might already have been +reported and closed. To help you find the most popular results, sort the result +by number of stars.
      2. +
    2. If you find your issue and it's important to you, +star +it! The number of +stars on a bug helps us know which bugs are most important to fix.
      3. +
    3. If no one has reported your bug, file the bug. First, +browse for the correct +component, such as Framework +or Networking, +and fill out the provided template. Or select the desired bug queue from the +tables below. +

      +Tip: Some components contain sub-components, like Network > +Messaging and Framework > Storage. +

      +
      4. +
    4. Include as much information in bugs as you can, following the instructions +for the bug queue you're targeting. A bug that simply says something isn't +working doesn't help much, and will probably be closed without any action. The +amount of detail you provide, such as log files, repro steps, and even a patch +set, helps us address your issue.
      5. +
    +

    Bug queues

    +

    +The Android Issue Tracker has a variety of sub-components in a number of +categories related to Android. There are subcomponents for security, the +platform, Android Developer Tools, documentation, and more. +

    +

    Security

    +

    +If you find an issue that impacts the security of Android or components in Nexus +or Pixel devices, follow the instructions +here. +Additionally, security bugs are eligible for the +Android +Security Vulnerability Rewards Program. +

    +

    +Because of the sensitive nature of security bugs, you won't be able to browse +open issues, only closed issues or issues that have been made public. +

    -

    Thank you for your interest in Android! One of the best ways you can help us -improve Android is to let us know about any problems you find with it.

    -

    Note: For security vulnerabilities, please use -the AOSP bug tracker Security -bug report template. See Reporting -Security Issues for additional details.

    -

    Here's how to report non-security bugs:

    -
      -
    • -

      Search for -your bug to see if anyone has already reported it. Don't forget to -search for all issues, not just open ones, as your issue might already -have been reported and closed. To help you find the most popular results, -sort the result by number of stars.

      -
      • -
    • -

      If you find your issue and it's important to you, star it! That's how we know which bugs are most important to fix.

      -
      • -
    • -

      If no one has reported your bug, file the bug. You can use one of these templates:

      -
        -
      • -

        Bug in your Device - -use this if you are a user reporting a bug in a device you own

        -
        • -
      • -

        Bug in the Software - -use this if you found a bug in the course of developing an app

        -
        • -
      • -

        Feature Request - -use this for a feature you'd like to see in a future verison

        -
        • -
      -
      • -
    -

    Keep in mind that an issue tracker is not a user support forum. It is a list -of pending technical tasks, along with information relevant for those tasks, -and information about progress on those tasks including which ones might -get worked on in the short term.

    -

    This issue tracker is narrowly focused on the Android Open Source Project. -Issues with retail devices need to be reported through those devices' support -channels, especially for devices other than Nexus. Issues with applications -that aren't part of AOSP need to be reported with those applications' -developers; that is also the case for Google applications.

    -

    Please note that we can't guarantee that any particular bug can be fixed in -any particular release. To see what happens to your bug once you report it, -read Life of a Bug.

    -

    In general, please put as much information in bugs as you can. Just a one liner -telling us something isn't working is usually useless, and will probably be -closed without any action. The more detail you provide, the more likely your -issue is to be resolved.

    - + + + + + + + + + + + + +
    Browse bugsDetailsFile a bug
    SecurityAndroid Security details + bug_report
    + +

    Platform

    +

    +If you find an issue that impacts an aspect of the Android platform, file your +bug in one of these components. +

    +

    Browse all platform issues

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Browse bugsFile a bug
    ARTbug_report
    Browserbug_report
    CTSbug_report
    Frameworkbug_report
    GfxMediabug_report
    Jackbug_report
    Libcorebug_report
    Networkingbug_report
    Securitybug_report
    Systembug_report
    Textbug_report
    Thingsbug_report
    Wearbug_report
    + +

    Android Developer Tools

    +

    +If you find an issue that impacts one of the Android Developer tools, such as +Android Studio, SDK, Emulator, System Images, or Support Library, file a bug in +one of these components. +

    +

    +As the tools have different requirements, read the +General Bug filing +details and the linked details for the tool. +

    + +Browse all +Developer Tools issues + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Browse bugsDetailsFile a bug
    Android +StudioAndroid +Studio details + bug_report
    C++Issues in Android Studio + bug_report
    Emulator or +System ImagesEmulator + details + bug_report
    GradleGradle + details + bug_report
    Instant +RunInstant + Run details + bug_report
    Lint + bug_report
    NDKStandalone NDK issuesbug_report
    Profilers + bug_report
    Support +Library + bug_report
    Test +Support Library + bug_report
    + +

    Documentation

    +

    +If you find an issue with this site or with +developer.android.com, +file a bug and a writer will help. +

    + + + + + + + + + + + + + + +
    Browse bugsFile a bug
    developer.android.com + bug_report
    source.android.com + bug_report
    + + -- cgit v1.2.3