- Use ordered broadcast to allow receivers to set a result code.
- Ack SMS with result code.
- New RIL command to report memory status.
- Fixed a typo in a Gservices setting.
- Merge in CL 137895 (hold a wake lock while broadcasting SMS_RECEIVED).
Ignore touch up events that happen after a gesture was cancelled. This fix also improves performance by ignoring move events that are within the touch threshold.
Only update the popup window when it is shown. This avoids throwing an NPE in PopupWindow.
A PopupWindow is only aware of its content view after being shown.
PhoneStateListener events like LISTEN_CALL_STATE_CHANGED,
have privacy information like phone numbers and hence,
need to be protected with a permission. The permission
READ_PHONE_STATE is used for this purpose. Use the permission
trick to ensure backward compatability.
If the list is opaque and its background is not, then we want to fill a solid rect where the dividers should be when they are skipped for non-selectable items. When the list is opaque and the background is also opaque, there is no need to draw something in lieu of the dividers since the background will do it for us.
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
Remove the else clause and always get the list of requested permissions first before adding the permissions obtained via
the shared user id.
Also change an if condition and comments for better readability
having the wrong version. I made the loader print a message to
the log for this, and made the calling code disable gestures
for the listview instead of crashing.
* changes:
Cause the icon drawables to animate automatically by calling setVisible false and then true on the drawables. For an AnimationDrawable, this will trigger the desired behavior of 'automatically' starting the animation, which should have been working to begin with according to the intended design of AnimationDrawable (see http://b/1878430 for my description of my correspondence with Romain). For Donut we'll just do this to work around it, but for a later release we need to decide a better story.
false and then true on the drawables. For an AnimationDrawable, this will
trigger the desired behavior of 'automatically' starting the animation,
which should have been working to begin with according to the intended
design of AnimationDrawable (see http://b/1878430 for my description of
my correspondence with Romain). For Donut we'll just do this to work
around it, but for a later release we need to decide a better story.
The algorithm for this is currently very simple: all persistent processes are
always in the normal scheduling group, all other processes are normal if their
oom_adj is as good or better than VISIBLE, otherwise they are in the background
group.
Note that this currently results in a fair number of log messages about not
being able to change the group, since the system process does not have
permission to do so. Once a kernel fix is in, these will go away and the code
will start working.
