Merge commit '2bb53754337225508f2b4d12f1575df7c226100c' into eclair-mr2
* commit '2bb53754337225508f2b4d12f1575df7c226100c':
Fix code example in Parcelable javadoc
Merge commit '3cba72880b78b81cda2868136462c9e261a3e403' into eclair-mr2
* commit '3cba72880b78b81cda2868136462c9e261a3e403':
Expose PowerManager.isScreenOn in the public api.
Merge commit '9053fdb32b38d1240d856bd6efedf72eefba48d3' into eclair-mr2
* commit '9053fdb32b38d1240d856bd6efedf72eefba48d3':
Add support for colored LED on jogball backlight.
interface (android.os.DropBox); move the Binder interface
behind the scenes. Make DropBoxEntry into DropBox.Entry.
Make it possible to get a dropbox from an (Application)Context
with the usual getSystemService(DROPBOX_SERVICE) type thing.
Update the tests accordingly.
- Added new functions to PerformanceCollector and PerformanceResultsWriter
- Modified unit tests to test new functionality and fix flakiness reported in
2218327 and 2118268
- Added PerformanceCollectorTest to small suite
DOCS ONLY
The code example for android.os.Parcelable contained several errors:
- There was no type parameter for Parcelable.Creator (due to unescaped
< > in the javadoc comment).
- There was no implementation of describeContents().
- The semicolon after the CREATOR declaration was missing.
This change fixes all of the above.
Fixes issue http://b/issue?id=2221120
Change-Id: Icaf932d079573cc7699f1caa643aac49e85ccca0
* changes:
It turns out to be useful to allow enumeration on a per-tag basis, and it's easy to support based on the data structures we have, so add a tag parameter to getNextEvent().
Merge commit 'f37447bad3773b62176baa837908daf6edb44273' into eclair-mr2
* commit 'f37447bad3773b62176baa837908daf6edb44273':
Proper fix for zero signal strength and no_service. Fixes#2176141
Track phone service state changes and use a separate timer for out-of-service
since the hunting can timeout on some devices.
Store the timeout value in the config.xml, as it is device/network specific.
Settings App will also change to use the hunting duration to compute the cost
of zero signal.
We will use the System.SCREEN_BRIGHTNESS_MODE Settings value instead.
Add SCREEN_BRIGHTNESS_MODE_MANUAL and SCREEN_BRIGHTNESS_MODE_AUTOMATIC constants.
Change-Id: I01935be3fcb48cf76392d2c594205cb47babc5b2
Signed-off-by: Mike Lockwood <lockwood@android.com>
queue of data chunks (sort of a blob-oriented logcat).
In the future, this will be coupled with a revised checkin service that
would actually upload this data.
This is in accordance to the documentation. This bug was approved by hackbod.
The change is safe and is a single line of code.
Change-Id: I9b771df3ae2aa4f496d15e6c43b677f3245539ac
More CPU speed stepping happening with newer devices, so we need
to qualify CPU time with the CPU speed, since power consumption
varies greatly by speed. Apps that peg the CPU should get a higher
penaltly.
Also, fix for 2062930: NPE at VolumePreference.onKey()
to prevent apps from changing the hardware behind its back.
Fixes b/2041941 Lock screen flashes the screen very bright before dimming
Change-Id: Ice757f7ae87902bdfb3634471cf44f020ebfaae4
Signed-off-by: Mike Lockwood <lockwood@android.com>
Add changes to have the ability to turn on and off the
automatic light sensing for the device. This is fully configurable
and is by default not present. Vendors should override the ALS setting
to enable the automatic lighting controls.
These changes will add a check box to the Brightness settings menu to give control
to the user to allow the device's display lighting to be controlled via the slide bar
or the auto lighting system.
If the user selects auto then the slide bar will become invisible. Manual mode
will present the slide bar to the user.
Change-Id: I146a6d75b99b08c9b839218ce6b85adf21f9fd73
Signed-off-by: Dan Murphy <D.Murphy@motorola.com>
Signed-off-by: Mike Lockwood <lockwood@android.com>
First, fix some issues with the final wallpaper bitmap
we use: ensure it is always 16bpp, and make sure dithering
of its bitmap is turned off. We take of dithering
when loading, to make sure we don't use it when drawing.
Also add new APIs to return the wallpaper with the equivalent
of Launcher's old FastBitmapDrawable. As doing this, also load
the default wallpaper the same way as custom ones, taking care to
resize it as needed at load time.
Finally implement a mechanism for the window manager to wait
for the wallpaper to redraw at its new position before returning
from the application's call to change the offset. This ensures
that the wallpaper better tracks the application. Note that there
is a timeout in this wait that is relatively short, and if it
expires we will run for a while without waiting.
Change-Id: Ife449437746da85958bd447e0a6cf3d2223b398c
+ For bug 1810508
- Added PerformanceCollector class to collect runtime and memory usage data
* Moved performance snapshotting from Intrumentation to PerformanceCollector
- Added PerformanceResultsWriter interface which defines functions for
reporting performance data
+ Framework integration
- Added TimedTest annotation to automatically time tests and write results
to instrumentation output
- Modified PerformanceTestBase to add collection hooks and wrapper methods
- Modified WatcherResultPrinter in InstrumentationTestRunner to implement
PerformanceResultsWriter for instrumentation output of performance data
- Modified InstrumentationTestRunner and AndroidTestRunner to pass writer
instance to test
This is needed to allow the BugReportService to start the dumpstate service.
Change-Id: I12cab23767c919592da102c654b6b80416717661
Signed-off-by: Mike Lockwood <lockwood@android.com>
Some of this is temporary (in particular the two approaches for getting
process memory, one working but horrible, the other not working but
preferred) until I figure out the best way to do it.
Change-Id: I8c8f25062d481fcea22a47d459b083d2fd8a5040
One of the problems I have been noticing is background services
sitting around running and using resources. Some times this is
due to the app developer doing this when they shouldn't, but there
are also a number of issues with the current Service interaction
model that make it very difficult (or impossible) to avoid
getting services stuck in the started state. This is a
change/enhancement to the Service API to try to address this.
The main change is that Service.onStart() has been deprecated,
replaced with a new Service.onStartCommand() that allows the
service to better control how the system should manage it. The
key part here is a new result code returned by the function, telling
the system what it should do with the service afterwards:
- START_STICKY is basically the same as the previous behavior,
where we usually leave the service running. The only difference
is that it if it gets restarted because its process is killed,
onStartCommand() will be called on the new service with a null
Intent instead of not being called at all.
- START_NOT_STICKY says that, upon returning to the system, if
its process is killed with no remaining start commands to
deliver, then the service will be stopped instead of restarted.
This makes a lot more sense for services that are intended to
only run while executing commands sent to them.
- START_REDELIVER_INTENT is like START_NOT_STICKY, except if
the service's process is killed before it calls stopSelf()
for a given intent, that intent will be re-delivered to it
until it completes (unless after 4 or more tries it still
can't complete, at which point we give up).
Change-Id: I978f5ca420d70023d1b5e7f97de639d09381f8ad
Add new wakelock flag PROXIMITY_SCREEN_OFF_WAKE_LOCK.
If you create a wakelock with this flag, while the wakelock is acquired,
the screen will turn off automatically when the sensor detects an object close to the screen.
Removing the object will cause the screen to wake up again.
Added PowerManager.getSupportedWakeLockFlags(), which can be used to determine
if proximity screen off wakelocks are supported by the hardware.
Signed-off-by: Mike Lockwood <lockwood@android.com>
This adds a new API with the activity manager to find out about movement between
activities. For my sanity, the old IActivityWatcher is now renamed to
IActivityController, and the new activity movement interface is named
IActivityWatcher.
This changes the search manager itself to use the new API to manage its state.
Note that there are still problems when going back to the search dialog after
it was hidden -- the suggestions window no longer appears until you explicitly
dismiss and re-show it.
This is the problem where various things are listening for broadcasts
(such as battery status, PIN/PUK/Network) that an application can send
to cause harm to the system.
Solving this is tricky because many of these broadcasts are sticky,
and I have never figured out how to do permissions with sticky
broadcasts in a sane way. So instead, I am going to punt on the
general problem and just brute force it:
There is new a way for system components to declare specific
broadcast actions to be protected, which means that only the system
and the phone can send them. This is good enough for now. None
of it is exposed in the public API so we can make something a little
less stupid in the future if we ever need to.
