am: dbc4e4f
* commit 'dbc4e4fa83d6fb460165be22798bbf04422be9c2':
Work on issue #28221912: Starting service as foreground might...
Change-Id: I243f791317962d2ab9eea156b0f146f6fcc96fcb
am: 9c211a3
* commit '9c211a339689a2e54da3315ccdbf22add472c76a':
Work on issue #28221912: Starting service as foreground might...
Change-Id: I9f94c6adca6891ac0e43b83f45001092536c7ee9
Dialer recreates activity inside onConfigurationChange
when configuration changes significantly. Recreated
activity in this case was initialised with old base version
which resulted in incorrect configuration in split-screen.
This CL updates configuration when activity is created from
override config.
Bug: 27976063
Change-Id: I0ac002a5661154ec25f2d5aba3d44070b683ba2f
am: f6267a0
* commit 'f6267a0ac1fcfdd2f83a9b20934bdf4bea9ee65f':
Be bug-compatible with Fragment#setUserVisibleHint < N
Change-Id: I38d063ed28041d07f188250408e98c5272be2d11
am: de7b2ed
* commit 'de7b2ed881d75cb7f21ae2199b9af68ae019becf':
Be bug-compatible with Fragment#setUserVisibleHint < N
Change-Id: I4bf16f207710cc9b9214d4c97e260a1348c3fe19
Prior to Android N we were simply checking if a fragment had a
FragmentManager set before we would trigger a deferred
start. Unfortunately this also gets set before a fragment transaction
is committed, so if setUserVisibleHint was called before a transaction
commit, we would start the fragment way too
early. FragmentPagerAdapter triggers this situation.
Unfortunately some apps relied on this timing in overrides of
setUserVisibleHint on their own fragments, and expected, however
erroneously, that after a call to super.setUserVisibleHint their
onStart methods had been run.
Bug 28184671
Change-Id: Ie40d5f6963d312c2fad4a48fb4f992d33e65c83b
...kill previous notification.
Add new platform API to detach a notification from a service
without dismissing it.
Also, while I am here, add some more @IntDefs.
Change-Id: I3bb46d9cd3db7f73716c8ced19c20fea800eb30d
am: 771f2f4
* commit '771f2f457eb10b0bf0641bf3c12d6d5e6d38eb55':
Show work challenge in if user in docked stack is locked
Change-Id: Ic8992dacbc4c550250abe7ace79854d900d25def
am: 853304c
* commit '853304c0b11921db142a3945ab66fae5f0cc7d8a':
Show work challenge in if user in docked stack is locked
Change-Id: I1a5ff10237639fa2f0c20c756594d1d04c16d07d
Register docked stack listener in ActivityManagerService.
If the docked stack is leaving minimized state, check whether the user
of the docked stack is locked. If yes, show credential confirmation.
Also, we now show work challenge in home task.
And we now scan the entire top task to handle the case the work app is
somewhere in the middle of the task. (eg: open personal camera in work app)
Bug: 27565539
Bug: 28094505
Change-Id: Iaf0738f43ae916a535b17949ec0f322bbfb194dc
In order to capture profiles for apps which share the same VM and for
splits loaded without restart we need to move the profile registration
closer to where we create the class loaders (since bindApplication is
not called multiple times).
Moving the registration after class loader creation also allows us to
not profile apks which are already fully compiled.
Bug: 27539488
Bug: 27893309
Bug: 28012567
Change-Id: I6333f026f4f0680ca28e989f1686e3eac1145339
am: b8d5524
* commit 'b8d5524d8d7211b266e5405da7864c7f9eefae20':
Register the UI Thread as a sensitive thread to the runtime
Change-Id: I22fca39e19f94f1fdc560e19ad27f78e5abdeca9
am: 6aff67b
* commit '6aff67bfcb9dcca6e3f26ff04dbe8f9806e5e8a5':
Register the UI Thread as a sensitive thread to the runtime
Change-Id: Ib3e5d6ac34f14c6d6f0809d2f969422b49efea8f
Framework edition
Previously we would throw away any stopped LoaderManagers when we went
to retain instances to pass along as nonConfigurationInstances during
config changes or similar activity restarts. This causes loaders to do
more work than they need to when a calling activity starts a new
activity on top, a config change happens (e.g. screen rotation) and
then the top activity is finished, restarting the caller in a new
configuration. The loaders would go through onReset unnecessarily,
potentially throwing away data to be reloaded again after the config
change completes.
Instead of throwing away stopped LoaderManagers in this case, restart
them and retain them across the config change so they can resume where
they left off.
Bug 27176186
Change-Id: Ia52c6448d2ad41dcb25d493770d9ffae20a19d2a
am: 021af18
* commit '021af1800c352933d25f927dc357534c62a9e39c':
Remember task which is being locked
Change-Id: I06c64b220fe20775510b938c5235acf026c83c7d
am: 5981b8c
* commit '5981b8c2e8f6363d1f3bf09e7f1b3b5fb9a3846a':
Remember task which is being locked
Change-Id: Id672304edaa6a02777e79fe6b4fcdd64e3c5f7e8
We need to remember task which requested to be locked
because we can accidentally lock another task after
user interacts with pinning request dialog.
Bug: 27876860
Change-Id: Ie8e607df4380dd33ea9b3474afc247b02e31de07
