If we created a BROWSE PendingIntent early during boot (while the
device was still locked), we would resolve the MIME type as "null"
meaning the intent would fail to launch.
Since we always know what the MIME type will be, set it explicitly.
Test: boot device while USB device attached
Bug: 30742481
Change-Id: I23c523cbe2660ca63a3b7df1f41300ab803b314c
Also fixes progress bar sample tile to reflect density and ensures
that ProgressBar.tileify() clones inner drawables into the correct
density.
Bug: 31841123
Test: BitmapDrawableTest#testPreloadDensity()
Test: ThemeHostTest
Test: Visual inspection of ApiDemos
Change-Id: I9dcb9817d8d91d61ff0215987247e9e7fb089c46
MessagingStyle expects the field userReplyName to be non-null, but the
documentation doesn't describe it as such. This updates the documentation
to say the field is required, and adds a NonNull annotation.
This has no behavior changes.
BUG:31747744
Change-Id: If832d059c276e856fba366dabfa8a5821bb63054
This patch adds an explicit check in the DHCP packet parser for
rejecting packets without a magic cookie, instead of relying on the
top-level try-catch-all in the parser.
This allows to add to DHCP error metrics this specific error.
It also allows to add two poor man's fuzzing tests that tries to find
additional gaps in the DHCP packet parser by
- trying to parse all subslices of a valid offer packet.
- trying to parse random byte arrays.
Test: covered by previously introduced malformed DHCP packet unit tests
+ additional fuzzing tests.
Bug: 31850211
Change-Id: If53c9ba9df78d7604ec018c9d67c237ae59c4833
When we dismiss the dialog as opposed to hide it, it is removed
from the local WindowManagerGlobal's list of ViewRoots. Thus it stops
receiving configuration changes. When first adding a ViewRoot it will
pull the configuration from the context, but in this case
we are reusing one which has already been added and removed
and no such action will occur.
Bug: 31004614
Change-Id: Ie247bcf1a14caf4a42413c6813e337aa4c88e3e4
This patch adds a try catch all to DHCP packet parsing so that
DhcpClient does not choke on malformed packets, brinding down with it
the whole framework.
Test: added new unit tests catching the issue fixed in this patch.
Bug: 31850211
Change-Id: I3c50a149fed6b2cbc4f40bb4f0e5bb2b56859b44
The limit is MAX_WAKELOCKS_PER_UID+1, since OverflowArrayMap
will add one more to contain the overflow.
Change-Id: I53004582daa0c405427308816728f2c1d2bef40d
The USB data transfer is disabled we should not allow access MTP devices
(e.g.
usb sticks). We have two ways of accessing them: Either by mounting them
or by creating a MTPDevice in an app.
Of course an app could implement implement their own MTPDevice
implementation. In this case we cannot enforce the policy without
completely suppressing all MTP USB devices which would be too
restrictive.
Note: When the policy is set we do _not_ disconnect already connected
MTP devices
Fixes: 31472955
Change-Id: I6080c48c49657102774b2b3b4d89ff030245a266
We call uncrypt services to setup / clear bootloader control block (BCB)
for scheduling tasks under recovery (applying OTAs, performing FDR).
However, we cannot start multiple requests simultaneously. Because they
all use the same socket (/dev/socket/uncrypt) for communication and init
deletes the socket on service exits.
This CL fixes the issue by a) adding synchronized blocks for the service
requests; b) checking the availability of the socket before initiating a
new one.
Note that adding synchronized blocks to RecoverySystem doesn't help,
because the calls could be made from different processes (e.g. priv-app,
system_server).
Bug: 31526152
Test: FDR works while a priv-app keeps calling clear BCB.
Change-Id: I95308989e849a9c98a9503ac509f2bc51ed3de19
(cherry picked from commit 794c8b0b3f)
