These have been created to reduce the size and complexity
of frameworks/base.
mms-common was created by moving all of
frameworks/base/core/java/com/google/android/mms
to:
frameworks/opt/mms
telephony-common was created by moving some of
frameworks/base/telephony
to:
frameworks/opt/telephony
Change-Id: If6cb3c6ff952767fc10210f923dc0e4b343cd4ad
Previous to this change the forceHiding variable was a boolean. This
change recognizes the different configurations of the keyguard by
defining separate states for forceHiding and testing for window
visibility differently in each state.
Fixes bug 6786114.
Change-Id: I3460c45ea6da772a4ff76bb016de7aa4b051a673
The flag indicating that the Starting window is displayed was not
being cleared when the Starting window was removed. That caused the
goodToGo indication to falsely indicate that all windows were drawn
when in fact the destination activity had not yet been drawn. This
caused the animation to begin when it was still black behind the old
animation.
This fixes bug 6764727.
Change-Id: Iacef73b0335b9bde2cdc8d0b072034222cd728e8
Only force hide windows when the keyguard is animating in.
Fixes bug 6721572.
Change-Id: Iad7b8b811bcf0840726cbf6c6f279dabd08a3aba
Conflicts:
services/java/com/android/server/wm/WindowAnimator.java
Make StateMachine#quit non-conditional and remove the need to
process the SM_QUIT_CMD it is now private.
Rename halting to onHalting.
Add onQuitting
Change the message specific logging to be more generic and change
the xxxProcessedMessagesYyy methods to xxxLogRecXyy names. Also add
addLogRec(String) and addLogRec(String, State) as the generic logging
methods.
bug: 5678189
Change-Id: I22f66d11828bfd70498db625fe1be728b90478b7
Conflicts:
services/java/com/android/server/NsdService.java
The package manager calls to clear data / clear cache were not also
having default container service clear the data on external storage. Now
they do.
Change-Id: Ib5e5eb6adf2cac5a4cc094cc1a02ac8cfb6a2edf
- There was a long-standing bug when using FLAG_ACTIVITY_REORDER_TO_FRONT
where we could find and use an activity that is currently finishing.
- There was a recently introduced bug where activities being destroyed
would not be removed from the history stack at the time they are done
being destroyed, allowing the above bug to be exposed.
- Removing a task would not kill any processes associated with the app
that had a different name from the app itself.
Change-Id: I4401ab6d348a69e1ac4fb8f719d2c69d5a78e567
...turns itself immediately back on.
The ON_AFTER_RELEASE flag is documented to not turn the screen on if
it is currently off.
Unfortunately, it didn't seem to actually do this -- it would just
cause a userActivity() call, which turns on the screen if it is
currently off.
Fix this by adding yet another boolean to that function to tell it
to not poke user activity if the screen is off. (Yes the number of
booleans on it is now insane, and should be cleaned up after we
get through JB.)
Bug: 6730064
Change-Id: I850dfbc777c7668d08b7d63f42a293e22b878256
Reduce the amount of unnecessary information emitted from
the DevicePolicyManagerService.
Bug: 6732364
Change-Id: I639f6beab8471bdbe41ce6cd3a5a378acaf678b2
When adding an system app via OTA, trying to remove it from mPackages
directly doesn't work. The ContentProviders and other things aren't
removed and point to the hidden system app's applicationInfo instead of
the updated app.
Bug: 6685263
Change-Id: I487cf518e0e3c60fae736e9b974617023a7dee8d
FLAG_ACTIVITY_CLOSE_SYSTEM_DIALOGS was a mistake.
Instead, and the infrastructure for the status bar to take care
of closing and hiding things itself when you press these buttons,
just like it does for the main Intent of the notification.
Bug: 6717667
Change-Id: I1b22186e0cedc05f46a1a3ec78053a72afaf61b1
Make sure that all cases where we remove an activity from the history
stack, we call resumeTopActivityLocked() to cause the home activity
to be launched if the stack is now empty.
Also fixed a problem where some timeouts would not be removed when destroying
an activity, and a race condition in boot that would cause the
PhoneWindowManager to initially start out with the home key not working.
Bug: 6381224
Change-Id: If046bb01aed624b0d9ee3bbaaba68ed6b98fd1d0
When launching only core apps, the wallpaper service
is not started. Without this change the WM waits
up to 30 seconds for the wallpaper window to be created even
though it will never happen. This introduces a significant
delay before the boot animation is dismissed so the user can
enter a decryption password.
Bug: 6263070
Change-Id: Ia975127a0bf09cf99818f7cc4fd6c0264b740ec6
The Starting window was being made visible early because the app
token had the dummy animation set. When the real animation started
the Starting window picked it up and became transparent causing
the underlying window to become visible again => jank.
Fixes bug 6691421.
Change-Id: I95fe88d2887760e6da3adedeb6be300eb6755283
In the course of the window manager refactoring into a separate
layout state, we introduced a bad interaction between the two
sides of the world. This resulting in multiple hops needed between
the two sides after an application has said it is finished drawing
its window, until the window/app transition is actually started.
Especially since these hops require going through the anim side
which is vsynced (so will delay its operation until the next frame),
this could introduce a notable delay until the window is first shown.
Fix this by re-arranging the code to make one straight path from
when a window reports it is shown to us starting the app transition
that is waiting for it. This change also includes various improvements
to debugging code that was done while working on it.
Change-Id: I7883674052da1a58df89cd1d9b8d754843cdd3db
