| Age | Commit message (Collapse) | Author |
|---|
|
Test: compile
Bug: 26552300
Bug: 31289077
Change-Id: I578b15b48f0fc2807a92abbc69a377c3d2191496
|
|
Change-Id: Ic66abfb547cd5551c47e03d604e65f83c84c597f
|
|
We now peform a total-size preflight pass before committing data to the
wire. This is to eliminate the large superfluous network traffic that
would otherwise happen if the transport enforces internal quotas: we
now instead ask the transport up front whether it's prepared to accept
a given payload size for the package.
From the app's perspective this preflight operation is indistinguishable
from a full-data backup pass. If the app has provided its own full-data
handling in a subclassed backup agent, their usual file-providing code
path will be executed. However, the files named for backup during this
pass are not opened and read; just measured for their total size. As
far as component lifecycles, this measurement pass is simply another
call to the agent, immediately after it is bound, with identical
timeout semantics to the existing full-data backup invocation.
Once the app's file set has been measured the preflight operation
invokes a new method on BackupTransport, called checkFullBackupSize().
This method is called after performFullBackup() (which applies any
overall whitelist/blacklist policy) but before any data is delivered
to the transport via sendBackupData(). The return code from
checkFullBackupSize() is similar to the other transport methods:
TRANSPORT_OK to permit the full backup to proceed; or
TRANSPORT_REJECT_PACKAGE to indicate that the requested payload is
unacceptable; or TRANSPORT_ERROR to report a more serious overall
transport-level problem that prevents a full-data backup operation
from occurring right now.
The estimated payload currently does not include the size of the
source-package metadata (technically, the manifest entry in its
archive payload) or the size of any widget metadata associated with
the package's install. In practice this means the preflighted size
underestimates by 3 to 5 KB. In addition, the preflight API currently
cannot distinguish between payload sizes larger than 2 gigabytes;
any payload estimate larger than that is passed as Integer.MAX_VALUE
to the checkFullBackupSize() query.
Bug 19846750
Change-Id: I44498201e2d4b07482dcb3ca8fa6935dddc467ca
|
|
(cherry picked from commit 5baa164aec06a9973a68303bc7752aa76e5c68e5)
Change-Id: Ifa9a157346edd479ce03982baf435ab213dc2e79
|
|
* commit '9568307cf32c8abc6703dc7a1b0b0fee56c4f8f5':
Fix redundant file backups
|
|
We'd observed a bug in which an unchanged file was nevertheless
being redundantly transmitted for backup on every backup pass.
The underlying issue turns out to have been the FileBackupHelper
base implementation's logic for diffing the prior-state file
set against the current state, in the case when there had been
deletions of prior files. In addition, there was also a
parallel bug in which file checksums were not calculated
properly in some cases, leading to at least one additional
redundant backup of the file in question.
Bug 18694053
Change-Id: Ie0dec06486b5fef4624561737019569c85d6b2a0
|
|
One less hack needed...
Bug: 18298106
Change-Id: I1e9e5ebf329bd6cbaf3445201f182793ee4871ce
|
|
Exposed by switching the target to Clang, and GCC 4.9 used by
MIPS.
Change-Id: Icb79285ab2306c39c2d381e53ea2e643ee2d2947
|
|
Turn on -Wall -Werror in libs/androidfw. Fix warnings. Refactor
some code.
Change-Id: I66fe54ace433c15dee5de328b149ca142f74b2dd
|
|
Changes in this patch include
[x] Use %zu for size_t, %zd for ssize_t
[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)
Change-Id: Id1aaa7894a7d0b85ac7ecd7b2bfd8cc40374261f
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
|
|
- uid_t/gid_t cast to unsigned long
- unused argument warnings
- tab and space requirements
Change-Id: Ib446d8165b9082be02edb55e6b71fd1a03ea3431
|
|
Change-Id: I74532a4e0400033f5ee3e3f6827ac42f77d16f53
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
|
|
OBB backup/ restore is no longer handled within the target app
process. This is done to avoid having to require that OBB-using
apps have full read/write permission for external storage.
The new OBB backup service is a new component running in the
same app as the already-existing shared storage backup agent.
The backup infrastructure delegates backup/restore of apps'
OBB contents to this component (because the system process
may not itself read/write external storage).
From the command line, OBB backup is enabled by using new
-obb / -noobb flags with adb backup. The default is noobb.
Finally, a couple of nit fixes:
- buffer-size mismatch between the writer and reader of chunked
file data has been corrected; now the reading side won't be
issuing an extra pipe read per chunk.
- bu now explicitly closes the transport socket fd after
adopting it. This was benign but triggered a logged
warning about leaked fds.
(Cherrypicked)
Change-Id: I471f6348abcccb7bf1e1710b7beda9f23de53e14
|
|
delete --> free
Change-Id: Idbf7e677f8cc4a9a9d04e58b5cf7d0f1589c5211
|
|
create the new libandroidfw from parts of libui and libutils
Change-Id: I1584995616fff5d527a2aba63921b682a6194d58
|
