When a binder service's main thread joins the thread pool
it retains its name (whatever the exec name was), which is
very confusing in systrace.
we now rename that thread just like its friends in the
thread pool.
Change-Id: Ibb3b6ff07304b247cfc6fb1694e72350c579513e
This is to help implementation of bug #8181262 and maybe
bug #8181261
Note the current code has not yet been tested; it is only
known to compile at this point.
Change-Id: I489674c96d0d3fc0ddacc92611931a19a9ee5230
MemoryHeapBase::getBase() returns MAP_FAILED in case or
OOM, not null which is what SF was checking against.
This addresses one of the issues of bug 7230543.
Bug: 7230543
Change-Id: I763a88f64a2f9ff75eb139cfbaf9a1a9746c5577
this change introduces a new class LightFlattenable<> which is
a protocol to flatten simple objects that don't require
binders or file descriptors; the benefit of this protocol is that
it doesn't require the objects to have a virtual table and give us
a consitant way of doing this.
we also introduce an implementation of this protocol for
POD structures, LightFlattenablePod<>.
Parcel has been update to handle this protocol automatically.
Sensor, Rect, Point and Region now use this new protocol.
Change-Id: Icb3ce7fa1d785249eb666f39c2129f2fc143ea4a
Every IBinder object can accept a new transaction to tell it that
it might want to reload system properties, and in the process
anyone can register a callback to be executed when this happens.
Use this to reload the trace property.
This is very much ONLY for debugging.
Change-Id: I55c67c46f8f3fa9073bef0dfaab4577ed1d47eb4
MemoryHeapPmem is not used any longer. PMEM is not a supported
type of memory by the system anymore. a particular device might
use PMEM and need something like MemoryHeapPmem, in this case this
should be implemented in device specific code (HAL).
This will most likely break older no longer supported targets.
Change-Id: I434e4291219950018de8b793b0403bb2d92dd5cc
Services now must explicitly opt in to being accessed by isolated
processes. Currently only the activity manager and surface flinger
allow this. Activity manager is needed so that we can actually
bring up the process; SurfaceFlinger is needed to be able to get the
display information for creating the Configuration. The SurfaceFlinger
should be safe because the app doesn't have access to the window
manager so can't actually get a surface to do anything with.
The activity manager now protects most of its entry points against
isolated processes.
Change-Id: I0dad8cb2c873575c4c7659c3c2a7eda8e98f46b0
Switching activity stacks
Cache ContentProvider per user
Long-press power to switch users (on phone)
Added ServiceMap for separating services by user
Launch PendingIntents on the correct user's uid
Fix task switching from Recents list
AppWidgetService is mostly working.
Commands added to pm and am to allow creating and switching profiles.
Change-Id: I15810e8cfbe50a04bd3323a7ef5a8ff4230870ed
Was mistakenly assuming that Parcel::writeFileDescriptor took
ownership of the fd that was passed in. It does not!
Added some comments and a default parameter to allow the caller
to specify whether it wishes the Parcel to take ownership.
Bug: 5563374
Change-Id: I5a12f51d582bf246ce90133cce7690bb9bca93f6
There is no difference and has never really been a difference
between local-only and remotable CursorWindows. By removing the
distinction officially in the API, we will make it easier to
implement CrossProcessCursor correctly. CrossProcessCursor
is problematic currently because it's not clear whether a call
to getWindow() will return a local-only window or a remotable window.
As a result, the bulk cursor adaptor has special case handling
for AbstractWindowedCursors vs. ordinary CrossProcessCursors
so that it can set a remotable window before the cursor fills it.
All these problems go away if we just forget about local-only
windows being special in any way.
Change-Id: Ie59f517968e33d0ecb239c3c4f60206495e8f376
Bug: 5332296
The memory dealer introduces additional delays for reclaiming
the memory owned by CursorWindows because the Binder object must
be finalized. Using ashmem instead gives CursorWindow more
direct control over the lifetime of the shared memory region.
The provider now allocates the CursorWindows and returns them
to clients with a read-only protection bit set on the ashmem
region.
Improved the encapsulation of CursorWindow. Callers shouldn't
need to care about details like how string fields are allocated.
Removed the compile-time configuration of string and numeric
storage modes to remove some dead weight.
Change-Id: I07c2bc2a9c573d7e435dcaecd269d25ea9807acd
Bug: 5332296
The code is functionally equivalent, but a little more efficient
and much easier to maintain.
Change-Id: I90670a13799df05831843a5137ab234929281b7c
This reverts commit 56c58f66b97d22fe7e7de1f7d9548bcbe1973029
This CL was causing the browser to crash when adding bookmarks, visiting the bookmarks page, and sharing pages (see bug http://b/issue?id=5369231
This is intended to absorb the cost of the IPC
to the permission controller.
Cached permission checks cost about 3us, while
full blown ones are two orders of magnitude slower.
CAVEAT: PermissionCache can only handle system
permissions safely for now, because the cache is
not purged upon global permission changes.
Change-Id: I8b8a5e71e191e3c01e8f792f253c379190eee62e
The offset that is used in the creation of the MemoryHeapBase must be saved, so
that it can be used to recreate the Heap when an IMemory object is passed
across process boundary through the binder.
Change-Id: Ie618fb5c0718e6711f55ed9235616fd801e648dc
Signed-off-by: Anu Sundararajan <sanuradha@ti.com>
Signed-off-by: Iliyan Malchev <malchev@google.com>
There are two areas that have changed to eliminate the assumption that
local jobject references are both canonical and persistent:
1. JavaBBinderHolder no longer holds onto and reuses it parent object
reference per se. Since the underlying JavaBBinder object holds a
real global ref, this was redundant anyway. Now, for purposes of its
transient need to perform JNI operations, it simply uses the current
jobject ref(s) passed during method invocation, and no longer attempts
to hold these refs beyond the scope of a single invocation.
2. Binder obituaries no longer assume that a jobject reference to a
recipient will always compare == as a 32-bit value with any future
reference to the same object. The implementation now asks Dalvik
whether object references match.
This amended patch fixes the earlier bug around races between
remote binder death cleanup and local explicit unregistration of
VM-side death recipients.
Bug 2090115
Change-Id: I70bd788a80ea953632b1f466f385ab6b78ef2913
There are two areas that have changed to eliminate the assumption that
local jobject references are both canonical and persistent:
1. JavaBBinderHolder no longer holds onto and reuses it parent object
reference per se. Since the underlying JavaBBinder object holds a
real global ref, this was redundant anyway. Now, for purposes of its
transient need to perform JNI operations, it simply uses the current
jobject ref(s) passed during method invocation, and no longer attempts
to hold these refs beyond the scope of a single invocation.
2. Binder obituaries no longer assume that a jobject reference to a
recipient will always compare == as a 32-bit value with any future
reference to the same object. The implementation now asks Dalvik
whether object references match.
Bug 2090115
Change-Id: If62edd554d0a9fbb2d2977b0cbf8ad7cc8e2e68d
let cursor window size be set per device in device resources file.
default is 1MB.
for SR, it is 2MB.
it can be set to any value (in kB) in the device resource
strings.xml file
Change-Id: I67b1d04a5c9fc18b0cd4da6184d0b814b64d89e9
This was causing stack stitching problems where a one-way call with
violations followed by a two-way call without violations was getting
the previous one-way call's violation stack stitched on to the second
caller's stack.
The solution is a little more indirect than I would've liked
(preserving the binder's onTransact flags until enforceInterface) but
was seemingly necessary to work without changing the AIDL compiler.
It should also be sufficiently cheap, since no new calls to
thread-local IPCThreadState lookups were required. The additional
work is just same-thread getter/setters on the existing
IPCThreadState.
Change-Id: I4b6db1d445c56e868e6d0d7be3ba6849f4ef23ae
Add native Parcel methods analogous to the Java versions.
Currently, these don't do much, but upcoming StrictMode work changes
the RPC calling conventions in some cases, so it's important that
everybody uses these consistently, rather than having a lot of code
trying to parse RPC responses out of Parcels themselves.
As a summary, the current convention that Java Binder services use is
to prepend the reply Parcel with an int32 signaling the exception
status:
0: no exception
-1: Security exception
-2: Bad Parcelable
-3: ...
-4: ...
-5: ...
... followed by Parceled String if the exception code is non-zero.
With an upcoming change, it'll be the case that a response Parcel can,
non-exceptionally return rich data in the header, and also return data
to the caller. The important thing to note in this new case is that
the first int32 in the reply parcel *will not be zero*, so anybody
manually checking for it with reply.readInt32() will get false
negative failures.
Short summary: If you're calling into a Java service and manually
checking the exception status with reply.readInt32(), change it to
reply.readExceptionCode().
Change-Id: I23f9a0e53a8cfbbd9759242cfde16723641afe04
Merge commit 'efcf68aa1fd7fcfd52cf3d2837ed8db8e797194b'
* commit 'efcf68aa1fd7fcfd52cf3d2837ed8db8e797194b':
Start of work on passing around StrictMode policy over Binder calls.
This is (intendend to be) a no-op change.
At this stage, Binder RPCs just have an additional uint32 passed around
in the header, right before the interface name. But nothing is actually
done with them yet. That value should right now always be 0.
This now boots and seems to work.
Change-Id: I135b7c84f07575e6b9717fef2424d301a450df7b
