am: ac4dfec1
* commit 'ac4dfec1c6d684b7d0d8ce09a5cba8fa9003e3a4':
BatteryStats: Add ble scans to checkin data and start global ble scan timer
Change-Id: I70c38df715190c58809732d03835286ab18a2e27
am: 740a5f0
* commit '740a5f023eea7b2fdb3e31efe8b8d5ac18aa8302':
Add the print service recommendation service
Change-Id: Ie58ade9356f591781496581259b6d8a876780ac9
am: ac94586
* commit 'ac945867145c571506a211ccb0a87a3402c4d745':
Refactor usages of Picture In Picture and Multi Window (1/4)
Change-Id: I34a274c3eca15546d7be85fbb30ac072ff03db7f
This service connects through the print manager to the print spooler:
PrintSpooler.AddPrintersActivity <-> PrintManager <-> PrintManagerService <-> UserState <-> RemotePrintServiceRecommendationService <-> PrintRecommendationService <-> PrintRecommendationServiceImpl
Hence there is a lot of mindless plumming.
The actual changes are only in the AddPrintersActivity which is extended
to show another list of services: The recommended services.
The PrintServiceRecommendationService is based on the experimenal print
service stubs provider. This provider was contributed the Android by
Mopria. As this services uses Android own network discovery service most
code from the experimental provider goes away. In fact the only logic
left over is the selections of mdns-txt fields to look at and the
printer vendor configuration.
This relies on the Android MDNS to get fixed (Bug: 27696905). This also
does not deal with how to update the recommendation service.
Bug: 24533249
Change-Id: I6edc6e25fc08a50d478b61c71bb8ea158b08624c
am: 620a84c
* commit '620a84c76aa3b0180fa214328cd200645de9008d':
LUTInterpolator needs to have 2 frame at minimal
Change-Id: I21005de68c66524ce471e423baaaccd6adb21e62
It turns out that BaseInputConnection has still depended on a private
API named BaseInputConnection#reportFinish(), which was introduced
4 years ago to work around a UI freeze due to an unbalanced batch edit
count [1]. Note that such an unbalanced batch edit count cannot always
be avoidable. It can easily occur in the following situations.
- The current IME crashed during batch edit.
- The user changed the View focus during batch edit.
- The current IME called IMM#switchToNextInputMethod() during batch
edit.
The remaining problem is that #reportFinish() is still an internal API
and only subclasses of BaseInputConnection can implement it, and IMM
calls it when and only when the current InputConnection is
BaseInputConnection or its subclass. InputConnectionWrapper and any
other InputConnection implementations will never receive such a callback
to clean up InputConnection#{begin, end}BatchEdit(), which is considered
to be a major contributor to UI freeze.
To address the above issue, we unhide BaseInputConnection#reportFinish()
as InputConnection#closeConnection() so that application developers can
receive an appropriate callback to clean up internal state including
unfinished batch edit.
[1] I5525d776916f0c42d5e6d4a4282aed590d7f0e9a
9d69ecbf61
Bug: 24688781
Bug: 25332806
Change-Id: I234309c5880c9fe0b299b8bd0f8862796d4dda0d
am: fe1886f
* commit 'fe1886f8b82330315a62e10d6dd27b0aa7c045cb':
Should not update initial state at all on resize.
Adding logging to track down bitmap issues.
Moving the background to the window.
Adding clear-all button.
Change-Id: I18865c7e916863138a3e8ab36b5e594ed92bc666
* changes:
Should not update initial state at all on resize.
Adding logging to track down bitmap issues.
Moving the background to the window.
Adding clear-all button.
- Make sure to remove the background from the DecorView while
resizing, so we don't draw it twice.
Bug: 27869246
Change-Id: I7f830e5c825749fdf2b5bbda7af92239702b70ad
For StandardMenuPopup, if user opens a submenu, the ondismiss listener is no
longer called. Instead, it is called when the submenu (which is now open in
the top level menu's place) is dismissed.
Bug: 27877103
Change-Id: I069388fd173142620c667fa8d1cb21e88d5266fe
am: f25ea2f
* commit 'f25ea2fece6dfe3c63cd063e5342e0102ee6d1f3':
Use default implementation for onForwardingStopped() in action menu
Change-Id: I884e15fce160a4cdefbad3418bfe6213f1977a1e
am: 09d83b0
* commit '09d83b032e5f456750f2f3149aa4932836643957':
Clean up a couple of bugs about transport init staging
Change-Id: I0c32b31bf82b1d3ed798263816ca789c3a7305d8
- Cache shouldAlwaysConsumeNavbar so it doesn't get reset when
insets == null
- Remove logic with frame comparison when determining whether to
consume nav bar. Not sure how that ever worked.
- Make sure shouldAlwaysConsumeNavBar survives when consuming
insets.
Bug: 27157904
Change-Id: I35f209ab27cc12240038da7efa9e79c95f70c6ce
This attempts to reland previously reverted CLs [1][2] due to an
unexpected regression (Bug 27824691).
The Bug 27868748 we want to address by this CL is that currently
InputConnection#finishComposingText() can be called on the root view's
Handler no matter what Handler is associated with
ControlledInputConnectionWrapper. Actually the root cause of
Bug 6789252 is the same, but there we worked around it by not calling
InputConnection#finishComposingText() in certain situations [3].
With this CL we should be able to logically revert that workaround.
This CL also removes redundant IMM#mServedInputConnection. This is safe
because the following two fields have the same lifetime.
- InputMethodManager#mServedInputConnection
- InputMethodManager#mServedInputConnectionWrapper
We do not need to maintain both of them. This also allows us to use a
strong refecente in IInputConnectionWrapper#mInputConnection instead of
a WeakReference. To understand why this is safe, we need to understand
how things previously worked, which is as follows:
1. InputMethodManager#mServedInputConnection becomes non-null.
-> IInputConnectionWrapper#mInputConnection.get() is guaranteed to
be alive.
2. InputMethodManager#mServedInputConnection becomes null or another
object.
-> IInputConnectionWrapper#mInputConnection.get() may not be alive.
Since we know exactly when InputMethodManager#mServedInputConnection is
updated, in theory we do not need to use WeakReference here, and
with this CL we do not use WeakReference anymore. Actually the initial
commit [1] accidentally removed the last strong reference to the active
InputConnection and WeakReference could be null at any time, which was
what we observed in Bug 27824691.
[1]: I1181e067aa5bedbdf0c7ec1bcec479257aea511c
afb6558c8f
[2]: Ibe94f115e607a198d12ecd3d4e4f91a7d9469c98
16e2c7b59a
[3]: I66f51da1299532793ef8fa700f35b0811670f235
4e5184f929
Bug: 27868748
Change-Id: If2a03bc84d318775fd4a197fa43acde086eda442
Now that CE data isn't available until after a user is unlocked, we
need to delay the PRE_BOOT_COMPLETED broadcasts. This is done by
adding a new RUNNING_UNLOCKING user state to the UserController
lifecycle.
We now track the last fingerprint a user was logged in under, and we
dispatch PRE_BOOT receivers when that fingerprint changes. To work
around battery pull issues, we only persist the updated fingerprint
once all PRE_BOOT receivers have finished. This is less granular
than the original solution, but it's still correct. We only consider
a user as "logged in" once it transitions into the RUNNING_UNLOCKED
state.
When starting a process, track if the user was "unlocked" when
started, so that we only spin up unaware providers in processes
started before user unlock.
Add generic IProgressListener to communicate PRE_BOOT progress and
strings up to lock screen. For now, LockSettingsService just blocks
until finished, but it could display these strings in the future.
Bug: 27220885
Change-Id: I349439776b885acd32f6a578d8951ffd95640be2
am: a04c532
* commit 'a04c532a09b8d946ebc9a086f673220059218869':
Implement transition for docking task in recents #6
Implement transition for docking task in recents #5
Implement transition for docking task in recents #4
Implement transition for docking task in recents #3
Implement transition for docking task in recents #2
Implement transition for docking task in recents #1
Show a scrim activity if task is not resizable
Add a callback to TaskStackChangeListener which gets fired when the system
might need to inform the user that a specific app might not work in
multi-window.
Use that callback in SysUI to show a translucent activity which scrims the
activity behind to inform that it might not be resizable.
Debounce the information to once per multi-window session, to not make it
annoying.
Introduce launchTaskId to start an activity in an existing task, and protect
that with START_TASKS_FROM_RECENTS permission.
Bug: 27327287
Bug: 27431869
Change-Id: I89e8d653872ab01ba3c1e252b426e5481da0e6ca
