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
Many activities in core were using the
material theme which would result in teal
colors on all devices. These themes have
all been changed to DeviceDefault so that
the color will be more suited to whatever
device the user has.
Test: Manual Inspection
Bug: 31623421
Change-Id: I6847023c4fb57a1c3384a1f8e483cd740229458f
Add the FLAG_RECEIVER_FOREGROUND flag to the broadcast intent
triggered by hardware key.
This prevents the framework from delaying the delivery of the
intent to its recipients, and improves the response for hardware
key event under heavy load on the system.
Bug: 28735973
Change-Id: Ib7f219845be34794f4c7545927e53cc6c2b504a3
