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
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.
* changes:
Remove dimmed background (and accompanying animation) for global search, since we should never really see that background anyway, and I suspect the animation is using a significant amount of CPU.
* changes:
Fixes NPE in ListViews with non-selectable items. This was caused by a weird initialization issue in ListView and AbsListView: a private final field instanciated in the declaration in ListView was used in AbsListView<init> via an overriden method and that field was somehow null at this time. This fix moves the instanciation at a later point.
This eliminates the requirement that all sensors share a single file descriptor.
This, along with concurrent changes in other projects, fixes bugs b/1614524 and b/1614481
Signed-off-by: Mike Lockwood <lockwood@android.com>
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.
This adds a new window type that is a surface that sits between the
current media type and the application window, in theory allowing you
to have two surface views in your hierarchy and control their
Z-ordering. There is also another hidden API on SurfaceView to set
the type of your window.
All a big hack, but for the good of the commonwealth!
SQLLite limit is not only used to limit the returned number of data.
It can be used to do an offset query.
For example, "SELECT * FROM table LIMIT 100, 10", will return the
data of index in the range of [100, 100 + 10).
This change set enable this kind of useage.
This is also more efficient than use "cursor.moveToPosition()".
In my experiment, I query 1000 items in batch mode, i.e.,
get 20 items out of 1000 each time.
Time of using LIMIT clause: 626ms
Time of useing "cursor.moveToPosition()": 2062ms
