The command always has one or more bytes for its parameter, so
the right validation should have been the one ensuring the number
of bytes (1 ~ 14).
Bug: 24986703
Change-Id: I171e971f1649761d69ffe2aa0af364f34dc9ac3e
(cherry picked from commit 4808581f4dfdf04adcd2646e152dede0ce418cad)
While one party calls oneTouchPlay() to initiate the action and
put it in progress, the other parties making the same call gets
an error 'operation in progress'. This is not really an error,
but there was no other choice for them but just to wait till
the action is completed and the service is ready to accept
the API call again.
This CL resolves the inconvenice by allowing multiple callbacks
rather than returning IN_PROGRESS for those joining later. Same
was applied to queryDisplayStatus().
Change-Id: I5fc9aba4aa73e76a25f8fdec37e11cd961a3d35f
(cherry picked from commit 98a25f1ee27c1b4362a23981edc17fc92199a876)
Added a comment to clarify how the service is designed to handle
CEC commands <Text View On>/<Image View On>.
Bug: 24690166
Change-Id: Iaa1813b3ded76e8525141555d2aaff6dfb67888d
(cherry picked from commit 6667797016a28551202b40067fe90512185a7a61)
We need to be very precise about removing the old window when the new
one is shown. The right moment is immediately after the first frame
of the new window entrance animation gets commited. This requires
more infrastructure and flags, rather than depending on the old ones
and hoping that they will match our needs.
Bug: 25075151
Change-Id: I0fdbf38d0915ded3300d75fc7268e619b574bcf5
we print using it the first time.
This warning used to be shown when the print settings app was used
to enable a service.
If two warning as shown for the same print service we automcatially
dismiss all dialogs once one dialog is confirmed. Please note that
we are not confirming the printjob as it is unexpeced to have a
single click to confirm multiple print jobs.
Change-Id: I8bb0a49bac2063c1c55e2f24bd34df2c44e2df89
Bug: 24135353
Because DecorView is now a static inner class, we need to remember to
always add the PhoneWindow on which it depends.
PhoneWindow.generateDecor will do that now to prevent further
mistakes.
Also remove PhoneWindow.setFeatureFromAttrs which is not used
anywhere and seems to be an artifact from the past.
Bug: 25086413
Change-Id: I0d8e5df717d7046e85ffc58f7ec4e94ce15a7d80
Apps can mark manifest components as being encryption-aware, which
means they can safely be run before the credential encrypted storage
is available.
Start adding filtering logic so that we only return these components
when a user is running "with amnesia." That is to say, only device
encrypted storage is available, so the user is running but with only
partial knowledge of its data.
To avoid calling into ActivityManager with the PackageManager lock
held, we quickly determine user state and splice the state into the
flags for later per-component evaluation.
Bug: 22358539
Change-Id: Idc56ec29f1ef04da8963e004314d7f5e47400997
Wallpaper wanders through the window list, for example to position
itself directly behind keyguard. Because of this it will break the
ordering based on WindowState.mBaseLayer. There might windows with
higher mBaseLayer behind it and we don't want the new window to
appear above them. An example of this is adding of the docked stack
divider. Consider a scenario with the following ordering (top to
bottom): keyguard, wallpaper, assist preview, apps. We want the dock
divider to land below the assist preview, so the dock divider must
ignore the wallpaper, with which it shares the base layer.
Bug: 25564817
Change-Id: I5bab792d972f845931b54db9f9ae5ff9a4a0e9b3
