When wide color gamut rendering is requested, hwui will now
use an rgba16f scRGB-nl surface for rendering. This change
also fixes the way screenshots are handled in the platform
to behave properly with wide gamut rendering.
This change does not affect hardware layers. They also
need to use rgba16f scRGB-nl; this will be addressed in
another CL.
Bug: 29940137
Test: CtsUiRenderingTestCases, CtsGraphicsTestCases
Change-Id: I68fd96c451652136c566ec48fb0e97c2a7a257c5
Was caused by a new requirement to not offer to show
non-exported intent handlers as options. For first
time warning dialog, don't show a chooser activity.
Change-Id: Ibada9a7a14b77ec0670bf35ba0944f369d42bf69
Fixes: 62169466
Test: manual
Test: mmm -j32 frameworks/base/packages/Shell && adb install -r -g ${OUT}/data/app/ShellTests/ShellTests.apk && adb shell am instrument -e class com.android.shell.BugreportReceiverTest$1 -w com.android.shell.tests/android.support.test.runner.AndroidJUnitRunner
Overall we need more synchronization, but I'm taking a safe approach
here for oc-dev for now.
Bug: 62043115
Test: adb shell am instrument -w com.android.shell.tests
Change-Id: I0e22c5160cb96ce51dc1775237f01b7bf5c97a17
This flag is required whenever starting an activity from a
non-activity context.
Change-Id: Ia77e6e7801d712a20d407bc2ac92e543bc287010
Fixes: 62016780
Test: Click on generated bug report notification
This allows it to gain all the benefits of FSP, ie. listening in on
File-system level changes without any explicitly notification Uri
passing back and forth.
This also reverts commit 6c9ff513c6d7d3de7ab8920d88111c2b1dc1bb1f.
Test: Manual test.
Bug: 38183534
Change-Id: I30a1d8489ec8732bdb80611bd8fa7099763de2a3
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
