ActivityManagerService will send the details to dumpstate and
BugreportProgressService will get the details from dumpstate and use
that for the notification.
Bug: 33561517
Test: Modify TelephonyMonitor to use this API and ensure that the
notification uses that the title and description sent as arguments
to the API. File a bug using betterBug and ensure that the
information gets populated automatically.
Change-Id: I455f1df2278e5d569dd19c74245a0704dcf5a321
Bug: 36175844
Test: by generating a bugreport (long-press DPAD_CENTER + BACK)
Test: verified that BugreportProgressServiceTest still passes
Change-Id: If5bf53512c60a359838aa76dc61b90d4e67a45df
When launching ChooserActivity from lockscreen, we will start it
in stopped state because lockscreen is still showing, meaning that
the activity goes through start -> resume -> pause -> stop
immediately after it was launched, and will be later resumed once
Keyguard actually goes away.
However, ResolverActivity finished itself in onStop. We add a
private extra to change this behavior for sharing bugreports.
Test: Take bugreport, double tap on it on lockscreen
Test: com.android.shell.BugreportReceiverTest$1
Bug: 33009364
Change-Id: I973b2c71587950499b7c88b16af9cf1387795e17
Now we look at work profile too, if available, when looking for a preferred
email address.
TODO: The chooser activity should default to work profile too, but it seems
to require a lot more work, so not done yet.
Test: manual tests
Test: adb shell am instrument -w -e class com.android.shell.BugreportProgressServiceTest com.android.shell.tests
Bug 30865666
Change-Id: I9b4776d53455a23bfdc4960da25e98bd1dc1b2a1
BugreportProgressService used to poll system properties to get the
progress of the underlying dumpstate process, but now dumpstate provides
a IDumpstateListener and IDumpstateToken binder objects for the same
purpose.
Test: BugreportReceiverTest passes
Test: manual verification
BUG: 31636879
Change-Id: I81d551781a511cb1cc218a27452875b0bb267f7a
Currently, we define 4 hardcoded init services to launch dumpstate with
different command-line options (since dumpstate must be launched by
root):
- bugreport
- bugreportplus
- bugreportwear
- bugreportremote
This approach does not scale well; a better option is to have just one
service, and let the framework pass the extra arguments through a system
property.
BUG: 31649719
Test: manual
Change-Id: I1d627a73bfbdd9930c605fa4468c15282a23bb65
- testProgress_changeJustDetailsTouchingNotification was failing because
the notification mechanism changed and now provides a way to expand
and collapse the actions bar, and the test was collapsing it instead
of opening the details dialog. It was fixed by tapping the
notification content instead of the notification title.
- Similarly, openProgressNotification() was refactored to use the
bugreport name instead of id.
- Uses getObject() (instead of getVisibleObject()) to get the activity
from the intent chooser.
- Removed the redundant call to back to dismiss the keyboard, which was
causing some tests to fail due to an accessibility bug.
- Retry a few times in case the bugreport name system property assertion
fails, since the property is set by a background thread.
- Improved how notifications are canceled.
- Created a sleep() helper.
Besides the test case improvements, it also removed a redundant call to
setCancelable() in the main code.
BUG: 30641229
BUG: 30639703
Change-Id: Icd79fada22d0b8e4be034068c3e9143ef0134eed
When using startActivity(intent), the platform allows the user to pick
the same activity for the intent, which can be a problem for sharing bug
reports when the device has personal and work profiles.
Change-Id: I1fd66905feb5d894307bbe5656c2aec705a59ab7
Fixes: 22115530
BugreportProgressService do not persist the user-provided
information (like details and screenshot paths), so if it's killed by
the framework, that info is lost.
Running it as foreground mitigates the changes of it being killed.
BUG: 27431998
BUG: 28291423
Change-Id: I2f58507beb38309628f2f19d3f7f950d07eca16f
When the user enters details (title or description) to the bugreport,
Shell tries to add a title.txt (and/or description.txt) to the zip and
uses 2 instance variables (addedDetailsToZip and addingDetailsToZip) to
control its state.
The problem with the current approach is that if there is a failure
adding the entries (for example, if the entries already exist), these
variables are not updated and hence when the user taps Share, it will
try to add the entries again, which most likely would fail.
BUG: 28291423
Change-Id: I56a71256be4f8de15f8126b815334277319e8e8a
One of the changes in the 'interactive bugreport' bugreport workflow
introduced on N is that the initial screenshot was taken right away (by
Shell, not dumpstate).
Unfortunately, such initial screenshot is often delayed when the system
is overload. Also, if the user is not interested in a screenshot, it
would be adding more load on the system unnecessarily.
Given these issues, and the fact that the user can still easily take an
initial screenhsot by selecting the proper notification action, the
initial screenshot is being removed.
BUG: 28167977
Change-Id: I2cf6616ce3124102b62ec9a36dc5a0ce6455a909
When a bugreport is finished with a pending notification, it already
display a subtext explaining the situation - not only the extra title is
redundant, but it's too large.
BUG: 27583025
Change-Id: I8d8171faf7b8b86b34f6d860555839918be10550
Removed the percentage shown in the header and
migrated the name to the subtext as contentinfo
was deprecated.
Change-Id: Ifd79a67cad8958049bd29b8eb4c9bcbb4822688b
- Better dump of received intents by displayed the relevant extras.
- Gracefully handles the case where the bugreport file URI is invalid
during development.
BUG: 27996121
Change-Id: I97a48d1e9641142a43c66c1dded2f7f322dc66aa
On M, internal storage such as bugreport files were only shown when user
selected the "Show internal storage", but such UI has changed on N.
BUG: 27862860
Change-Id: I1edf086a9f9345303595ee952e4646764709d36d
When Shell receives a BUGREPORT_STARTED intent for a process it's
already monitoring, it should completely ignore it, but current it's
taking an extra screenshot.
BUG: 27804637
Change-Id: I733cacfee5e9c82646a3295b50c3856b6e0352c3
When dumpstate starts, it estimates its maximum duration and sends it
through an extra on BUGREPORT_STARTED; as it progress, it sets a system
property with its current progress and if the progress value overflows
the estimated max, it increases the max as well.
Shell uses the max/progress to display the progress % in the
system notification, and need to handle the scenario where the max
changes. The initial implementation would recalculate the progress, with
makes it swing back and forth as dumpstate increases the max.
This CL changes the Shell logic so the progress never go back, just
forward. The drawback of this approach is that if dumpstate
underestimate the maximum, the progress might get stuck in a high
value (99%) early on, but such issue will be addressed in the long
term by tuning the estimated max value.
BUG: 26354314
Change-Id: I3a5416acaffaaa43fd28d2f1f8ec8ea12aa0d91e
