When we were fading out the preview for phone/camera to crossfade to
the real application, it might have been that showKeyguard was
called in the middle of this transition. This change makes sure that
we cancel this animation when showing the keyguard.
Bug: 17439581
Change-Id: I89cacf7ecf43d37ea979418b976390272510a09d
The bootanimation daemon will play 16 bit WAV files contained in bootanimation.zip
For this to work, the bootanimation.zip must contain an audio_conf.txt file,
which contains parameters to be used for the tinyalsa pcm_open call
as well as mixer parameters to set before attempting to play the sound.
If the bootanimation finds an audio_conf.txt file, then it will look for a file named
"audio.wav" in each of the part subdirectories. If audio.wav is found, it will play that
WAV file starting at the beginning of that part.
The code for this is based on the tinyplay utility in tinyalsa.
The audio_conf.txt and must begin with the following header:
card=<ALSA card number>
device=<ALSA device number>
period_size=<period size>
period_count=<period count>
This header is followed by zero or more mixer settings, each with the format:
mixer "<name>" = <value list>
Since mixer names can contain spaces, the name must be enclosed in double quotes.
The values in the value list can be integers, booleans (represented by 0 or 1)
or strings for enum values.
Finally I should mention that this change is not the right approach.
Instead of going straight to ALSA we should be using the mediaserver instead.
But mediaserver isn't ready in time due to interactions with the system server, and there
isn't time to fix this for the current release. We need to fix that for the next one.
Bug: 17674304
Change-Id: Ic391ade61c941d0a24f4d64fe005ac9375a23fa9
We've been seeing some really funky behavior when upgrading or
downgrading system apps around OTA time. Put more of these one-time
logs into durable storage to help investigate.
Bug: 17805839
Change-Id: If898d7df229c1f71e598b0d965325c272060e5e7
Bug: 17765082
DeferredLayerUpdater had fallen behind RT updates. Re-snap to
latest expectations, ensuring to call requireGlContext() prior
to detachSurfaceTexture to avoid leaking SurfaceTextures
Change-Id: Ic65fb9831e5284f658866da8da9ad5af1d227699
If the creation of an Activity fails, it is impossible to determine what
went wrong. We should log the exception immediately before failing on assert.
Change-Id: Ie6cbe87ff342b8d60989f5e1a6ffa3efc058c585
This reverts commit 851a5059a47cbf76e530c9d050a677cb6e3f8657 as
it creates a regression. Let us revert this and correctly fix the
issue the original change was trying to address.
bug:17789608
Change-Id: I8abb1a61d5310430e839e4ef60e7ca5cc0cbdd80
Found a very simple fix. Just set the cached metadata so we have
it to copy over when editMetadata(false) is called.
bug:17796693
Change-Id: Ib27f0c3d28e7f2a3c7d9495697f36c8045e2bcf6
We also refine the order of delivery within any given package. Now,
we identify which apps have wakeup alarms being delivered in the
current pass, and deliver all of that app's alarms before moving
on to alarm delivery to apps who are only receiving non-wakeup alarms
in the current delivery pass. The TIME_TICK alarm is also hoisted to
the start of the current delivery pass if present.
Bug 17778686
Change-Id: I6306a00fe657787a77d0254c0807ac51e810fdcf
Currently, Mockito tests don't run on ART (KitKat & L) due to an extra
NoClassDefFoundError exception being thrown while trying to resolve
internal test runner classes. These exceptions are benign, Mockito's
internal test runners all inherit from org.junit.runner.Runner, which is
not included in the setup, but none of them are actually used in tests.
The same apks succeed on Dalvik, and logcat shows the same exceptions
going by, minus the NCDFE's.
Section 5.3 of the VM spec says the virtual machine has to wrap a
ClassNotFoundException in NoClassDefFoundError if the first exception
arises from verification or resolution but not initialization of that
particular class.
Bug: 17042833
Change-Id: I3af20f6884d9fa3afc3fbf9fcb238be10267827a
The HTTP proxy system properties are set based on the proxy configured
for the network the captive portal login app is operating on. These
system properties are subsequently read by the WebView used to perform
the sign-in.
This is a short-term fix using reflection. This allows users with
cellular providers that use proxies to sign into WiFi captive portals.
The long-term fix could involve:
1. Sending out a network-specific proxy config changed broadcast, and
2. Modifying the ActivityThread to set proxy system properties for
Networks selected with setProcessDefaultNetwork(), and
3. Modifying WebView to read from the proxy system properties when
PROXY_CHANGE_ACTION broadcasts are received.
bug:17679789
Change-Id: I3ada0470ad085df1a4452b4a655ac35f310d2241
