| 791a887701aa8751f11ec5a664503f2dcf56bb60 |
|
22-Feb-2017 |
Wale Ogunwale <ogunwale@google.com> |
Updated some internal apps to use TYPE_APPLICATION_OVERLAY
TYPE_SYSTEM_ALERT is deprecated as of O.
Test: builds
Change-Id: Ic335ff0aa2f0356737c2e67debe8e71ea9eb2f41
/frameworks/base/packages/FakeOemFeatures/src/com/android/fakeoemfeatures/FakeApp.java
|
| b57a50bd16ce25db441da5c1b63d48721bb90687 |
|
12-Apr-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #8582003: Evernote Camera Capture Failure
ActivityThread.currentPackageName() was actually returning
the process name. Change this to return the package name, and
fix the one spot using it I could find that was actually wanting
the process name.
Change-Id: I323b9c5987106b5a090968e545281fc0ba55b6b8
/frameworks/base/packages/FakeOemFeatures/src/com/android/fakeoemfeatures/FakeApp.java
|
| 98365d7663cbd82979a5700faf0050220b01084d |
|
20-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Refactor for multi-display support.
Split WindowManagerImpl into two parts, the WindowManager
interface implementation remains where it is but the global
communications with the window manager are now handled by
the WindowManagerGlobal class. This change greatly simplifies
the challenge of having separate WindowManager instances
for each Context.
Removed WindowManagerImpl.getDefault(). This represents the
bulk of this change. Most of the usages of this method were
either to perform global functions (now handled by WindowManagerGlobal)
or to obtain the default display (now handled by DisplayManager).
Explicitly associate each new window with a display and make
the Display object available to the View hierarchy.
Add stubs for some new display manager API features.
Start to split apart the concepts of display id and layer stack.
since they operate at different layers of abstraction.
While it's true that each logical display uniquely corresponds to a
surface flinger layer stack, it is not necessarily the case that
they must use the same ids. Added Display.getLayerStack()
and started using it in places where it was relatively easy to do.
Change-Id: I29ed909114dec86807c4d3a5059c3fa0358bea61
/frameworks/base/packages/FakeOemFeatures/src/com/android/fakeoemfeatures/FakeApp.java
|
| d459f4bbfcfe4989a0e2298b3cfd36064b386b88 |
|
28-Feb-2012 |
Dianne Hackborn <hackbod@google.com> |
You could think of this as what an OEM might do.
Except it does nothing.
But eat resources.
Yum, yum!
Current we create five processes. The main process sucks up 16MB of
RAM and creates a full-screen window; only on high-end devices does
the window (and process) use the GPU.
The second through fourth processes just sits there not really doing
anything except using process overhead.
The fifth process runs a background service, slowing eating RAM until
it gets killed by the system (as the system will ultimately do with
background services). It also creates a full-screen window, and always
uses the GPU even on low-end devices.
Change-Id: Ibe9e25f7dbd889f4dc83eed6a3c09b9b0437b4e3
/frameworks/base/packages/FakeOemFeatures/src/com/android/fakeoemfeatures/FakeApp.java
|