Fix a bug where the DisplayMetrics wouldn't be updated for a Resources
object on the default display. Since multi-window, we want to update
all Resources.
This didn't always manifest itself due to recreation of assets, which
would force an update of DisplayMetrics. Re-use of an AssetManager from
the cache would expose the bug.
Bug:32133693
Bug:31998629
Test: cts-tradefed run cts --module CtsServicesHostTestCases
Change-Id: Ic51ab82710517b87eb995ccf982085dba876ad58
Ignore every filesystem entity that is not a regular file or directory.
In particular, we now ignore not only symlinks but also sockets, pipes,
et cetera.
Bug 32143362
Change-Id: If51b54df1f7a643af145eb15bf12d389d19f8780
The copy constructor of Notification.Action.Builder did not copy
the mAllowGeneratedReplies field.
Change-Id: I40fbe8950ee2232e2589ab3930a32bfbebe9fc89
Fixes: 31766718
Test: runtest --path $T/cts/tests/app/src/android/app/cts/NotificationTest.java
The admin can instead use the value of 0 to reset to default.
Test: runtest --path frameworks/base/services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerTest.java
Bug: 31430135
Change-Id: I0d6b29ca4eca65d7ca72a8975a0c28c9050a946c
(cherry picked from commit 943aabd11c)
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 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)
Log the error code to uncrypt_status if uncrypt gets killed because
of timeout.
Test: We log the error code correctly in uncrypt_status when uncrypt timeouts.
Bug: 31603820
Change-Id: Ia623c333714295e68f4269257fbb4297a867e42b
(cherry picked from commit 036d08638e)
The static initializer for a pre-loaded framework class is run
no later than at zygote startup, which happens at device boot.
Which means that if the timezone later changes, DngCreator will use
an incorrect cached timezone until the next reboot. This is especially
evident in freshly wiped devices, where initial setup will typically
change the timezone.
Instead, read the timezone each time DngCreator is created, which is
also when we query the current time for constructing the timestamps.
Test: android.hardware.camera2.cts.DngCreatorTest#testSingleImageThumbnail
Bug: 31743060
Change-Id: I83a4eac762650e5f904f3b8fa779c094cef30562
This patch defines new Settings symbols for
- setting the probe urls for captive portal detection.
- setting which User-Agent to use for captive portal detection.
The existing default values for these settings are not changed, i.e:
- HTTP and HTTPS probes urls are unchanged.
- the fallback probe is not used.
- User-Agent is empty by default.
Bug: 29367974
Change-Id: I6e4b3b172e56b8b67fffa4b51f776d68d5851f25
This patch adds the possitibility to send a 3rd fallback validation
probe in sendParallelHttpProbes when neither the 1st http probe nor the
https probe came back with a conclusive answer.
This 3rd probe is only used for trying again captive portal detection
and does not return success, so that network validation always fails if
the https probe fails.
In addition, the url reveals a captive portal is now sent to the
CaptivePortalLoginActivity so that all three probes can use different
urls.
Bug: 29367974
Change-Id: I7385fde1aa1316d94aac350af0e956cb193aa4ee
All that this member variable is doing right now is leaking a
reference to a context without any benefit.
Bug: 31752040
Bug: 31710795
Change-Id: If2241422533318b866340e8dcc9f5fbd9518349c
The NanoApp.java class has a bug (b/30808791) where the API treats
app IDs as 32-bits, instead of 64-bits. We are too late in the
Android N release cycle to change this API.
We previously put in a hack to fix this only for Google nanoapps.
However, our GTS nanoapps need this to work, and there are other
partners who need this to work in the N timeframe. So we make
a more robust hack which parses the full 64-bit app ID out of
the header binary.
Test: Compiles and runs GTS
Bug: 31767599
Change-Id: Ic43f1f62c685fb99aac08d08767d1a67c329503f
