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.
Optimize backups by writing an entity only if the checksum of the data has changed.
Call into the hidden AudioService API to apply changed audio settings.
After restoring wifi data, make sure that the permissions and ownership are set
properly for the supplicant process to access it.
Locale isn't restoring properly - TODO added.
There are 2 types of vibrations: simple and repeated. Simple vibrations run for
a given length of time while repeated patterns run until canceled or the calling
process dies.
If a vibration is currently running and another request is issued, the newer
request always takes precedence unless the current vibration is a simple one and
the time left is longer than the new request.
If a repeating vibration is running and a new request overrides that vibration,
the current vibration is pushed onto a stack. Once the new vibration completes,
the previous vibration resumes. IBinder tokens are used to identify Vibration
requests which means that multiple calls to Vibrator.vibrate with the same
Vibrator object will override previous vibrations on that object.
Merge commit '040441fa992bcfc11070d559bfceeb039667b382'
* commit '040441fa992bcfc11070d559bfceeb039667b382':
Tweak the core and maximum pool sizes for AsyncTask.
This change allows up to 5 AsyncTasks to run concurrently. Before, only 1 task
could run at a time, which was too limited. This change also bumps up the maximum
number of tasks that can be created; this large number is not an issue because
tasks are queued up and run only 5 at a time.
Merge commit 'f881762f97c74253bbc7f629380bb65739457041'
* commit 'f881762f97c74253bbc7f629380bb65739457041':
Add a method to Process to get uid for a pid.
The am command is now the one that takes care of opening the target file,
handling the opened file descriptor to the process that will be profiled.
This allows you to send profile data to anywhere the shell can access, and
avoids any problems coming up from the target process trying to open the
file.
Track the foreground CPU time of an activity so that we can tell if apps are
spending more time in the background compared to foreground.
Update power profile values for screen backlight and GPS.
Fix some javadoc bugs (milliseconds vs. microseconds).
Before, the variants of MemoryFile.MemoryInputStream.read() would throw
IOException or IndexOutOfBoundsException if EOF was encountered
before the requested number of bytes was read. This violates
the contract of InputStream.read().
This patch makes read() return the number of bytes available, if any.
If already at EOF, -1 is returned. The patch also adds new tests,
which checks cases where MemoryFile.MemoryInputStream.read()
should throw IndexOutOfBoundsException or return -1. several of these
tests failed with the old code and pass now.
This fixes http://b/issue?id=1881894
This allows content providers to use in-memory data to implement
ContentProvider.openAssetFile(), instead of just normal files
and sockets as before.
To test cross-process use of AssetFileDescriptors for MemoryFiles,
a test content provider and a client for it are added to
AndroidTests.
Fixes http://b/issue?id=1871731
As reported in http://b/issue?id=1398215 MemoryFile did not
munmap(2) the ashmem region after closing it. This
causes the process to leak virtual address space.
This change fixes the problem by calling munmap(2) in
close(). The unmapping is done by a helper method deactivate().
The change also replaces the use of an int for the
file descriptor with a FileDescriptor object to
make sure that we keep track of when the file descriptor
has been closed. I chose to implement it this way because I
will need decativate() and a FileDescriptor object in an
upcoming change that allows sending MemoryFile file
descriptors between processes.
The change also adds a number of tests for the behavior
of close(). The testCloseRead() and testCloseWrite() fail
with the old MemoryFile implementation, and testCloseLeak()
causes a segfault. They all pass now.
These native methods in android.os.MemoryFile throw IOException but their
Java declarations did not include "throws IOException":
native_open(),native_mmap(),native_read(),native_write(),native_pin()
The MemoryFile(String,int) constructor calls native_open and
native_mmap, but does not declare that it throws IOException. The other
Java methods that call the native methods do actually declare that they
throw IOException.
This means that any code that created memory files could throw
an IOException, without knowing about it.
This changes adds "throws IOException" to the native methods and to
the constructor. The constructor change changes the public API, but
maintains binary compatibility. There is some precedent for making
source incompatible source API changes for this sort of thing
(see https://mondrian.corp.google.com/changelist/124214-p9).
The change also makes the native methods static, which
they seem to have been intended to be, as indicated by the
second parameter to the native implementations being named
"clazz".
This requires changes to the Compatibility Test Suite to catch the exceptions.
This is done in https://android-git.corp.google.com/g/2617
Unfortunately that change must be submitted together with this one in order
not to break the build.
Fixes http://b/issue?id=1881829
Merge commit 'd50a458bb291801ab9fdc119301bc7b84b42a6e3'
* commit 'd50a458bb291801ab9fdc119301bc7b84b42a6e3':
Fix a major bug in Bundle when unparcelling from AIDL.
This adds the PowerProfile class and data file that provides power consumption numbers
for different subsystems. Also added Audio/Video subsystems to track on a per UID basis.
There was a serious problem in the Bundle(Parcel) and readFromParcel() methods,
where it wasn't doing the copying of the Parcel that Parcel.readBundle() does
and is a basic requirement for it to work correctly.
This re-arranges the code to make all of these functions (hopefully) correct.
Also fix a problem in Parcel where we were not duping fds when copying data from
one Parcel to another.
Merge commit '3e458241d9930465a20a861ecb42744355d48e48'
* commit '3e458241d9930465a20a861ecb42744355d48e48':
process: Add setProcessGroup() hidden API call to set the cgroup of
Now old applications will automatically be granted it. Also renamed it from
SDCARD_WRITE to WRITE_SDCARD to be consistent with our other permissions,
and re-arranged how we do targetSdkVersion to actually be usuable for this
kind of stuff.
Note that right now this results in basically all apps being given the
WRITE_SDCARD permission, because their targetSdkVersion is not set. I will
be dealing with that in a future change.
