| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| | |
stuff happens.
|
| |
| |
| |
| |
| |
| | |
Bug 2652948
Change-Id: I9d386395278830ead5deda17b8b09e0dcfeff989
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Looks like the code path for buildDrawingCache(false) has some bugs.
This reverts to the old code path and tries to manage the creation of
those caches a bit better.
Change-Id: Ic468e9db396c51f723454dc3832e0cd1c0c82004
|
|\|
| |
| |
| | |
2639807" into froyo
|
| |
| |
| |
| | |
Change-Id: I71a18497862a30db5ff0f52f566fb86eae213ea3
|
|\|
| |
| |
| | |
UI thread. Bug #2614636" into froyo
|
| |\
| | |
| | |
| | | |
Bug #2614636" into froyo
|
| | |
| | |
| | |
| | |
| | |
| | | |
Bug #2614636
Change-Id: If9ded9a2e231a429e4d0a21626b486f76fd0a3a6
|
|\| |
| | |
| | |
| | | |
browser." into froyo
|
| |\ \ |
|
| | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
To do this, we invoke resolveActivity to see what activity
would result from viewing an arbitrary (but valid) URL. If
there's just one installed, or there are multiple and the
user has chosen a default handler for http:, we take that
component and launch it with CATEGORY_HOME (so as not to
upset the URL in the frontmost window/tab/what-have-you).
We also use this information to extract the localized name
of the app, which is then installed into the hotseat as the
contentDescription (for accessibility).
If there's no default and multiple options are availble,
we'll get the activity chooser instead. In this case, we
just fire off that chooser and let the user pick an app
(possibly setting a default along the way). Because the
default may change, we reload all this hotseat information
every time one of the hotseats is tapped.
Another side-effect of this approach is that until there
exists a default browser, the original URL will be sent to
the activity the user chooses from the ResolveActivity. So
we need a sensible default URL here; one can be found in
R.string.default_browser_url (similar to Browser's
R.string.homepage_base).
This change also moves the hotseat intents and icons into
arrays.xml for easier configuration.
Change-Id: I06268df8b59e0f41f1f8b0e47f823db4c44ec761
|
|\| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Duration of motion is now influenced by fling velocity. Constants have
been tuned and tweaked.
Fix a couple of drawing optimizations in Launcher2 Workspace.
Change-Id: Iaa674d10a28554884d9cc98134b2d1253b5e3e70
|
|\| |
| | |
| | |
| | | |
distance.
|
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes the issue where using the long-press-on-dots feature to
jump to a specific home screen overshoots by a large distance. It also
speeds up the resulting animation such that jumping from screen 1 to 5
doesn't take as long.
Change-Id: If41086b17df875be5514776e3af24292587d05a7
|
|\| |
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The hotseats are permanent slots on either side of the
AllApps button. Their functions are:
LEFT/BOTTOM: Phone
Launched via the hardcoded class name
com.android.contacts/.ContactsLaunchActivity.
RIGHT/TOP: Browser
Launched by querying to see which application is the
default for URLs, then starting that activity directly.
In the future, it would be ideal to allow an application
with permission to access LauncherProvider to customize
these (icons, contentDescriptions, and Intents).
Bug: 2559083
Change-Id: I56f6e745f8574aa17e28feaa9d2118fb4a715cd4
|
|\| | |
|
| |/
| |
| |
| |
| |
| | |
Callbacks can be null.
Change-Id: I56462a54673b1804a6235d6d882008b453290542
|
|\| |
|
| |
| |
| |
| | |
Change-Id: I78130d6f237f476bc33a4718ca5ef245fe502857
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| | |
This way we can figure out how many apps to send to the grid
at a time even if the grid hasn't been instantiated yet.
Bug: 2599979
Change-Id: I7960fe1adae6976555334422335f3a4b28d0675e
|
|\| |
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Removed another redundant sort
* Correctly set the thread priority to BACKGROUND for the
all apps loading step.
* Moved batch delay to a resource
* Reduced delay between loading batches of apps to 100ms
(we really just want to sleep a tiny bit between batches
to give the UI time to react)
Bug: 2562420
Bug: 2599979 (related)
Change-Id: I1ae72a68c1a47377a9eb62827fe7666bfc50caa5
|
|\| | |
|
| |/
| |
| |
| | |
Change-Id: I1d8f1ceb39dc21e58c833cf030a41d08913ef7e3
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The sorting is no longer being done in LauncherModel.
AA3D.addApps correctly performs an insertion sort, but
setApps did not.
Missing from change I77e3865b.
Bug: 2562420
Change-Id: I6854c2c4a221b2c1ad123410292da1fbfece7871
|
|\|
| |
| |
| | |
LauncherModel." into froyo
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
AllApps2D and AllApps3D do their own sorting before display.
Bug: 2562420
Change-Id: I77e3865b856a5123872bee3d8578d0596956cddd
|
|\| |
| | |
| | |
| | | |
widgets, or background.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
background.
The mNext* stuff in AllApps3D got reset when onNewIntent came in too fast after an
onCreate, which happened because of the configuration changed.
Change-Id: I9a358b6969ac1d17ea98f58218d47bfe983936f0
|
|\| | |
|
| |/
| |
| |
| |
| |
| |
| | |
This code never worked. If you delete a live folder for an app that's been uninstalled, it would
crash.
Change-Id: Id91712fada8912addbc4892bd5ae517536fc4f24
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
AllAppsList now maintains <data> and <added> in sorted
order, to amortize the cost of sorting the apps list over
multiple batches.
Launcher boosts thread priority on first launch, but we now
reduce thread priority to normal after the main workspace
has been drawn but before all apps are loaded.
Experimental feature: a short delay is introduced between
batches to help free up the CPU (as well as to show that we
are indeed batching apps).
Bug: 2562420
Change-Id: I2035ec3e819b4e7993a80c6d03bfad3914c95a7a
|
|\|
| |
| |
| | |
navigate between home screen using touch.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
home screen using touch.
Somebody fixed a bug in managed dialogs where it wouldn't
create the dialog after a configuration change. This means that we
shouldn't set mWaitingForResult in createDialog, we need to set it in
onShow. This is what the add dialog was already doing.
Change-Id: I955c2f7cd4a47213f84986ec9ba251146b1ac423
|
|\| |
|
| |
| |
| |
| | |
Change-Id: Iec8df7b668a4657677f9c5421d00aa1b7df91015
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| | |
Bug #2498787
Change-Id: I8f007eb2759d00f52e05e776a70510ba3a213ae9
|
|/
|
|
| |
Change-Id: Ia14ff132e49390bf3bc4ac6ebf1b3eded8d39caf
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #2562729
In landscape, the left and right dots buttons are 93dip wide; this makes them overlap
with widgets at the bottom of the screen. The dots do not need to be that wide but
we chose this size to make it easier to tap them in portrait. To avoid issues in
landscape, this change introduces a new type of ImageView that can ignore touch
events in a certain zone. This was easier and cheaper than re-cutting 36+ assets.
Change-Id: Id261fba41a43dede943e72060e39e87658e4b0df
|
|
|
|
|
|
|
| |
This prevents users from scrolling left slightly, flinging right,
and scrolling by two screens as a result (and vice versa).
Change-Id: I04c60438c022b24defcd8e4cbedf1c6b07c24423
|