By using DeviceDefault instead of Material, this UI is now
resilient to any platform-level theme changes.
Change-Id: I43ce61b36f4c089ee07f754088abe2dfe6700877
Fixes: 30173174
Remove MANAGE_USERS permission from shell and whitelist it for
some specific functionality.
Bug: 29189712
Change-Id: Ifb37448c091af91991964511e3efb1bb4dea1ff3
am: 5d5ddfa80e
* commit '5d5ddfa80ecb482e34ed4bfebae2c7308269a1c4':
Register change Uri and notify changes in bugreportServices.
Change-Id: Ic118dd61f0471f61af3fe5fbace8a0dbae258484
But make sure that we don't allow Shell or other apps
to disable an active profile or device owner.
Also limit exactly what states Shell can switch apps
between, similar to Settings UI.
This is required for some CTS tests
Bug: 27924655
Change-Id: I958f0d1de7f0bc1f5a0cbf853d57dfdeb2f9ad59
am: 34510eb
* commit '34510eb2933b98f0c8c73f9a7be5eae911a14210':
Don't opt-out of warning dialog by default on user builds.
Change-Id: I4cb37a050cbed326ca78e9d3ace672819059e825
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 tests run for the first time, the list of activities that can
handle ACTION_SEND_MULTIPLE might not be scrollable, which was cause the
scrollForward() method to fail.
BUG: 27431998
Change-Id: I5992bc9fec6291c74c4af7887ee66eb4f96e87c0
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
The code that asserts the right progress is displayed was based on the
percentage text displayed in the system notification, but such text is
gone.
Since UIObject doesn't easily expose the underlying ProgressBar, such
checks were temporarily disabled.
BUG: 28114251
Change-Id: Idb64fe97cf84f5f73e08e293b8fd0384bc8b70d6
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
Mostly consists of removing the word "encryption" from most APIs,
since we can't actually make promises about the data being encrypted.
Bug: 27531029
Change-Id: Iace9d7c4e64716abf86ed11847c40f3947e1d625
