It turns out this was not a problem in the resource code at all. Rather,
the system process has a cache of pre-loaded attributes it uses to avoid
continually reloading things as it needs them. Well it turns out this
cache wasn't flushed after a package was uninstalled or a configuration
changed, so you could re-install an app where you change its style resources
so its theme now points to one that is inconsistent in the cache.
This is mostly a problem for developers, where they continually install
new versions of an app where resources have changed. This could possibly
show up when updating an app on a normal phone, although the problem would
eventually correct itself since this cache uses weak references.
Anyway, the cache is now reworked to be flushed appropriately.
This change also includes an update to aapt to be able to dump the
contents of bags in resources.
* changes:
Better (and less) logging from backup.
Add an extra null terminator. String8::unlockBuffer is supposed to be doing this, but it's not and I can't figure out why. This makes BackupHelperDispatcher able to read the keys correctly.
Applications can now declare that they support small, normal, or
large screens. Resource selection can also be done based on these
sizes. By default, pre-Donut apps are false for small and large,
and Donut or later apps are assumed to support all sizes. In either
case they can use <supports-screens> in their manifest to declare
what they actually support.
This allows the camera service to hang onto the callback interface
until all callbacks have been processed. This prevents problems
where pending callbacks in binder worker threads are processed
after the Java camera object and its associated native resources
have been released.
Bug 1884362
This change adds a fixed-size metadata block at the head of each file's content
entity. The block is versioned, and fixed-size on the theory that it might be
nice to be able to recover the content (if not the full metadata) of the files
if we're ever confronted with data backed up some hypothetical future helper
that stored expanded metadata.
The net effect is that now on restore, we assign the same access mode to the
file that it originally had when backed up.
Also, some of the code was failing to properly free transient heap-based buffers
when it encountered errors. This has been fixed with the addition of a tiny
stack-based object whose job it is to free() its designated pointer from its
destructor.
This change puts the file's access mode into the saved-state blob used by the
file backup helpers. The tests have been updated for the new blob content
format.
What this change *doesn't* do is actually backup/restore the file mode. This
change is a prerequisite for that, but mode preservation in backup/restore will
require adding metadata to the backup data stream itself, so will be approached
a bit more carefully.
(Also fixed one outright bug in the test program: ReadEntityData() had been
changed to return a ssize_t union of either a byte-count or a negative number
indicating error, but the test program was still assuming that nonzero == error,
and was spuriously failing.)
The aapt tool now reports all available densities like it already did
for locales. Also this includes more resource data output, which I
was using to examine bug #1867049 (which at this point I am unable to
reproduce).
ro.sf.lcd_density is usually defined in the build.prop file which is parsed by init
before anything else. Since its name begins with "ro.", this property is write-once
and cannot later be modified, e.g. in /system/etc/init.goldfish.sh.
In other words, you cannot use "emulator -prop ro.sf.lcd_density=<value>", since
it is impossible to override the value defined in build.prop
This patch modifies the system to recognize "qemu.sf.lcd_density" as an override
value, which can be set with "emulator -prop qemu.sf.lcd_density=<value>", forcing
a specific density.
A later patch will allow the emulator to automatically set this property depending
on AVD hardware configuration settings.
The problem comes from the code handling the automatic change of audio routing to speaker when notifications are played. The music is also muted while the sound is forced to speaker.
To avoid truncating the end of the notification, a delay is inserted between the end of the notification and the restoration of the audio routing. If a new notification starts during this delay, the current music mute state read and saved before muting music corresponds to the forced mute due to previous notification. When the new notification ends, the mute state restored is muted and music stream stays muted for ever.
The fix consists in reading and saving music mute state only if the audio routing has been restored (check that mForcedRoute is back to 0).
- return "const" objects for overloaded operators to disallow constructs like: (a+b) = c;
- don't return references to non-static members, it's not always safe.
- Point.cpp was empty, so get rid of it
This change is the first part of a fix for issue 1846343, :
- Added new enum values for input sources in AudioRecord and MediaRecorder for voice uplink, downlink and uplink+downlink sources.
- renamed streamType to inputSource in all native functions handling audio record.
A second change is required in opencore author driver and android audio input to completely fix the issue.
Added missing include sys/time.h for utimes.
Detects when stat64 uses a timespec for the modif and access times
and work around the missing st_*time_nsec.
Apologies for the whitespace changes, emacs removed them automatically.
There was a serious problem in the Bundle(Parcel) and readFromParcel() methods,
where it wasn't doing the copying of the Parcel that Parcel.readBundle() does
and is a basic requirement for it to work correctly.
This re-arranges the code to make all of these functions (hopefully) correct.
Also fix a problem in Parcel where we were not duping fds when copying data from
one Parcel to another.
