Supports both age and count based constraints. Added light docs and
tests to verify behavior.
Bug: 8387555
Change-Id: If4d0dac8bc54ce705c2a339bc09a60ea748728b8
Modify WifiService to add a controller to track the various
desired states and let the WifiStatemachine actually control
the bring up.
Bug: 8141918
Change-Id: I6e98fd5a29b43c3c50c315eff5255cd0a3eaebcd
When a new IME is attached it is not enough to remove the
WindowManager messages from the local queue, but the ones in
the previous IME queue must also be removed.
Fixes bug 8263462.
Change-Id: I9e916c6052a83dc7691bcba0b6ab8328b9b7cc36
In general, calling requestLayout() during layout is a Bad Idea.
However, ListView does this during the normal course of its layout, as it
removes and adds views during layout. However, it handles this properly,
ensuring that the views in its hierarchy are all measured and laid out
properly by the time its layout process is done.
A previous fix to the request-during-layout issue attempted to distinguish
the correct from incorrect behavior by checking whether views had been properly
laid out since the requestLayout() call, and making sure the views were
visible in the hierarchy (parented, attached, and !GONE), since otherwise
the views would not be laid out, the flags wouldn't be cleared, and requests
are superfluous anyway. However, this logic only checked whether the
requesting views were GONE, whereas the check should include the entire
parent hierarchy of the views (since a view with a GONE parent is still not
visible to the user).
This fix adds that additional check and cleans up other parts of the previous
code, such as not bothering to post() requests that occur during the second
layout pass unless those requests are also valid (coming from visible views).
Issue #8370042 Path seems to be in an infinite layout loop
Change-Id: I7aaf701229adfeee349a9a7c9ec14585735ba9f6
Show notification when a bugreport is finished, letting the user
launch a SEND_MULTIPLE intent to share them. Add dialog that warns
user about contents before sharing. Since bugreports are now stored
in private app data of the Shell app, use FileProvider to build Uris
that we can grant others access to.
Define BUGREPORT_FINISHED as being a protected broadcast. Delete
older bugreports automatically to reclaim disk space. Migrate any
Intent extras to ClipData when building PendingIntents.
Add --receiver-permission support to am shell command.
Bug: 7005318
Change-Id: If6c607dbcf137362d5887eac482ff7391563890f
Fix a few things found in our "Constants" section.
- Close unclosed links.
- Avoid periods inside parens for summary sentences.
- Lowercasing in a few places for consistency.
Change-Id: I9aa689fd980b373614dae7c4f8257e0786d2340a
Fix for failing android.speech.tts.cts.TextToSpeechServiceTest#testSynthesizeToFile.
In test env, ParcelFileDescriptor instance may be EXACTLY the same one that client uses.
And if it's closed by a client, then service is prevented from writing anything to the output.
Bug: 8377754
Change-Id: I7f95aae1b877e543ab02d3c548b29537aa852a89
Add a minimum size for the event pools for devices which don't have sensors.
Otherwise the system server crash loops on boot.
Change-Id: Ic51c6fc26c8779d9f435f358d4274148a2ddbfb3
You can now declare shared libraries in apks that are
on the system image. This is like the existing mechanism
of using raw jar files as shared libraries, but since they
are contained in an apk the library can actually be updated
from the Play Store. And this even (mostly) works.
There are some deliberate limitations on this feature. A
new shared library *must* be declared by an apk on the system
image. Installing an update to a system image apk does not
allow you to add new shared libraries; they must be defined
by everything on the base system image. This allows us to
get rid of a lot of ugly edge cases (shared libraries that were
there disappearing after an update is uninstalled for example)
and give some brakes on apps that happen to be pre-installed
on devices from being able to throw in new shared libraries
after the fact.
In working on this, I ran into a recently introduced bug where
uninstalling updated to system apps would fail. This was done
to allow for the new restricted users that don't have all
system apps, but conflicts with the existing semantics for
uninstalling system apps. To fix this I added a new uninstall
flag that lets you switch on the new mode if desired.
Also to implement the desired logic for limitations on declaring
new shared libraries in app updates, I needed to slightly tweak
the initial boot to keep the Package object for hidden system
packages associated with their PackageSetting, so we can look at
it to determine which shared libraries are allowed. I think
this is probably more right than it was before -- we already
need to parse the package anyway, so we have it, and when you
install an update to a system app we are in this same state
until you reboot anyway.
And having this fixed also allowed me to fix another bug where
we wouldn't grant a new permission to an updated app if its
system image version is updated to request the permission but
its version is still older than whatever is currently installed
as an update. So that's good.
Also add new sample code showing the implementation of an apk
shared library and a client app using it.
Change-Id: I8ccca8f3c3bffd036c5968e22bd7f8a73e69be22
