homescreen
A shortcut can be added by any app as INSTALL_SHORTCUT is a normal
level permission. But the intent is actually launched by the launcher
app which can have other permission as well.
> When adding a shortcut from the broadcast, verify that the intent does
not require any permission
> When adding a shortcut using the two-step drop process, verify that
the source app also has the permission to create such a shortcut
Bug: 30778130
Change-Id: I33a391bc0af81248aaff4459aaa79d1adc77926b
(cherry picked from commit fb5096d07b)
The default strict mode policy in NYC cause death penalty when
when sharing file URI in intent. This causes launcher to crash
for users who have shortcuts of images and documents on their
homescreen.
Bug: 28853579
Change-Id: If84cd5ff732713aaff5d3164edf428c8b4233ea2
(cherry picked from commit 85fc55a976)
> Sending unboundX to the overlay which is the total untranslated X and not just deltaX from last frame
> Handling overlay callback and translating workspace accordingly
Change-Id: I3bd8d9efac738e9ce131758f0e5ff1b9c1d6a8fc
Overlays are supposed to use their own UI and not interfere with the
Launcher UI. If the UI needs to be put inside the Launcher, use customContent
instead.
Removing some unnecessary and unused methods related to overlays
Bug: 25993953
Change-Id: I4d715cdee04eb7b0ebef673d885a4258c521ff1f
b/27978139
Background: onSaveInstanceState assumes that state of the launcher
is being stored after screen is all binded. However, due to ActivityStack
bug in nyc, onCreate is called twice when the device is rotated while
the Launcher is in the background. The first onCreate fails because
our AndroidManifest is setup with nosensor field and hence doesn't support
Landscape. During this first onCreate, screen is not correctly bound
and incomplete workspace state is saved. This results in the second onCreate
to load wrong screen id.
Fix: While the workspace is still being bound, mSaveState is not reset,
which has the correct values. SaveInstance should use this state
instead of incomplete workspace state.
Change-Id: I5b80f584e55769b2a8ffa292f5daa4705c20086d
In battery saver mode, animations skip directly to the final values.
For LogDecelerateInterpolator, however, an input of 1f outputs an
interpolated 0.99999994. This meant that the FirstFrameAnimatorHelper
didn't realize that this was the last frame, and messed things up.
Since any interpolator should return 1 on an input of 1, we just
short-circuit in that case for the log interpolators.
Bug: 25666809
Change-Id: I60527e3758cea383fbcf50acb95460a7bd9ab43c
change for launcher when going in/out of another app
Bug: 27600678
Change-Id: Ic873faba99c539025769d911bc7b0a4fed629cd7
(cherry picked from commit 784f9c3996)
AppWidgetHost in N was changed to make start/stop lisenting calls
light weight, which allows launcher to avoid getting unnecessary
updates when its not visible
Bug: 23892701
Change-Id: I0ca6e02400992bc4e0359e45a3d66b9252751402
(cherry picked from commit 23ac9cb3e1)
> When package gets unavailable or suspended, the disabled flag was getting
updated on the UI thread. This could lead to inconsistent model if launcher
activity didn't exist.
> Fixing: When unsuspending one work profile apps, all work profile apps get
unsuspended
Bug: 27673573,27673373,27403236
Change-Id: I7fde3f79c36204e73ca66ccf8431fa0f0cce3d08
Conflicts:
src/com/android/launcher3/DragController.java
Widget is loaded only when the user enters the overview mode and we keep
the list updated as long as the user is in the overview mode. Once the user
leaves the overview mode, we stop responding to widget updates
Bug: 26077457
Change-Id: I9e4904b8f1300bfe0d77e2bc5f59aa6963fad8d1
Grey out applications when managed profile is
not available.
Change-Id: I9bb9442cd0b3d0d207062716bfd6b179e3ba8489
(cherry picked from commit ff05f4375d)
Grey out application shortcuts and all apps entries
for packages that are suspended.
Bug: 22776761
Change-Id: I1b63da1816aca1de52b9f9bee62d1b162d0cdf4d
(cherry picked from commit 44cba69638)
The content provider is the first component started with the main process,
which makes it ideal for initiating LauncherAppState
Change-Id: I03db82a8949ad1376af53a0033592f421dbf0b15
> Pressing 'enter' enters the focus inside the widget.
> If the widget has only one focusable, it directly performs click
> Pressing 'esc' brings the focus back to the parent host.
Bug: 25199581
Change-Id: Ia7fd5d929f5945d61173abd349660a5efbe74afc
- Seperate search bar height from its top and bottom paddings
- Report this height plus 8dps top and bottom for the widget options
- Use a separate bottom padding to adjust spacing between QSB and
the workspace
- Add tests to verify the height of the search bar in both normal and
tall modes (ran on Nexus 6, 7, and 10)
Change-Id: Ia7557785d1b38194eee869d0460456e8f33447d5
There is a race condition that occurs primarily (maybe entirely) with
Android Auto, it seems because they hijack the Home intent or something
similar. I'm not exactly sure how Android Auto works, but if I pair my
phone with the Desktop Head Unit (car dashboard emulator), I can repro
the NPE fairly easily by simply force closing Android Auto and then
disconnecting my phone from the DHU. If I don't force close Android
Auto, then pressing home launches Android Auto or other apps that I
assume handle some custom intent, such as Car Home Ultra, instead of
normal Home intents such as Launcher3/Google Now Launcher. So I think
what's happening is that, when the phone is disconnected from the car,
Android Auto restores and launches the real home intent (Launcher 3)
around the same time that it destroys the previous home intent
(Android Auto, Car Home Ultra, etc.). This could cause the NPE if both
intents are actually Launcher 3, as is the case when Android Auto is
already closed, because mWorkspace is set to null in
Launcher#onDestroy() (something like onNewIntent() --> post() called
--> onDestroy() --> post() runs). This is consistent with the fact
that I can guarantee a repro if I use postDelayed() instead of post().
Long-winded explanation aside, I think this fix is safe, especially
since we already have a null check for mWorkspace in onNewIntent(),
just not inside the post().
Bug: 24610231
Change-Id: I42f75b83946f375d947be1961a1f2a03a3707a84
This ensures that the QSB widget options are set correctly the first
time they are used.
Bug: 24704753
Change-Id: I2bb13ff012b6f13ca076deed61f0b08a7037e2fa
The problem was due to a race condition between removing a prebound
widget view from the drag layer and adding the same view to the
workspace upon dropping it; if you let go of the widget immediately
after picking it up, the latter happened before the former.
Specifically, the flow was: long-click a widget --> drop --> remove
the view from the drag layer if it's not null (it is, so nothing
happens) --> the view is finally bound/inflated and added to the drag
layer --> add the view to the workspace --> already has a parent.
There are actually 2 problems here: one is that the bind/inflate is
asynchronous, and can therefore happen after dropping the widget view
being inflated, and the other is that the view is added to the
workspace even though the transition has barely started (we usually
ignore drops if the transition is less than half complete). It turns
out that this second problem was also due to a race condition, this
time between dropping a widget or app onto the workspace and calling
LauncherStateTransitionAnimation.dispatchOnLauncherTransitionStart().
If the drop happened before the dispatch, as in the case of the
crash, then the drop was accepted because the transition progress was
still 1.0 from the previous transition.
I fixed the first problem by removing the drag layer widget view
in Launcher where it is potentially used instead of Workspace. And I
fixed the second problem by setting mTransitionProgress to 0 in
Workspace.onLauncherTransitionPrepare().
I also added some debugging logs.
Bug: 23896857
Change-Id: I66944e6d3f23b70dea15f7fb01af0763a1bfcbda
Sunny Goyal
Hyunyoung Song
Tony Wickham
Kenny Guy
Winson