Also moved the prepare/cleanupThread methods to Bridge
as they are not really specific to the scene anymore.
Change-Id: I7b93821913ce4d2fcbe3d8be489be6533ff87e57
Refactored to use a custom Callback instance instead.
This instance can be shared by different TextView, which no longer have to
be overloaded.
Change-Id: I4749905d8e2057dab2b3ded62bd7c388d13d4e57
This will allow 3rd party apps to access files on digital cameras via the PTP protocol
BUG: 3210830
Change-Id: I06dbf2842a7eea2e0749e2124bb7b7a65e8901c0
Signed-off-by: Mike Lockwood <lockwood@android.com>
Found reproducible cases of Launcher freezing up due to this change
This reverts commit 62490bd358cd001e00cb643cf3879d736c448788.
Change-Id: I1b10e05ee9f0c43566b53c7a11e61fc168d17a75
Add divider attributes to LinearLayout, plus styles for borderless
buttons. Update text field assets.
Change-Id: I673acab1692cc028a0327e8c154069253a4d52e8
By returning the channel object it self it is unnecessary
to have a token. Also, no current code needed it, if its
needed in the future it can be added back.
Change-Id: Ie1d2a1e885f9cd74e95663711ccefb760811bf16
Legacy applications using FLAG_FULLSCREEN do so principally
to get as much screen real estate as possible; reducing
clutter is usually a secondary concern. The new UI style
takes care of the latter for the most part, and the former
is irrelevant because the xlarge system bar never goes away.
Lights out---and with it the disappearance of important
systemwide navigation controls---is probably *not* something
these apps are expecting! Consider a game: it might want
FLAG_FULLSCREEN on phone to take over your entire display,
but might also rely on menu (to pause the game or bring up
options) and home (to allow you to exit). Lights out makes
these tasks much harder on the user because those buttons
aren't visible anymore.
So, to mitigate this potentially confusing situation, we now
disable lights out for fullscreen legacy apps.
[Hack, er, cleverness alert: We use NEEDS_MENU_KEY as a
shorthand for "legacy app." This flag is set by
pre-Honeycomb apps by default, but even an app built against
the current API can request this flag; be forewarned that if
you do, you won't get lights out mode in this particular
system bar implementation when you use FLAG_FULLSCREEN.]
Change-Id: If90d8354114ba45f9485b935b87ee575a30b9f87
1.) Change from samples per second (persist.sys.profiler_hz) to
interval between samples (persist.sys.profiler_ms) to match
underlying SamplingProfiler API. This allows samples to be taken
less often than a second, which allows lower overhead for always
on profiling.
2.) Add persist.sys.profiler_depth to control the number of frames
kept. Currently defaults to 4 which is the default hprof depth,
but often 12 is necessary even in benchmarks to get a good idea
where time is being spent.
3.) Moved SNAPSHOT_DIR creation to initialization time instead of
checking it on every sample.
4.) Used ThreadFactory to provide human readable name to writeSnapshot
Executor thread.
5.) Fixed bug where writeZygoteSnapshot was calling wrong variant of
writeSnapshot causing profiling to prevent zygote startup. Renamed
underling private writeSnapshot to writeSnapshotFile to try to
prevent future confusion.
Change-Id: Ifcfc343816b19f13a6eef2cbf25cde334d8adc3b
o getSupportedVideoSizes() allows us to retrieve the list of the supported
video sizes from the camera
o getPreferredPreviewSizeForVideoRecording() allows us to retrieve the
preferred/recommended preview size for camcorder applications
bug - 3237021
Change-Id: I52fc9938d389bb411406320b0309775b6f44f4dc
When calling startDrag(), the app can now supply an Object to be passed
along in every DragEvent that the app winds up receiving itself. This
object is *not* passed to any other applications; it's strictly app-
local. The purpose is to allow state tracking/management to be done
directly through the drag mechanism rather than requiring out-of-band
code.
An example of the utility here might be TextEdit widgets. A drag that
starts in one TextEdit but ends in a different one should be treated as
a copy/paste operation, where the originating TextEdit is not altered.
However, a drag that starts and ends in the *same* TextEdit is a 'move'
operation within that TextEdit; the text is removed from its original
position and inserted at the drop point. To support this easily, the
drag/drop code in TextEdit can now pass a pointer to the originating
view as the local state object. Then, the drop recipient could tell
whether the drag started within the same TextEdit without needing to
implement any other out-of-band state tracking.
This CL (and its accompanying CLs in a few other packages where the
startDrag() API is being used) adds the new local-state parameter to
the API, but does not actually change the behavior of any existing
clients.
Change-Id: Icba73b2ab4a650b7a94485a19633065b0ef9058c
The problem is that the code in AudioPolicyManagerBase::checkAndSetVolume() that forces
voice volume to max when setting bluetooth SCO volume is not called if the bluetooth stream
volume did not actually change. So even if we re apply volumes when switching to bluetooth
device, the volume voice volume is not changed and remains what it was when routed to earpiece
What makes things worse on Passion is that stream volumes are limited when connected to bluetooth
and their actual value does not change as soon as they exceed the limit threshold.
Change-Id: Id7c317db45b392a1c20dca2859678e3c64a371ed
