* commit 'd1c87d37025c49f6a47fe43328572da495ff04c1':
Binder: Fix some valgrind errors.
Binder: Don't cast directly from a pointer to binder_uintptr_t
Binder: Disable attemptIncStrongHandle
* commit '58242fc29881cf29d56ee6e5fde6d73b16d0b67c':
ServiceManager: Implement PING_TRANSACTION
ServiceManager: Use 32/64 bit types from new binder header
Binder: Use 64 bit pointers in 32 processes if selected by the target
Add BINDER_IPC_32BIT to CFLAGS unless TARGET_USES_64_BIT_BINDER is true
Binder: Make binder portable
ServiceManager: Fix the binder interface
ServiceManager: Store handles in uint32_t instead of void *
ServiceManager: Generic Fixes
ServiceManager: Add extra error handling
ServiceManager: Fix Android.mk
ServiceManager: Make use of kernel exported structures
* commit 'c5294424386bedad2a240074d0845999f28e662d':
Binder: Fix some valgrind errors.
Binder: Don't cast directly from a pointer to binder_uintptr_t
Binder: Disable attemptIncStrongHandle
* commit 'd1c87d37025c49f6a47fe43328572da495ff04c1':
Binder: Fix some valgrind errors.
Binder: Don't cast directly from a pointer to binder_uintptr_t
Binder: Disable attemptIncStrongHandle
* commit '6f286114ec1d597f3dae987bba6e72dbbc404e32':
Revert "Fix "Binder: Make sure binder objects do not overlap" to work old binder kernel interface"
This branch has the new driver interface so it should not have this change.
This reverts commit 6790329358.
Change-Id: I9b6d0d653d98dbdb521ef964c5e7c2f14859d340
When using 64 bit binder pointers, only initializing the 32 bit
handle, in a stack allocated struct, will pass uninitialized stack
data to the kernel and other processes.
Change-Id: I3432d9d36bb251d8ddb0a863661aeb80aabb3d92
When using the 64 bit binder interface from a 32 bit process the
pointer may get sign extended and cause the kernel to fail to read
from it.
Change-Id: I90fcf53880e2aa92e230a9723f9b3f7696170e32
The driver does not support BC_ATTEMPT_ACQUIRE and will return an error.
IPCThreadState does not handle driver errors, and will resend the failed
command blocking all other commands.
Change-Id: I643986037341821b27b62dc82df933844f4842b8
Fix warnings related to casting pointers to ints, using %d or %ld to
print size_t/ssize_t, and unused parameters.
Change-Id: I7a13ba83d402952989c1f795cd9e880a95b98d9e
* commit 'c93865de80a16d3638936890fb42eb175284044b':
ServiceManager: Implement PING_TRANSACTION
ServiceManager: Use 32/64 bit types from new binder header
Binder: Use 64 bit pointers in 32 processes if selected by the target
Add BINDER_IPC_32BIT to CFLAGS unless TARGET_USES_64_BIT_BINDER is true
Binder: Make binder portable
ServiceManager: Fix the binder interface
ServiceManager: Store handles in uint32_t instead of void *
ServiceManager: Generic Fixes
ServiceManager: Add extra error handling
ServiceManager: Fix Android.mk
ServiceManager: Make use of kernel exported structures
Changes include
- Binder attempts to cast pointers to a int datatype
which is not sufficient on a 64-bit platform.
- This patch introduces new read/write functions into
Parcel that allow pointers to be written using the
uintptr_t datatype for compile-time data type size
selection.
- Change access specifier for the methods above.
- Binder uses the 64bit android_atomic_release_cas64
(aka cmpxchg)
Change-Id: I595280541e0ba1d19c94b2ca2127bf9d96efabf1
Signed-off-by: Matthew Leach <matthew.leach@arm.com>
Signed-off-by: Serban Constantinescu <serban.constantinescu@arm.com>
Initialize local variable to avoid syscall ioctl warning.
Change-Id: I33a90917856018a8527305bb362948ef03bd734c
Origin-Change-Id: I022ebce40b3774a815639a5af34bc7aeb2489936
Signed-off-by: Jin Wei <wei.a.jin@intel.com>
Signed-off-by: Jian Luo <jian.luo@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Author-tracking-BZ: 62797
Fallout from the Flattenable change, update all its uses.
Additionnaly, fix/tighten size checks when (un)flatten()ing
things.
Removed the assumption by some flattenables (e.g.: Fence)
that the size passed to them would be exact (it can
and will be larger in some cases)
The code in Parcel is a bit complicated so that we don't
have to expose the full implementation (and also to
keep the code smallish).
Change-Id: I0bf1c8aca2a3128491b4f45510bc46667e566dde
This is currently safe to do only for processes that disallow any binder
threads to be created: setThreadPoolMaxThreadCount(0).
Change-Id: I8a27f3cf26f4d51edb7f222af487ac256cbcab65
Adds logging to help determine what is happening to the /dev/binder
fd and dump the process state when it happens.
bug: 8912673
Change-Id: I2aa0c66fc499e91e0bf9ee4ae20404bec35adc82
- added a ctor that updates and dumps the stack immediately
- added a "logtag" parameter to dump()
Change-Id: Ie51c256071d282591752243bdb4f68cf9ff8829d
Third-party libraries are currently trying to use the
MemoryBase constructor but failing because we fixed the
definition of ssize_t. This is a stop-gap for users of
this private API until we can get them fixed.
Bug: 8253769
Change-Id: Ie7c86f45fa39cb53539cab0ffe8585a585656714
Third-party libraries are currently trying to use the
MemoryBase constructor but failing because we fixed the
definition of ssize_t. This is a stop-gap for users of
this private API until we can get them fixed.
Bug: 8253769
Change-Id: I8a19770f3252d88ee87023fde625cc6289924b0d
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
When the app_process is shutting down the main thread will close the
binder fd while pool threads are executing an ioctl (in
IPCThreadState::stopProcess called by AppRuntime::onStarted in
app_main.c).
The binder driver will then return all pending calls in ioctl
without any error and with a command. One of the threads gets a
BR_SPAWN_LOOPER which will create a new thread (the other thread
gets a BR_NOOP). This new thread then calls
vm->AttachCurrentThread. Usually this results in a log entry with
"AndroidRuntime: NOTE: attach of thread 'Binder Thread #3' failed",
but sometimes it also causes a SIGSEGV. This depends on the timing
between the new thread an the main thread that calls DestroyJavaVM
(in AndroidRuntime::start).
If IPCThreadState.cpp is compiled with "#define LOG_NDEBUG 0" the
pool thread will loop and hit the
ALOG_ASSERT(mProcess->mDriverFD >= 0) in
IPCThreadState::talkWithDriver.
Crashes like this has been seen when running the am command and
other commands that use the app_process.
This fix makes sure that any command that is received when the driver
fd is closed are ignored and IPCThreadState::talkWithDriver instead
returns an error which will cause the pool thread to exit and detach
itself from the vm. A check to avoid calling ioctl to a fd with -1
was also added in IPCThreadState::threadDestructor.
Another solution might be to change the binder driver so that it
returns an error when the fd is closed (or atleast not a
BR_SPAWN_LOOPER command). It might also be possible to call exit(0)
which is done when System.exit(0) is called from java.
Change-Id: I3d1f0ff64896c44be2a5994b3a90f7a06d27f429
The Java implementation of writing the RPC response header
calculates the length of the header including the 4 bytes
specifying the header length but the native implementation
excludes the 4 bytes specifying the length from the header
length.
The native implementation has been aligned to the Java impl.
Change-Id: I325bf272a63152d8fded4cf4e51a906b5a9bfe19
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
Remove C++ APIs androidSetThreadSchedulingGroup and
androidGetThreadSchedulingGroup, and the ANDROID_TGROUP_* constants.
Former callers of these should now use the C APIs set_sched_policy and
get_sched_policy, and the SP_* constants.
Note: debug.sys.noschedgroups is not supported by the C APIs,
this needs to be discussed.
Change-Id: I32bbfc539ef4090faf9ef0320380e8cca9eae07c
As part of scheduling policy cleanup, remove or isolate
all references to the scheduling policy APIs.
Change-Id: Ia1ea2fe711a399039f25217309e061267744b856
prctl(PR_SET_NAME) limits to 15 characters. Before we had names like
"Binder Thread #" and the counter was cut off :-( Also remove redundant
"thread" at end of name; it's always a thread.
Change-Id: I1f99c2730ba0787ed9b59c15914356cddf698e2f
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
Currently, madvise(MADV_REMOVE) is called after deallocation.
Another thread might allocate (and even write) the same region between
deallocation and madvise(), in which case the new thread will fail to read
what it have written. So, call deallocate() after madvise(MADV_REMOVE).
Bug: 5654596
Change-Id: I26f36cd6013de499090768a0ddc68206a4a68219
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
On user-debug and eng builds, you can set the
"db.log.slow_query_threshold" system property to queries that
take longer than the specified number of milliseconds.
Set it to 0 to log all queries.
This property has been around for a while but it was implemented
poorly. In particular, it *changed* the behavior of the query
by calling getCount() while holding the Db connection.
In normal operation, the query will not actually run until later.
By putting the timing logic into fillWindow() instead, we ensure
that we only measure queries that actually ran. We also capture
cases where the cursor window gets filled multiple times.
Bug: 5520301
Change-Id: I174f5e1ea15831a1d22a36e9a804d7755f230b38
Bug: 5520301
When an application requests a row from a SQLiteCursor that
is not in the window, instead of filling from the requested
row position onwards, fill from a little bit ahead of the
requested row position.
This fixes a problem with applications that seek backwards
in large cursor windows. Previously the application could
end up refilling the window every time it moved back
one position.
We try to fill about 1/3 before the requested position and
2/3 after which substantially improves scrolling responsiveness
when the list is bound to a data set that does not fit
entirely within one cursor window.
Change-Id: I168ff1d3aed1a41ac96267be34a026c108590e52
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
Updated the command name lists, and masked off the additional bits in
the command word when doing the name lookup.
Made descriptor values easier to grep for and consistent with kernel
output (i.e. decimal rather than hex). Attempt to show transaction
descriptors as such (they're in a union with a pointer).
Also, the writeLines() function in Static was using a no-op
logging call to write an iovec. It looks like all callers are using
N=1, so I just added a log for the first string.
Bug 5155269
Change-Id: I417b8d77da3eb6ee1d2069ba94047210f75738bc
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>
We now write battery history directly into a buffer, instead of
creating objects. This allows for more efficient storage; later
it can be even better because we can only write deltas.
The old code is still there temporarily for validation.
Change-Id: I9707d4d8ff30855be8ebdc93bc078911040d8e0b
HAVE_ANDROID_OS was defined as "1" for targets, but never defined as "0"
for non-targets. Changing them to #ifdef should be safe and matches
all the other uses of HAVE_ANDROID_OS throughout the system.
Change-Id: I82257325a8ae5e4e4371ddfc4dbf51cea8ea0abb
If writeString8 is called with the following sequence:
writeString8(String8(""));
writeString8(String8("TempString"));
Then in the readString8, the 2nd String i.e. "TempString" is not read,
instead an empty string is read.
The bug comes because of the write call for String8("") where there are
no String bytes present. In the write Statement, an extra ‘\0’ is
written. During the Marshalling, Following bytes are written:
1 2 3 4 5 ...
0x0 0x0 0xB ‘T’ ‘e’ ...
The readString8 function has a check that, if String length is 0, don’t
read anything. So the first byte is read as the length for the first
string. The second byte i.e. ‘\0’ is read as the length for the second
string and hence the second string becomes empty too.
Change-Id: Id7acc0c80ae16e77be4331f1ddf69ea87e758420
grief from people who think this message is bad news.
but in reality, this message is really just an informational message
to aid in debugging
Change-Id: I1a2ab1666a27adb7d3fd210528b2c5218640d53d
- New feature to "am monitor" to have it automatically launch
gdbserv for you when a crash/ANR happens, and tell you how to
run the client.
- Update dumpstate to match new location of binder debug logs
- Various commented out logs that are being used to track down
issues.
Change-Id: Ia5dd0cd2df983a1fc6be697642a4590aa02a26a5
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
Now, when Thread A has a strict mode policy in effect and does a
Binder call to Thread B (most likely in another process), the strict
mode policy is passed along, but with the GATHER penalty bit set which
overrides other policies and instead gathers all offending stack
traces to a threadlocal which are then written back in the Parcel's
reply header.
Change-Id: I7d4497032a0609b37b1a2a15855f5c929ba0584d
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
