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
This will enable the developers to check if they could replace an unbuffered
I/O operation with a corresponding buffered I/O operation.
The policy can be set as follow:
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
.detectUnbufferedIO().build());
Test: vogar BlockGuardTest
Bug: 3018772
Change-Id: Ib804a8e9980ae40abfd216f8b87c250fd413bd5c
(cherry picked from commit 9b7184a8fd)w
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
