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
We expect to be able to parse the output of ResTable_config::toString(),
so it should use modified bcp47 (b+en+Latn+US).
Change-Id: I597a1779a1fa5cff171c473e6a0368d93b9c7722
Rejects any non null-terminated string that a caller asks
ResStringPool::stringAt for, returning NULL instead.
The rationale for returning NULL rather than amending the string to add
a null-terminator is that conformant APK files will have all their
strings null-terminated anyway, and that this is a possible signal of a
malformed package.
Bug: 15288069
Change-Id: I370937b92f2cadf67fbd54203cbc7d1494be969f
Adds checks to 2 malloc() calls to ensure that the finally allocated
buffer size is not vulnerable to integer overflows. Also includes a
sanity check on the upper bound for type_info.numEntries before each
call.
Bug: 15171384
Change-Id: Ifdf0276bcca7e3d93da7c3577b9486d3c03a9d03
The base APK may have resources with configurations that compete
against some splits. The base APK must be involved in the selection
of splits.
Bug:18982001
Change-Id: Ieb29b5a36cf2c68e7831484d98a9fd275acd97e8
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
A sentinal value of 0x00000000 was used to mark the first time an AttributeFinder
was used. If the resource ID of an attribute was also 0x00000000 (which occurs with
non-resource attributes, like 'style'), then it would be mistaken as the sentinel
start value.
Bug:18421787
Change-Id: I4be353e0f8c940cb6f262d155129f048dcc444ae
Private attributes are typically placed after public
attributes in the resource table. Each time a new version
of the Android framework is released, new public attributes
take the place of the private attributes, and the private
attributes are shifted after the new public ones.
This means that any apps built against the newer SDK
may inadvertently be using private attributes on older
devices.
This change moves all private attributes to a completely
different type ID, so there will never be collisions across
versions.
These private attributes are automatically moved to a synthesized
type only for the system resources.
Bug:18263655
Change-Id: I7a850512953fadcc9f3524d509cea30249782db8
System overlays, ie overlays with targetPackage="android", were loaded
twice, which caused all sorts of issues. Ensure they are only loaded
once, which will be during Zygote initialization.
Bug: 17765434
Change-Id: Ia5064045c77f713c58fb78adc3942f6af1abdc93
In the new idmap format (version 0x1), 0x00000000 no longer represents a
non-existing entry: 0xffffffff should be used instead.
Bug: 17765434
Change-Id: If2c7e09feba2224eeafe88fd9230e6392d81b9a7
With the recent introduction of AssetManager::appendPathToResTable,
overlay packages were not properly added to the AssetManager, and once
added, were not properly inserted into the ResTable.
Bug: 17765434
Change-Id: Ie21f227c654c98730f74a687d0e16ee2b80e747e
