Fix 5783857: Device Policy Manager doesn't allow Face Unlock
This makes it so that if face unlock is enabled and then a device policy
manager that requires something more secure than face unlock is installed,
the user will be forced to choose a new acceptable lock type.
This was previously fixed for the case where the device had been reset, or
the shell was restarted after setting face unlock, but not for the case where the
device remained on between setting face unlock and setting up a device policy
manager.
Also changed the function ordering of saveLockPattern() so that the overloaded
wrapper function is next to the main function.
Change-Id: Ibed8c4ab137ebbc07fb143faef6f047bc6dc4474
Instead of picking between the music stream and the enforced audio
stream, change the camera service to always play sounds through
enforced system stream. Also update the currently-hidden CameraSound
API to match.
Bug: 5778365
Change-Id: I3cc64b1d1ff567dbac8020a665d5b19846197ff3
The calculation done in prepareTracks_l() for the minimum amount
off frames needed to mix one output buffer had 2 issues:
- the additional sample needed for interpolation was not included
- the fact that the resampler does not acknowledge the frames consumed
immediately after each mixing round but only once all frames requested have been used
was not taken into account.
Thus the number of frames available in track buffer could be considered sufficient although
it was not and the resampler would abort producing a short silence perceived as a click.
Issue 5727099.
Change-Id: I7419847a7474c7d9f9170bedd0a636132262142c
The idea is that this is a device which is more-or-less headless. It
might have some limited interaction capabilities, but it's not something
that you want to rely on having.
Change-Id: Icc9f674299f8dbe2b736a5622a4965904d27e49c
-------------------------------------------------------
MCC detection fixes for CountryDetector
- Don't get and cache phone tpe at the initialization time. At this point
TelephonyManager is probably not ready yet.
- Refresh MCC whenever we get the service state changed callback, even when
the state hasn't actually changed, in order to make sure we get refresh
country properly when MCC changes.
- Also remove the initialization of mPhoneStateListener, which prevented us from
registering phone state listener properly.
- Also fix tests which were already failing.
Bug 5670680
-------------------------------------------------------
Add logging to country detector logic
This is for debugging purposes to verify the effects of
change Id45abeba1b1e843053ac2c946861b439ca568de4.
Bug: 5670680
Change-Id: I238d953484e2c8135f7dac70fce8662c8300a286
We need to work more like before in determining whether the menu
key is needed -- in some cases look back in the window list to
determine this if we don't know the value from the current window.
This requires adding a new private flag indicating whether the
compat menu state is known for a window, which is set by
PhoneWindow as part of its existing process of computing the flag
for its own windows.
Now we can have a new API on WindowState to determine the value
of this flag for a window, which if needed walks back in the window list
to find a window the value is known for (or stops at what the policy
has determined is the top full-screen window, so we stop like we used
to at things like the lock screen or the bottom of an application).
Change-Id: I829de6d629b5af8bcb422cb85249ee4041c7205e
Fixed a problem where the key up for the ALT or META key was not
delivered to the task switcher dialog because it was deemed
to be inconsistent with the window's observed state. Consequently
the dialog would not be dismissed when the key was released.
Moved global hotkey handling for META+* shortcuts and ALT/META-TAB
into the window manager policy's interceptKeyBeforeDispatching
method. This change prevents applications from hijacking these
keys.
The original idea was that these shortcuts would be handled only
if the application did not handle them itself. That way certain
applications, such as remote desktop tools, could deliberately
override some of these less important system shortcuts.
Unfortunately, that does make the behavior inconsistent across
applications. What's more, bugs in the onKeyDown handler of
applications can cause the shortcuts to not work at all, for
no good reason.
Perhaps we can add an opt-in feature later to enable specific
applications to repurpose these keys when it makes sense.
Bug: 5720358
Change-Id: I22bf17606d12dbea6549c60d20763e6608576cf7
* commit '0a361b10a665a3d158c846722290f26ce62276e1':
Workaround for issue where the notifyDatasetChanged call chain is broken when Launcher is killed. (Bug 5703782)
... a different app opens
In some cases when reparenting activities we could end up with a reply
chain that crosses task boundaries, so if an activity below that needs
to be reparented we pull that and the activities above it up into the
new task.
Change-Id: Ia4fa041ab7069e39dac162ddbf5b8e1de98675b9
HDMI audio hotplug is treated as a "headset" in the audio services. When a headset is unplugged,
WiredAccessoryObserver sends an AUDIO_BECOMING_NOISY broadcast so that applications can take
appropriate action (e.g. pausing audio if headphones were unplugged).
However, on Tungsten, when you unplug HDMI audio, the Music2 service was getting the NOISY intent
and pausing the transmitter media player. We could add Tungsten-specific code to Music2 to
disable this behavior, but it's probably better to disable this broadcast entirely because
applications on Tungsten probably shouldn't treat HDMI hotplug in the same way they treat
headphone hotplug on phones.
Change-Id: I2d2b913f74f51fb496bd2f00f32e109bbff01fa1
Make the standby time for AudioFlinger configurable using a system
property. Default AudioFlinger behavior is to go into standby
(allowing the audio outputs to underflow) after there has been nothing
to mix and AudioFlinger has just been pumping out silence for the
configured standby time (which defaulted to 3 seconds).
Now, by setting the "ro.audio.flinger_standbytime_ms" property in
their platform init.rc, platforms can override this default and
control the standby time. If the property is missing or malformed,
the old default value of 3 seconds will be used instead.
Change-Id: Ic9fa8b5f5bccee493bc72c65e408d3fd8ddd1059
Signed-off-by: John Grossman <johngro@google.com>
New API to let you build an Intent whose base configuration is correct,
but has an additional "selector" to pick out the specific app that you
would like launched.
Change-Id: Ide9db6dc60e2844b7696cfe09b28337fe7dd63db
The maximum sleep time allowed in the mixer thread when audio tracks
are enabled but not ready for mixing is derived from the latency
reported by the output stream.
This does not work for A2DP where the latency also reflects encoding, decoding
and transfer time.
Modified activeSleepTimeUs() to take A2DP case into account.
Issue 5682206.
Change-Id: I3784ac01fb6f836b5a6ce6f764fb15347586de35
Layer::lockPageFlip() and layer::onRemove() could be called on
different threads and race such that lockPageFlip() successfully
called mSurfaceTexture->updateTexImage() but then gets NULL back from
mSurfaceTexture->getCurrentBuffer(), leading to a crash.
This change moves Layer::onRemove() calls to
SurfaceFlinger::commitTransaction() so they happen after the Layer is
done being drawn from and only happen on the main surfaceflinger
thread.
Change-Id: I4b550caadff4cc1878d7c3bca6129193fb0c713e
