Always keep all the files of the remote bugreport
operation and keep them for at least a day.
Bug: 27215341
Change-Id: I514956004bf982e868a87b39c705d7c4a4a7b001
service died.
There are scenarios when the user is running low on resources and it
kills Shell after it start monitoring a dumpstate process, in which case
the BugreportInfo is not available anymore when the user tap a
notification action.
We could add a mechanism to recover that info (like persistenting the
user-provided values in a shared preference), but would incur in more
costs when the device is already in a resource-constrained state, so
it's better to just stop monitoring and switch back to the traditional
model where the user is notified after the bugreport finishes (the
drawback is that all user-provided information will be lost).
Also improved how info.name is checked to avoid crash in similar cases.
BUG: 27186542
BUG: 27203559
Change-Id: I57076b098a3fce493e1a27121b6e070366808668
Although 'pid' is more useful when diagnosing problems with the
bugreport workflow, it could be confusing to the end user. Hence, a
sequential id (started at 1 after a reboot) would be more useful, and this CL changes Shell to accommodate such id (dumpstate will be changed separately).
BUG: 27076108
Change-Id: I5c42dc49a100b43266787d4f79698a22a4e533a9
Showing the pid is useful in many cases, like when one bug report is finished
and another one is in progress.
BUG: 26906985
Change-Id: Ib8ae462c85246b99234f8dac63edb608d1eafeb0
Otherwise, if user entered "Details" but not "Summary", the
ACTION_SEND_MULTIPLE subject would be empty.
BUG: 26768595
Change-Id: I955ab5e8f05eba9fbfa6fe65eabb6a8a8e28c5b4
If the user provides a title or description, it's necessary to create a
new zip file with the contents of the old file plus the new entries,
which takes time.
Hence, if the user didn't provide more info (title or description), we
should skip that step.
BUG: 26616935
Change-Id: Ice14f88b5763d463d8db2f942e823797e80bfde9
When a bugreport is finished, BugreportProgressService sends a
INTENT_BUGREPORT_SHARE intent containing the bugreport pid; then when
the user clicks the share notification, BugreportProgressService uses
the pid to retrieve the bugreport info.
The problem with this approach is that if the service dies before the
user clicks the notification, the bugreport won't be shared.
This change fix this scenario by saving the bugreport info in the share intent.
BUG: 26513652
Also added more logging statements.
Change-Id: Iba86d06369f843ad88194fb1dad0c8b69764df78
After receiving android.intent.action.REMOTE_BUGREPORT_FINISHED
in newly created RemoteBugreportReceiver, Shell will generate URI
to the bugreport zip file and send the broadcast
android.intent.action.REMOTE_BUGREPORT_DISPATCH.
Bug: 26152603
Change-Id: I058d626e021b488c9347b45467a4e3505134e79c
Prior to this change, the user-provide title and description were only
used in the ACTION_SEND_MULTIPLE intent, which was fine for the cases
where the user share the bug report with an app that used intent
extras (like an email app).
But if the app did not use the extras, or if
the user did not share the bug report right away, the info supplied by
the user would be lost.
With this change, such info will be saved into 2 new zip entries,
title.txt and description.txt
BUG: 26403310
Change-Id: I888364d14d67fb4e2f2c26cb66b21576d7ce13b4
notification is sent.
Prior to this change, if a screenshot finished after the share
notification was sent, it would replace the share notification with a
progress notification, and the share notification would never be sent
again.
Also improved the test cases that automatically generate a screenshot
but don't use it to wait for the screenshot to finish before proceeding,
otherwise it could cause a future test to fail (if the screenshot is
finished after the initial test is completed).
Change-Id: I6e2a6549ebb48e5bebf5aa78d1bda94404c1812b
Currently, the bugreport screenshots are taken by dumpstate and passed to
Shell as a path on BUGREPORT_RECEIVED; this change not only delegates the
screenshot taking to Shell, but also allows user to take more
screenshots while the bugreport is being generated.
As a result of this change, the final ACTION_SEND_MULTIPLE intent might
contain multiple screenshot attachments, all of them named
"screenshot-PREFIX-NUMBER.png", where PREFIX is the bugreport
name (either initial date provided by dumpstate or a name entered by the
user) and NUMBER is the sequential number of the screenshot as taken by
the user.
The screenshot is taken using screencap, which not only is simpler than
using Framework APIs, but also faster and less intrusive. The only
drawback is that it might fail if an OEM is not providing screencap; if
that happens in the field, we'll need to add fallback option to do it
using such APIs.
Prior to this change, all work done on BugreportProgressService was
executed in one single thread (through the ServiceHandler class) but the
code was guarded by unnecessary synchronization. Now there is another
thread (ScreenshotHandler) that will be used just for taking the
screenshot (so it doesn't handle the main thread). Despite the addition
of a new thread, the code was simplified to remove most synchronization
locks, excepted for the areas touched by both threads.
Once this change is submitted, the bugreport service will be changed so
it does not ask dumpstate to take a screenshot.
BUG: 26274653
Change-Id: I1df883e3c0ca6e3e3cad2522a6a99585f71abb75
The "bugreport in progress" notification now have a "DETAILS" button
that when clicked opens a dialog window displaying the following fields:
- Name: short name for the bugreport, will be used as part of the
final files (and by default is the timestamp sent by dumpstate)
- Title: a 1-line title for the bugreport, will be used as the subject
in the final message.
- Description: a detailed description for the bug.
The main advantage of such dialog is that it allows users to enter more
info about a bugreport while it's being generated, rather then when the
bugreport is finished (since of the user doesn't remember what the
context was when the problem happened).
BUG: 25794470
BUG: 10676443
Change-Id: I0d1dba2a94ad989e541415a2a59475619a2e3d13
Also added a sanity check when deleting old files to avoid a runtime
exception in the AsyncTask when the file doesn't exist.
BUG: 25752530
Change-Id: Ic4a118ae7cc5750cc96c2ac82f2c7dcc6a0cb506
Previously on 24: when a BUGREPORT_FINISHED was received,
BugreportProgressService would remove the watched BugreportInfo from its
map and if there was no info left, it would stop self and send the
SEND_MULTIPLE_ACTION intent.
Soon we're going to allow the user to enter more details (like a title
and description) for the bugreport, but if the service is stopped while
the user is still entering data, that window will be killed.
Hence, although this refactoring doesn't change the current logic, it
paves the way for such new feature.
BUG: 25794470
Change-Id: Ic5283ddc3e07d88ba2a9a925f9534426857e7606
When progress is set to 'true', it calls the new, enhanced
'bugreportplus' service, while when 'false' it calls the regular
'bugreport' service.
'bugreportplus' is more user-friendly (it shows a system notification
with the progress, allow user to cancel, etc...), at the cost of
consuming more resources. As such, the "Take Bug Report" UI will be
changed to offer the user a combo with these 2 options, but for now it's
always going to be 'bugreportplus'
BUG: 26034608
Change-Id: I21a6b5b092a85614e91d523b8f4df1fb00e49b3b
Now ServiceHandler only have 2 methods:
- handleMessage(): part of its interface.
- poll(): delegates work to parent, but sends a delayed message
so it keeps polling.
Also changed hardcoded "N/A" to a resource.
BUG: 25794470
Change-Id: I486fff46c1532685bfd6f5903349d14e55059219
The old workflow was:
1. dumpstate starts.
2. When dumpstate finishes, it sends a BUGREPORT_FINISHED intent.
3. Shell's BugreportReceiver receives the BUGREPORT_FINISHED and issues a
system notification so user can share the bug report.
The new workflow is:
1. When dumpstate starts, it sends a BUGREPORT_STARTED with its pid and
the estimated total effort.
2. When Shell's BugreportReceiver receives the BUGREPORT_STARTED, it:
2.1 Issues a system notification so user can watch the
progresss (which is 0% initially).
2.2 Starts a service (BugreportProgressService) responsible for
polling the dumpstate progress (using system properties and the
pid) and updating the system notification.
3. As dumpstate progress, it updates the proper system property.
4. When dumpstate finishes, it sends a BUGREPORT_FINISHED event.
5. When Shell's BugreportReceiver receives the BUGREPORT_FINISHED, it:
5.1 Finishes the service if necessary.
5.2 Issues a system notification so user can share the bug report.
This CL handles the Shell changes only, the dumpstate changes will be
changed in a separate CL.
BUG: 25794470
Change-Id: Icbd0b42dd48e8db376b60544348b6818c6374338
Although this Change doesn't modify the workflow logic itself, it paves
the way for upcoming changes where the overall bug report progress will
be monitored by this service.
BUG: 25794470
Change-Id: Id0c867b04b595b5d31d11531405408f3423dd68b
These tests rely in the UI Automator to interact with the UI and
follow the workflow below:
* creates the bug report files
* generates the BUGREPORT_FINISHED intent
* emulate user actions to share the intent with a custom activity
* asserts the extras received by the custom activity
It still have some limitations, like requiring the phone to be unlocked
and having the bugreport warning already checked, and those will be
addressed in future CLs.
BUG: 25752530
Change-Id: I01d7fad9f94daf156b728cbb9ef228bbfa6ee0f5
- Bug reports without screenshots are supported.
- Shows a toast message when the bugreport file cannot be read.
BUG: 25751868
Change-Id: I4ed2c47a89b373cf878720ebcba90c96bd51342b
Also labeled information contained in the body (i.e., Build Info: and Serial Number:).
BUG: 21454488
Change-Id: I5f2a62147ca3e1989aebfbd465f3e42b96b655df
The ACTION_SEND_MULTIPLE contract expects the EXTRA_TEXT to be an
ArrayList<String>, but it's currently set as String, which causes an
exception when exporting the EXTRA_STREAM as ClipData.
The right approach would be changing the EXTRA_TEXT content, but that
would break some clients like GMail, so a safer fix is to explicitly
set the ClipData.
Also removed unused variables and imports.
BUG: 21735884
BUG: 21729227
Changes to be committed:
modified: src/com/android/shell/BugreportReceiver.java
Change-Id: If9954e8cae4af7b74f077a32806f25eb7d55dffb
Many times to file a bug, its necessary to take several bugreports and
attach them all to the same bug. With the current implementation, all
extracted files are bugreport.txt which makes it difficult to attach
several bugreports to the same bug, and reference them throughout the
bug uniquely.
Bug: 20447313
Change-Id: I22d2286d06c8dfb82273b5b98c48b21f77941b15
When BugReporterReceiver receives a android.permission.DUMP, it will handle the bugreport file (extra android.intent.extra.BUGREPORT) depending on its format:
- If it's a plain-text file (extension .txt), it will create a zip file with the plain-text report renamed as bugreport.txt.
- If there is an error creating the zip file, the plain-text bugreport will be sent instead.
- If it's not a plain-text file, it fill send the file as is (so if 'dumpstate' is later changed to generate a zipped file directly, nothing has to be done here).
Note that only the bugreport itself is included in the zip file, the screenshot is still sent separately (extra android.intent.extra.SCREENSHOT), so the receiver of the bugreport intent can display a screenshot thumbnail without unzipping the other file (which is useful when sending the bugreport through GMail, for example).
BUG: 20447313
BUG: 21868658
Change-Id: I3fa1e0c89190bfe6fa5c418f0f01ce1fb376f537
Supports both age and count based constraints. Added light docs and
tests to verify behavior.
Bug: 8387555
Change-Id: If4d0dac8bc54ce705c2a339bc09a60ea748728b8
Show notification when a bugreport is finished, letting the user
launch a SEND_MULTIPLE intent to share them. Add dialog that warns
user about contents before sharing. Since bugreports are now stored
in private app data of the Shell app, use FileProvider to build Uris
that we can grant others access to.
Define BUGREPORT_FINISHED as being a protected broadcast. Delete
older bugreports automatically to reclaim disk space. Migrate any
Intent extras to ClipData when building PendingIntents.
Add --receiver-permission support to am shell command.
Bug: 7005318
Change-Id: If6c607dbcf137362d5887eac482ff7391563890f
