attachViewToParent is generally used for finishing a temporary detach
of a view as seen in ListView, etc. Have it dispatch aggregated
visibility to the newly added view so as to correctly update the view
as to its new state.
Bug 27702014
Change-Id: Ie8a67c78d3edf401641d52ce10bddf7cb49796fe
* changes:
Add more @NonNull/@Nullable to TextServicesSettings.
Remove an unnecessary int to String conversion.
Add more @NonNull/@Nullable to InputMethodSettings.
This is a safe refactoring to remove an unnecessary int to String
conversion in TextServicesSettings.
Settings.Secure.SELECTED_SPELL_CHECKER_SUBTYPE is a integer value that
indicates subtype ID (or SpellCheckerSubtype#hashCode() if the subtype
ID is not specified), and we can just rely on
Settings.Secure#putIntForUser() rather than converting int to String
by ourselves then pass it to Settings.Secure#putStringForUser().
Note that this change is still OK for existing users because
Settings.Secure#putIntForUser() has been internally doing exactly the
same thing.
Bug: 27687531
Change-Id: Ibcf12746f1295c12bec095300ea7f6ced0a51d09
It's easy for apps to throw custom Parcelables into Bundles, but
if the system tries peeking inside one of these Bundles, it triggers
a BadParcelableException. If that Bundle was passed away from the
Binder thread that delivered it into the system, we end up with a
nasty runtime restart.
This change mitigates this trouble by "defusing" any Bundles parsed by
the system server. That is, if it encounters BadParcelableException
while unpacking a Bundle, it logs and delivers an empty Bundle as
the result.
Simultaneously, to help catch the system process sticking its
fingers into Bundles that are destined for other processes, a Bundle
now tracks if it's "defusable." For example, any Intents delivered
through ActivityThread are marked as being defusable, since they've
arrived at their final destination. Any other Bundles are considered
to be "in transit" and we log if the system tries unparceling them.
Merges several Parcel boolean fields into a flags int. Add better
docs to several classes.
Bug: 27581063
Change-Id: I28cf3e7439503b5dc9a429bafae5eb48f21f0d93
Change the args for onVisibilityAggregated to a single boolean for
visibility to the user. Also fix an ordering bug that could trigger a
view background drawable call to setVisible before the view would
respond true to verifyDrawable, which caused issues with some apps.
Bug 27461617
Bug 27689884
Change-Id: I58bdc7c4364264f7fa0863689ba2b76df904ef81
There's a common misconception (even across the framework) that
View#onVisibilityChanged determines and reports visibility on 'this'
up to the changed view and the total visibility within the
window. Knowing this is useful for things like starting/stopping
animations. onVisibilityChanged only reports the visibility for the
specific changed view, not the effects that would have down the tree.
Add onVisibilityAggregated to report what some code thought it was
getting already, and move ImageView and ProgressBar over to using it.
Bug 27461617
Change-Id: I433f41de453e27a53f907f1d9805350f30f31de9
Hides the wallpaper when it's not needed and fixes
the unlock animation to not unnecessairly show the
wallpaper if neither the Keyguard nor the underlying
app need it.
Also fixes a bug where the enter animation had a background
set, which led to uglyness when no wallpaper is involved.
Bug: 27533740
Change-Id: I667c6f7ca6c0e1ff7e9f793c6ddc13f6da8387b1
FLAG_LAYOUT_NO_LIMITS allows a window to extend its dimensions outside
the screen area by setting the display frame to a really big value.
We don't want this in multi-window mode since all window frames should
be limited to their parent task/stack dimensions.
Bug: 27577275
Change-Id: Ie0a8b8c13de91561e06dadc27aac3a5ba209d05b
Update behaviour of the method to actually return real size of the
display independent of current configuration.
Bug: 27548818
Bug: 26986895
Change-Id: I64ba65f305801d97d30aed1c9a6cf6881c94ceda
Previously we were using native config flags in some places that expected
Java flags, and vice-versa. All usages of config flags are now annotated
to ensure we're using the right type.
Cleans up annotations on most methods that were touched.
Bug: 21161798
Change-Id: Ifd87dfb12199fc8258915d8a510e03ddb681ca89
Since DRAG_END is now being delivered only to views that
returned true from DRAG_STARTED, make sure to clear
mCurrentDragStartEvent when returning false from DRAG_STARTED,
to avoid incorrectly sending DRAG_STARTED events to children
views on visibility changes.
Bug: 27595763
Change-Id: Ic18628b48b474351e2433e871bf545657a6ebf52
Adds tap affordance that moves all tasks of the docked
stack into the fullscreen stack as well as moves the top task
of the fullscreen stack into the docked stack.
Also make sure not to trigger focus switch when tapping the divider
handle. For that, add a method so SysUI can specify the touchable
region which then gets excludes for the focus switch touch region.
Bug: 27358134
Change-Id: I34f39c53cacc0b9c00f87a792b88c3f64a5f61e1
* Clarify Javadocs for add / remove when called with the same
Drawable.
* Add @NonNull annotation to all add / remove APIs and throw
IllegalArgumentException when null value is passed.
Bug: 27528798
Change-Id: Ied8f28c70775309e4fa85aff6a7202c1a0eb6aa3
This is a preparation CL to make TextServicesManagerService (TSMS)
encryption-aware.
This CL changes nothing except for the output of TSMS#dump().
To diagnose File-Based Encryption (FBE) related issues, it would be
useful if we can see if each spell checker service is encryption-aware
or not. To do that this CL updates TSMS#dump() so that it can include
the result of ResolveInfo#dump() as we have done in
InputMethodManagerService.
This CL also updates TSMS#dump() so that its output can be more
consistent with IMMS#dump().
Bug: 27456430
Change-Id: Ie2321278f1d52533a3cd74d98f1f84c950a8f6d0
Added a partial screenshot function in TakeScreenshotService
also added corresponding shortcut keys in PhoneWindowManager
Bug: 26820467
Change-Id: Id67cd3b4b0eed848eb4665056766546500bdac88
(cherry picked from commit 03e45541e9d54a2f285906ac7b5bcb374db14495)
* changes:
Removed the group expand button
Removed the bundle number from the header
Fixed a crash with notification children
Fixed a bug where the media header wasn't indented
Fixed fading and dozemode for custom notifications
Fixed a group bug with a single expanded child
Fixed a bug where the top child notification wasn't expandable
Fixed a bug where heads up where not expandable by touch
Fixed a bug where the wallpaper was shining through the background
It is possible for an activity to be in the stopped state without
setting it's visiblility to false in window manager.
For example, the home acitivty behind the lock screen. Since the
lock screen isn't an activity it doesn't affect the visiblity set
of the home activity, so AM doesn't tell WM to hide the app token.
However, AM uses another channel to detect that the device is locked
and moves the activity into stopped state. WM on the other hand also
detects that the device is locked and hides the window surfaces of
all windows behind the lock screen. So, at this point AM has also
told WM that the activity is stopped. Once you unlock the screen
AM resumes the activity but doesn't report any visiblility changes to WM
since it's internal state didn't change. So, if you go from the home
activity to another app the home activity window will be destroyed
before the activity is stopped because mAppStopped is set to true.
We now set mAppStopped to false when the activity is resumed.
Bug: 27286867
Change-Id: Ic75456d30abd582fa44f932f5aeeb449950157ee
Apps making calls into the system server may end up persisting
internal state or making security decisions based on the perceived
success or failure of a call, or the default values returned.
The reality is that if the system process just died, init will be
along shortly to kill all running apps, so we should have no problem
rethrowing the RemoteException as a RuntimeException.
Bug: 27364859
Change-Id: Ife0bcb079636c88d54c44d17eb580409fd79028b
- Move camera AIDL files to frameworks/av
- Update makefiles to point to new AIDL locations
- Adjust camera2 implementation to match modifications to AIDL needed
for native AIDL auto-generation
- Move Surface.aidl to frameworks/native to allow use in
native AIDL. Use android::view::Surface in Surface JNI to
serialize Surface objects to ensure parceling compatibility.
- Adjust service binder tests to new interface
Bug: 25091611
Change-Id: I85b817374b34a4540fa145328dbe4bbf7f746baf
If ignoreBottomDecorations=true, the display size was extracted from
the resources. However, this didn't work if the parent window was in
multi-window, as all the calculations went wrong. Instead, introduce
View.getWindowDisplayFrame which returns the "full" frame of the task
the window is currently in, without any insets, and use that to
calculate the bottom edge.
Bug: 26255254
Change-Id: I8b235b335775022ae399ee082d1200aa76cc047c
Some client will not disconnect, and if we're saving the surface (instead
of destroying it), we need to make sure the surface is disconnected.
Otherwise the client won't be able to reconnect to the same surface.
bug: 27295820
Change-Id: I471b8fbe8f590c900e17a017167466fc8a70b87a
This CL makes it clear that InputConnectionWrapper cannot be used to
emulate the behavior when a null InputConnection is passed to the
system.
We should provide some guideline for developers about how to deal with
bugs like crbug.com/571229, but as explained in the previous CL [1],
changing the behavior of InputConnectionWrapper could be a bit risky at
this point. Hence we put more cautions in JavaDoc instead.
[1] I8bc84d484ab0b27a02e74f11110430f70646e69a
abc4b8f035
Bug: 27407697
Change-Id: I98d1fc096c108603647a85bb0ba045b5dd23d37b
This reverts commit 90bd36363c.
Seems that the semantics of InputConnectionWrapper#setTarget() is more
complicated than I thought. At least the following cases have worked
fine.
case 1:
InputConnectionWrapper wrapper =
new InputConnectionWrapper(null, false);
wrapper.SetTarget(ic);
...
case 2:
InputConnectionWrapper wrapper =
new InputConnectionWrapper(null, true);
wrapper.SetTarget(ic);
...
case 3:
InputConnectionWrapper wrapper =
new InputConnectionWrapper(ic, true);
wrapper.SetTarget(null);
wrapper.SetTarget(ic2);
...
The previous code did not intended to break existing code. Let's revert
it we decide how to deal with above cases.
Bug: 27407697
Change-Id: I8bc84d484ab0b27a02e74f11110430f70646e69a
This CL makes it clear that InputConnectionWrapper does not support null
target. In other words, the semantics of null InputConnection can never
be emulated by a non-null InputConnectionWrapper.
This is particularly problematic when app developers are just forwarding
the return value of super.onCreateInputConnection() to
InputConnectionWrapper or its subclass, because there are many chance
that super.onCreateInputConnection() starts returning null, e.g. when:
A. the application is extending a Framework class, and the Framework
class is updated by OTA.
B. the application is extending system WebView, and the WebView is
updated.
C. the application is extending a 3rd party library, and the app
developer creates a new build with a new version of the 3rd party
library.
To make it easy to catch these kind of bugs, this CL lets the
constructor of InputMethodWrapper throw NullPointerException when target
is null. Bugs like crbug.com/571229 should be caught by developers
more easily.
Bug: 27407697
Change-Id: I83875bea886d4784f9507c930050efc29708d9db
Sometimes pointer change request is delivered after view is detached from its
ViewRootImpl. E.g. when popup is present click outside to close it.
Bug: 27292939
Change-Id: I925728af334a1e1ae53f7e530d639e50b0c37f2b
