for better performance. Without the optimization, these two functions
may check more than 100k file names in the pre-installed APK files,
which can take a few seconds to finish even on a recent device.
Bug: 21957428
Change-Id: I315fd3c6d5aa1076b993752525de449a9933de12
getEntryInfo crashes on 64-bit devices because "long" types
were being passed int pointers (that pointed to a stack frame)
that were reinterpret_cast'ed to long* (sigh.). To fix this issue
once and for all, use types with explicitly defined widths.
This change also removes some dead invariant checking from
Asset.cpp instead of cleaning it up.
Note that we've introduced a wart in NativeLibraryHelper, where
we need to deal with zlib's uLong type, which is "at least 32 bits
wide".
bug: 21622286
Change-Id: Iae675a9601db7aae03a8b80b40321d2cc1d97f50
The round qualifier denotes a device with a screen shape that
is round. The qualifier shows up after the 'long/notlong' qualifier
and before the orientation 'port/land/square' qualifiers.
Change-Id: I3044258b2703a9165694b79725bade770fa6cea1
I've inspected all other callers of OpenArchive and this seems
to be the only broken one. The easiest way to reproduce this is
by using getPackageArchiveInfo or by adding an asset path that
isn't a valid APK.
bug: https://code.google.com/p/android/issues/detail?id=171099
Change-Id: I41cd85d20f26ad47968e2a6f1384cc03330b558b
Themes now use an array of applied styles rather than a String to store
their history. They are keyed based on a hash code computed from the
history of applied styles. The themed drawable cache has been abstracted
out into its own class.
Also updates system context to use DayNight as the default and ensures
that GlobalActions uses the correct context, which exercises the change.
CTS tests have been added in another CL.
Bug: 20421157
Change-Id: I9eb4b7dffd198ad24d02f656eaf0839570b59caa
Required to know when to reload the system context's theme in response
to configuration changes, and thus needed to support the DayNight theme.
Bug: 20267825
Change-Id: I7df5e28b7a6d8b611ea030032544cf4800788514
Was here because UBsan found integer overflow in the parsing for hex
numbers, since hex numbers here are actually unsigned but assigned to
a signed integer.
Also fixes a number of missing error conditions.
Change-Id: Iaea576daedfc6c75521cde02de3fe9dd0198a3b7
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