Regression from merge issue that was created when merging ag/9489200 and ag/9502526.
Previously, before saving the screenshot file in the array, it had to be
created each time it was required.
Bug: 123617758
Test: manual
Change-Id: I2dc2924aa20609d2445af00025580b2752935903
BugreportCallbackImpl class methods modify (read/write) the private
variable mInfo. Add synchronized locks for consistency.
Make other methods static to be thread-safe, and operate only on its
arguments.
Bug: 123617758
Test: Build and flash. Takes bugreport as expected
Change-Id: I237fd940f5ccd4833d053558cf1b014883d59791
In the current implementation of API flow of bugreport, renaming bugreports
works fine but it changes the entire name. In legacy flow, the user is only
able to rename the suffix of the file. The prefix of the name
(bugreport-deviceName-buildID) remains unchanged. Also, wifi and
telephony bugreports have the type of the bugreport specified explicitly
in the name.
Fix Shell's rename implementation to follow legacy logic. Also stop setting
name property in the API flow since it's a functional no-op anyway, and we
want all communications to dumpstate be through the API when possible.
No need to call trackInfoWithId() for remote bugreports as Shell does not
process any notification related to it.
Bug: 123617758
Test: * Take interactive bugreport, rename and save. (work as expected)
Test: Corner case:
* Take interactive bugreport, rename and save.
* Click on the progress notification again and keep the edit box
open.
* Wait for bugreport to finish, filename edit box would be disabled
and autofilled with last saved rename. You will still be able to
edit title and summary. (works as expected)
Change-Id: I0016ef4fc1e80fb792712c45439e2b0d348f5249
Previously added "android:theme="@android:style/Theme.
DeviceDefault.DayNight" to the application tag in this manifest file to
enable dark theme for bugreport info.
BugreportWarningActivity is nested within this application tag, so
assumed all the child tags to have DayNight theme.
android:theme="@android:style/Theme.DeviceDefault.Dialog.Alert" shows
the dialog always as Dark mode.
android:theme="@android:style/Theme.DeviceDefault.Light.Dialog.Alert"
shows the dialog always as Light mode.
This bug is not easily notice-able as "Do not show this again" checkbox
is checked by default for this dialog. Unless one wipes data partition,
this dialog doesn't come up even after flashing new builds.
Bug: 141663298
Test: Normal (light mode) Trigger interactive/full/wifi bugreport.
Click on bugreport finished "Share" notification.
Light mode warning dialog should appear. (with white background)
Uncheck the "Do not show this again" checkbox to test with dark
mode.
Test: Go to Settings. Turn on Dark theme.
Trigger interactive/full/wifi bugreport.
Click on bugreport finished "Share" notification.
Dark mode warning dialog should appear. (with dark grey background)
Change-Id: I200c592608261665e4c2416303f573522c6bc59a
In legacy bugreport workflow dumpstate used to send BUGREPORT_STARTED,
BUGREPORT_FINISHED and REMOTE_BUGREPORT_FINISHED broadcasts.
BUGREPORT_FINISHED and REMOTE_BUGREPORT_FINISHED broadcasts contain
information about the bugreport file, this information is not with
dumpstate in the API WORKFLOW, and is passed to it by the API caller.
Hence these broadcasts need to be sent by the caller of the bugreport
API to share the bugreport file information in the onfinished() callback
function.
Send REMOTE_BUGREPORT_DISPATCH broadcast for DevicePolicyManager to
handle.
Add minimal information in these broadcasts. Not adding all fields that
dumpstate used to send, as most of those were used by Shell. Only
sending necessary fileds used by receivers of these broadcasts.
Handle clean up of old bugreports in onFinished() callback function
Bug: 137825297
Test: * Interactive/Full bugreports successfully created
* Share notification appears as expected
* Able to attach these to gmail
Test: * Trigger remote bugreport by hardcoding the value of remote
bugreport when calling the API
* Remote bugreport is created successfully
* No share notification (same behavior as before)
* Same logs in logcat as triggering remote bugreport using old flow:
* adb shell setprop dumpstate.options bugreportremote
* adb shell setprop ctl.start bugreport
Test: * TestDpc (go/testdpc):
* Install TestDPC
* Set it as Device Owner
* Open TestDPC to trigger a remote bugreport ("Request bugreport")
* Shows user consent for bugreport collection (indicating that the
API workflow is triggered.
* Once the collection is complete and you tap "Share" in the notification.
* TestDPC shows another notification showing the received bugreport file
path and hash.
* Verify using adb shell to check if the bugreport file is present
in the above specified file path
Change-Id: I07c0c64b74a723683601e53e3c68a374ca54f3cb
Camera CTS tests, while running with system cameras assume shell
identity for permission checking, recording tests need permissions to
record audio.
Bug: 138130599
Test: CTS camera RecordingTest with system camera.
Change-Id: I987eff88ebd06ff85024de1bfe0edb7e0fb0fa8e
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
(Don't worry, stat_sys_adb isn't going away, but it will
only be used by the ADB notification now.)
Bug: 138661761
Test: initiate bugreport from globalactions
Change-Id: I238659d50f70bfbc047133d89afb76f78ec841f9
This bug was introduced when fixing dark theme for bugreport dialogs.
Bug: 135446537
Test: manually (both in light and dark theme)
Change-Id: Ib8c16d068c00632d009033c2eab7d2d6cb7e4eea
In order to access system-only cameras client processes need
SYSTEM_CAMERA permissions in addition to CAMERA permissions. A
permission was preferred over other mechanisms such as having private
connections would need to hard-code the package name(s) of clients using
system only camera devices. A system | signature permission on the other hand,
would make this more flexible and would be better for security.
Bug: 133508924
Test: cts CameraManagerTest, CameraDeviceTest
Test: Give cts test SYSTEM_CAMERA permissions by using
adoptShellPermissions and run some camera tests.
Change-Id: Ibcd6ccdb231dcca949ed4fb14712d033a5801d36
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
Add initial set up code to migrate requestBugreport,
requestBugreportWithDescription, requestWifiBugreport and
requestTelephonyBugreport to use the new Bugreport API.
Prepare the intent (to trigger API workflow) but do not send. Not
sending the intent keeps the workflow same as before.
This set up helps to move away from directly setting system properties
(dumpstate.options.title and dumpstate.options.description).
Bug: 139415553
Test: build and flash. Taking a bugreport works as usual
Change-Id: I0b57643ff8f4eadb281e1d7788171ef751a01b79
Note that with the new Bugreporting API, SystemServer is the only
expected DumpstateListener implementation. Once we fully migrate Shell
app, we can remove the implementation in BugreportService as well.
BUG: 128980174
Test: bugreport from power menu, observe progress bar
Change-Id: I40d654a70bd9ceb3a29f8a0113b85616100f4ee9
Merged-In: I40d654a70bd9ceb3a29f8a0113b85616100f4ee9
Delete the bugreport file to free the space before returning.
Delete unnecessary if blocks as the File constructor would never return
null
Bug:123617758
Test: Force code to execute the if (screenshotFd == null) block.
Bugreport file gets deleted successfully
Change-Id: Ib88278a8a56799ef562b8b06e5e530a8e31e85d5
Note that with the new Bugreporting API, SystemServer is the only
expected DumpstateListener implementation. Once we fully migrate Shell
app, we can remove the implementation in BugreportService as well.
BUG: 128980174
Test: bugreport from power menu, observe progress bar
Change-Id: I40d654a70bd9ceb3a29f8a0113b85616100f4ee9
Removing the TODO as won't be working on improving error handling as
part of this bug. Created another bug (b/138576498) to work on better
error handling.
Bug: 123617758
Bug: 127431371
Test: builds (only removing comment)
Change-Id: I8a7fea416e9871909cfb3cc801232bff6056536e
Since bugreport API workflow will be replacing old workflow of directly
starting dumpstate, we aim that the resulting file names be the same as
the users are used to the old file names (that dumpstate used to decide).
Bug:126862297
Test: * Build and flash to the device
* Turn on Settings feature flag to use the bugreport API
* Take interactive and full bugreports
* Output file names same as before
Change-Id: I24d800e26a8cc4f739038ac0f27da13bd83f7f47
android.permission.INSTALL_GRANT_RUNTIME_PERMISSIONS
It would be duplicated and we can remove it.
Bug:
Test: refactoring CL
Change-Id: I75bf3761be64d850781c29b734c2f7e60ef3b6a2
Signed-off-by: jay <jdragon.bae@gmail.com>
dumpstate increments system property PROPERTY_LAST_ID when a bugreport
is triggered.
In the old workflow for bugreports, dumpstate used to get triggered
before Shell, and dumpstate would send the 'id' to Shell. Hence Shell
always assumed that it has a known value for 'id', that is why
'id' is declared as a final variable which could be assigned value in
the constructor.
In new workflow using API, the 'id' is incremented after dumpstate gets
triggered. Hence making the following changes:
* Changing 'id' variable to be not final
* Reading 'id' after dumpstate has incremented the system property
Bug: 123617758
Test: Build and flash to device.
Turn on the feature flaggenerate bugreports
Check the progress and Finish notifications.
Change-Id: I44762190391c128cba135bf0ef795a1ae872dbb7
* Creating screenshot file for all types of bugreport
* The logic to populate the screenshot file is in dumpstate (few
bugreport types that do not need screenshots will leave the file
untouched/empty)
* Delete the empty screenshot file and set the file to null so that
empty file does not get shared
* This TODO was previously left as binder did not allow to send null
screenshotfd, which was recently fixed. While fixing and testing the
optional screenshot fd CL with these changes, left the value "null" by
default. Fixed now.
* Not adding any logic here on the basis of the type of bugreport as
all that is already in dumpstate
* Making the names of bugreport (.zip file) and bugreport screenshot
(.png file) consistent. In the old flow also both have the same names.
Bug: 123617758
Test: * Build and flash to the device
* Turn on use bugreport API feature flag from Settings
* Take interactive bugreport
Expectation: On clicking the notification to "Share the bugreport"
only 1 file (the bugreport zip file) gets shared. Also, there is
no screenshot file in /bugreports/ in the device
* Take full bugreport
Expectation: On clicking the notification to "Share the bugreport"
2 files (bugreport zip and screenshot png file) get shared. Also
we can see the screenshot file in /bugreports/ in the device
Change-Id: I39cb6913033b6e3c61bd0c6655a76524c12d2428
Added a version of the onPermissionUpdated and
onInstallPermissionUpdated methods which will notify
OnPermissionChangedListeners, and added this to the
PermissionManagerService "updatePermissionFlags" and
"updatePermissionFlagsForAllApps" methods. Also adds
OnPermissionsChangedListener to @TestApi
Fixes: 135937566
Test: atest PermissionUpdateListenerTest
Change-Id: I906598c366234c3daaa202261678bca04837cb13
Send instant progress notification for interactive bugreports (when
using bugreport API), starting notification when progress = 0
Bug: 123617758
Test: * Build and flash to the device
* Turn on use bugreport API feature flag from Settings
* Take interactive bugreport
Expectation: Progress notification is shown instantly
Change-Id: Icd834c05324108430ee6cb9c3d8539f91059e563
