| cc76991f37268eed1ef2c978720b32f0c103dc70 |
|
17-Jan-2017 |
Tao Bao <tbao@google.com> |
Revert "RecoverySystem: Fix the issue in installPackage()."
This reverts commit 9f7a0acd2d383b825bcdcbef25d6b42f9875acfe.
Bug: 34350643
Bug: 34396955
Test: installPackage() doesn't cause deadlock if it doesn't call
processPackage() prior to that.
Change-Id: I1da055c86a3326ae341da1b4d5dc79ab4be256fb
/frameworks/base/services/core/java/com/android/server/RecoverySystemService.java
|
| 9f7a0acd2d383b825bcdcbef25d6b42f9875acfe |
|
13-Jan-2017 |
Tao Bao <tbao@google.com> |
RecoverySystem: Fix the issue in installPackage().
Commit 794c8b0b3fe16051843c22232d58d6b184dde49b fixed the race condition
when requesting data wipes via uncrypt. We have similar issue with
RecoverySystem.installPackage(). It first requests to set up the BCB,
then triggers a reboot. These two steps should finish atomically.
This CL switches to calling
RecoverySystemService.rebootRecoveryWithCommand(), which guards the two
steps with synchronized blocks.
Bug: 34239871
Test: Having two apps: one calls RecoverySystem.cancelScheduledUpdate()
continuously, and the other calls RecoverySystem.installPackage()
just once. The install request should not be cancelled by the
other.
Change-Id: I5ec56fcaa70eae7c33e3cc8e6cfc7472b935ce4e
/frameworks/base/services/core/java/com/android/server/RecoverySystemService.java
|
| 794c8b0b3fe16051843c22232d58d6b184dde49b |
|
27-Sep-2016 |
Tao Bao <tbao@google.com> |
Handle the race condition when calling uncrypt services.
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
/frameworks/base/services/core/java/com/android/server/RecoverySystemService.java
|
| 1284482898712e994d28203d71655f3254b0d4d5 |
|
22-Mar-2016 |
Tao Bao <tbao@google.com> |
RecoverySystemService: Dump exception stack on IOExceptions.
We occasionally hit "java.io.IOException: Connection reset by peer" when
communicating with uncrypt. Change to print verbose exception stack for
future debugging.
Also conservatively change the two potential causes: a) by removing the
call to dos.flush() after sending the last status code; b) by closing
the streams quietly instead.
Bug: 27782920
Change-Id: Ice6da1f27cb1ee83207c9f34958c0e012270167e
/frameworks/base/services/core/java/com/android/server/RecoverySystemService.java
|
| dd3baae7ed9d923c8cb8e832853cbaed01528523 |
|
26-Feb-2016 |
Tao Bao <tbao@google.com> |
Switch to socket communication with uncrypt.
RecoverySystemService used to communicate with uncrypt via files (e.g.
/cache/recovery/command and /cache/recovery/uncrypt_status). Since A/B
devices may not have /cache partitions anymore, we switch to communicate
via /dev/socket/uncrypt to allow things like factory reset to keep
working.
Bug: 27176738
Change-Id: I109aa9a9592ca6074eb210089963a846955c0768
/frameworks/base/services/core/java/com/android/server/RecoverySystemService.java
|
| e8a403d57c8ea540f8287cdaee8b90f0cf9626a3 |
|
31-Dec-2015 |
Tao Bao <tbao@google.com> |
Add support for update-on-boot feature.
Add a separate system service RecoverySystemService to handle recovery
related requests (calling uncrypt to de-encrypt the OTA package on the
/data partition, setting up bootloader control block (aka BCB) and etc).
We used to trigger uncrypt in ShutdownThread before rebooting into
recovery. Now we expose new SystemApi (RecoverySystem.processPackage())
to allow the caller (e.g. GmsCore) to call that upfront before
initiating a reboot. This will reduce the reboot time and get rid of the
progress bar ("processing update package"). However, we need to reserve
the functionality in ShutdownThread to optionally call uncrypt if
finding that's still needed.
In order to support the update-on-boot feature, we also add new
SystemApis scheduleUpdateOnBoot() and cancelScheduledUpdate() into
android.os.RecoverySystem. They allow the caller (e.g. GmsCore) to
schedule / cancel an update by setting up the BCB, which will be read by
the bootloader and the recovery image. With the new SystemApis, an
update package can be processed (uncrypt'd) in the background and
scheduled to be installed at the next boot.
Bug: 26830925
Change-Id: Ic606fcf5b31c54ce54f0ab12c1768fef0fa64560
/frameworks/base/services/core/java/com/android/server/RecoverySystemService.java
|