O_RDONLY, O_WRONLY, and O_RDWR are not flags. Rather, they are the
integer values 0, 1, and 2, respectively.
#define O_RDONLY 00000000
#define O_WRONLY 00000001
#define O_RDWR 00000002
Quoting "man 2 open"
* File access mode *
Unlike the other values that can be specified in flags,
the access mode values O_RDONLY, O_WRONLY, and O_RDWR do not
specify individual bits. Rather, they define the low order
two bits of flags, and are defined respectively as 0, 1, and
2. In other words, the combination O_RDONLY | O_WRONLY is a
logical error, and certainly does not have the same meaning
as O_RDWR.
Linux reserves the special, nonstandard access mode 3
(binary 11) in flags to mean: check for read and write
permission on the file and return a file descriptor that
can't be used for reading or writing. This nonstandard access
mode is used by some Linux drivers to return a file
descriptor that is to be used only for device-specific
ioctl(2) operations.
Rather than treat these values like flags, use O_ACCMODE to extract the
values and then perform the comparisons.
Introduced in 63280e06fc.
Test: android compiles and boots.
Change-Id: I4d3185e835615ffba3a7854d3d58351e124599d0
ic_qs_wifi_full_x have been replaced by ic_wifi_signal_x in frameworks.
That way they can be overlaid with the whole system. Also,
ic_qs_wifi_disabled was identical to ic_qs_wifi_full_0, so it was
removed.
Test: Visual (using HotDog overlay)
Bug: 121040363
Change-Id: Ia36613e5c0b1f3a0c1eb5c687d795992e8660955
If you have a legacy assist app (launched through ACTION_ASSIST, not
implementing a VoiceInteractionService) then we kept the Google app
as the current speech recognizer. Thus if you force stopped the
Google app, we saw that as one of the active parts of the interactor
or recognizer and reset all of the state.
Now we handle the "only recognizer" case separately, only resettting
the recognizer state in that case.
Bug: 121104681
Test: manual
Change-Id: Icc007bdf2352548d58be997fae77d9e5aba842f3
I noticed that the real ACTION_BATTERY_CHANGED races against the mocked
calls to update power state and cycle through idle states. This actually
works on a high-end phone or an emulator because the sticky broadcast
goes through before the test finishes setting up.
But on a slower device we sometimes beat the broadcast queue and wind up
getting our state reset halfway through the test. Flaky tests are bad so
let's not listen to broadcasts at all in the test.
May address issue 118639768 [DeviceIdleControllerTest is flaky].
Bug: 110756616
Bug: 118639768
Test: atest com.android.server.DeviceIdleControllerTest
Change-Id: Ie03ed10f2781ccaba4f39f4f34673a3e073e9f7f
API Review request to use ViewGroup here as Scene roots can only be ViewGroup
Bug: 120504681
Test: none
Change in AndroidX: aosp/841919
Change-Id: I6fb857bc68d2afca54fe7d366fe8490d03c947a9
