In order to unbundle System Update, we need some to expose in the SDK
some way to reboot the device into recovery. Add a reboot() method to
PowerManager, protected by the android.permission.REBOOT permission.
Add optional flag to Wakelock.release() to specify whether we should wait for proximity sensor to go negative before turning on the screen.
Clear the "waiting for proximity sensor to go negative" state when the power key is pressed.
Part of the fix for b/2243198 (Black screen lockup after ending call)
Change-Id: I813fdb7aa4192cd3384a25be9e59d7d4b90da53a
Signed-off-by: Mike Lockwood <lockwood@android.com>
Merge commit '991475a2e5dcb344299387521b52fb637d6b1e4d' into eclair-mr2
* commit '991475a2e5dcb344299387521b52fb637d6b1e4d':
Add isScreenOn() to LocalPowerManager interface so we can call it from PhoneWindowManager
Needed for the fix for b/2260437 (device wakes itself back up when camera is last application running)
Change-Id: I0e419fcf05542df203eb3f127dde7a888416e86d
Signed-off-by: Mike Lockwood <lockwood@android.com>
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
