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
Changes:
- Removed hints.
- Added TextViews for field labels.
- Added padding for inner dialog
- Adedd autoCorrect and capSentences to title and summary
- Changed strings.
- Set name to be selectAllOnFocus initially.
Also improved some logging statements.
BUG: 26324085
Change-Id: I32597a7c2839ca706dbbcf13660e976469ab8dd0
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
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
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
- Bug reports without screenshots are supported.
- Shows a toast message when the bugreport file cannot be read.
BUG: 25751868
Change-Id: I4ed2c47a89b373cf878720ebcba90c96bd51342b
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
Rework how the shell user is defined so that it is
associated with an actual apk, instead of being a free
roaming uid with special permissions assigned to it.
This allows us to correctly account for its operations
in app ops.
Implement a special case for the root user in app ops --
it is always allowed, always with the package name "root".
Add various code to take care of cleaning up package state
from app ops -- when packages are uninstalled, and during
boot if any packages currently being stored no longer exist.
Also fix a bug in the activity manager to correctly grant
permissions in all cases when onNewIntent() is being called.
Change-Id: Iae9f6d793ee48b93518c984ad957e46ae4582581
