It looks like there was a subtle bug where Process.setOomAdj() could
return false just because the given process doesn't exist, even though
it is documented to only return false if OOM killing is not supported
at all. This would cause the activity manager to fall into its code
path of trying to clean up processes itself, which it does a much
poorer problem at. I am thinking we may be seeing this problem more
now that the activity manager is killing background processes itself
when there are too many of them.
In addition, this change cleans up and reduces some of the logging
around killing processes.
Finally, try to improve process LRU management a bit by taking
into account process dependencies. Any dependent processes are
pulled up in the LRU list with the processes that is actually
moving. Also, we bring a process up if someone accesses its content
provider.
Change-Id: I34ea161f839679345578ffe681e8d9c5d26ab948
MessageQueue now uses a socket for internal signalling, and is prepared
to also handle any number of event input pipes, once the plumbing is
set up with ViewRoot / Looper to tell it about them as appropriate.
Change-Id: If9eda174a6c26887dc51b12b14b390e724e73ab3
If we're grabbing references to many strings in a loop, we have to
remove our local references so we don't overflow the VM's local
reference table.
Also, use env->ExceptionCheck() instead of checking for NULL value
returns on trying to allocate new items.
Bug: 2663816
Change-Id: I9cb5e17f6181dbb2f2c03d53841b2f5d8ab10f68
This is a rough sketch of the new pure-native API, which you can
use through a NativeActivity in your manifest (no Java code in
the .apk needed!).
Intentionally no docs yet, the API is still being seriously
messed with. But it works.
Change-Id: I0e916d58a0d159ecaf3689e41834eb8dc681c0c0
user toggles BT state.
Bug:2607218
This happens when Bluetooth is turned off, and when the headset is
still trying to connect. We get the connection result of
attempt before Bluetooth was toggled. We need to ignore this result.
Change-Id: I023406ec6d59880754ca4f1de676d0dce71b13c6
Merge commit '15feb4defc61c7bded6fdd3ea1c3781f25666275' into kraken
* commit '15feb4defc61c7bded6fdd3ea1c3781f25666275':
Remove code to pass the nonexistant lockprofsample flag to Dalvik.
this is used in a few places to get access to the android.view.Surface
native surface. use a macro instead. Also rename the field to mNativeSurface.
Change-Id: I1c6dea14abd6b8b1392c7f97b304115999355094
Use the same procedure (select() with a short timeout) used by "logcat -d",
which doesn't seem to have any blocking problems.
Bug: 2569403
Change-Id: Ia27bb4207919a1288716b41a007b4b4b52f8e90a
Merge commit 'c1420832a8f9c7fa62b143ce63c71062b3969c1b' into kraken
* commit 'c1420832a8f9c7fa62b143ce63c71062b3969c1b':
Change TrafficStats to a new JNI implementation.
Also change phone's ConnectionStateTrackers to use it directly,
rather than through the INetStat binder interface.
Bug: 2578938
Change-Id: I8858e2609cbec3be845a0ce5178cb03f67e01b41
Merge commit 'b8fc825dfafd8792a4d9daead9d3d1b4a4b55de5' into kraken
* commit 'b8fc825dfafd8792a4d9daead9d3d1b4a4b55de5':
Fix crash while turning bluetooth on, due to a race condition.
Bug: 2561150
Race condition: We were basing whether the event loop is
running or not on whether nat->pollData was null or not.
In rare cases, eventLoopMain would have not started,
isEventLoopRunning returns true; java side makes a dbus call
and the watches get set to null, causing a crash in
dbus_connection_set_watch_functions when eventLoopMain starts.
Change-Id: I863f182185a8e956fd53cb58783b7fe0ecfb2ddb
This is kinda gross, but I can't find a good way to check for the
existence of gettid(), except by finding its syscall number. Then
might as well just use it rather than hope gettid's around, as it's
not in sim-eng.
Change-Id: Ieb7b39426dec08bd715b6fe1a9ab5b2801bdf775
This mimics what we do already for SQLiteDatabase's db_operation and
ContentProvider's content_query_operation and
content_update_operation: over a threshold things are always logged,
and under which they're sub-sampled.
Change-Id: Ia0280b9b07b336ee88b17be2a31a7af0fd7c5770
If the Binder is allocated but its constructor does not run for some
reason, then Binder.init() will not be called. Since the object was
allocated, it is still eligible for finalization. Eventually when
the finalizer runs and calls Binder.destroy(), it will have a NULL
binder holder pointer. Previously this would cause Binder.destroy()
to attempt to decrement a reference count on a NULL pointer.
Now we check and ignore the binder if it does not have a valid
holder pointer.
Bug: b/2533956
Change-Id: Ifc2729b2f2abe8bceea5a0645ae0a4c1575b7846
when a surface was returned from a remote process through the binder we
would leak its resources until a GC happened.
implement writeToParcel to release the source when PARCELABLE_WRITE_RETURN_VALUE
is set
Change-Id: I6a9fa369b0d164a9ca1229b8a2944d3c132a3720
