We can't use Parcel.writeValue() to write the ParcelFileDescriptor, otherwise
it leaks when returning the value to the caller (the flag gets lost). Change
the way DropBoxManager.Entry gets serialized so that it uses a bit of its own
flags value to track whether the data is a byte[] or a ParcelFileDescriptor.
Modify the dropbox unit test to add extensive checking of Entry serialization
and deserialization under various circumstances, and to include a regression
test to ensure that FD leaking doesn't happen.
Bug: 2847738
Change-Id: I4ccd17dd03ffab234340cd359e6f3510fdf81193
Merge commit 'bc4fcec70f841156f5e7fd16224e88cb3d551ca7'
* commit 'bc4fcec70f841156f5e7fd16224e88cb3d551ca7':
Only print out wake locks in the if the wakelock was held.
Merge commit 'c78f9a0e1ba931988144a52c54bc05a7e1521f67'
* commit 'c78f9a0e1ba931988144a52c54bc05a7e1521f67':
COMMENT ONLY change to add some warnings about ParcelFileDescriptor
Merge commit '29e25bd3418b04e395119bf99abe92898830a796' into gingerbread-plus-aosp
* commit '29e25bd3418b04e395119bf99abe92898830a796':
Only print out wake locks in the if the wakelock was held.
Merge commit '3c1363beec9c142c062d8704b8bef4230b42eae5' into gingerbread-plus-aosp
* commit '3c1363beec9c142c062d8704b8bef4230b42eae5':
COMMENT ONLY change to add some warnings about ParcelFileDescriptor
Merge commit '2f0dc6d9f50ceece294e9db393583e655d3bf781' into gingerbread
* commit '2f0dc6d9f50ceece294e9db393583e655d3bf781':
COMMENT ONLY change to add some warnings about ParcelFileDescriptor
Merge commit '527e9c8f0471666b5b1c461f1a8a710192208e70'
* commit '527e9c8f0471666b5b1c461f1a8a710192208e70':
StrictMode: avoid an allocation in common case
* Unhide StorageService class; hide all the USB-related items
* Add application-visible API to StorageManager for OBB files
* Add class for parceling OBB info across binders (ObbInfo)
* Add a JNI glue class to libutils/ObbFile (ObbScanner)
* Add API to MountService to deal with calling into vold and checking
permissions
Change-Id: I33ecf9606b8ff535f3a2ada83931da6bbef41cfd
Make the initialValue() of the ThreadLocal be null, so checking it doesn't
cause one to be created in the case of an RPC call not using StrictMode.
Change-Id: I3ea19ce444a1b3c39a6e53c5cb5d4faf4b07a6c8
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
This adds the ability to generate a trivial heap dump on demand. If
the appropriate system properties aren't set, the output file will
instead contain instructions for enabling them.
The data returned by get_malloc_leak_info() is processed and written
to the specified file. The output looks something like:
Android Native Heap Dump v1.0
Total memory: 2981301
Allocation records: 2152
z 1 sz 65557 num 1 bt 8010dd78 afd12618 ...
z 1 sz 52008 num 3 bt 8010dd78 afd12618 ...
z 1 sz 24428 num 1 bt 8010dd78 8010de84 ...
...2149 more...
END
(the "..." is actually the remaining entries in the stack backtrace;
I truncated it here)
"z" indicates whether the allocation was made pre- or post-zygote,
"sz" is the size allocated, and "num" is the number of allocations
made of that size with the specified backtrace.
Change-Id: I2d60f07444fce5f7178b3f51c928c8faa0b051bd
This was mostly cloned from the "am profile" implementation. It's
intended to replace the old "kill -10" approach used by "runhat".
We could really use a native heap dump, so I pass a "managed"
flag through that indicates whether we want to dump the native or
managed heap. We don't currently have a native heap dump-to-file
function, so it currently just logs a warning.
(android.ddm.DdmHandleNativeHeap.getLeakInfo is a good start -- it
copies /proc/maps and then calls get_malloc_leak_info to get some
goodies. Needs some formatting to make it human-readable. I didn't
want to cram all that into this change.)
It would be useful if "am" didn't exit until the heap dump operation
completed, but I'm not sure how to do that.
Bug 2759474.
Change-Id: I46bc98067738d8c72ac0fc10002ca67bb4929271
The guard is compiled out by default because it adds overhead to
android.os.Process.setPriority().
Change-Id: Ibb2a648c6349b381abb7ae62a358888b04fba871
Added ANRs handling.
Added event injection.
Fixed a NPE ActivityManagerServer writing ANRs to the drop box.
Fixed HOME key interception.
Fixed trackball reporting.
Fixed pointer rotation in landscape mode.
Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
We now clear the battery stats when unplugging after the
battery is full. This allows us to use the "total" stats as
a new "since last charged" stat. Total is gone. I never used
it, it was worthless. Since last charged is a lot more
interesting.
The battery history now collects a lot more stats, and keeps
control over how much it can collect. Printing is now more
descriptive.
The kinds of stats have been renamed to SINCE_UNPLUGGED and
SINCE_DISCHARGED. The other two stats are still there, but
no longer printed; a future change will eliminate them
completely along with all of their state.
Change-Id: I4e9fcfcf8c30510092c76a8594f6021e9502fbc1
Merge commit '46b9ac0ae2162309774a7478cd9d4e578747bfc2' into gingerbread
* commit '46b9ac0ae2162309774a7478cd9d4e578747bfc2':
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
Modify OOM adj classes a bit, to take into account the new
heavy weight app type, and give "foreground services" their
own category to have a bettery chance to manager them when
things go wrong.
Also add some new code to battery stats to keep a history
of changes to the battery level.
Change-Id: I29f5ab6938777e1a7eafd7d8c38b5e564cc9f96a
This is a new public API for developers to opt-in to strict rules
about what they're allowed to do on certain threads. (this is the
public face of the @hide dalvik.system.BlockGuard, added recently...)
In practice this will be used for developers to opt-in to declaring
that they don't want to be allowed to do various operations (such as
disk I/O or network operations) on their main UI threads. (these
operations are often accidental, or even when they are fast come with
a good chance of being slow or very slow in some cases....)
Implementation wise, this is just a thread-local integer that has a
bitmask of the things that aren't allowed, and more bits for saying
what the violation penalty is. The penalties, of which multiple can
be chosen, include:
* logging
* dropbox uploading for analysis/reporting
* annoying dialog
* full-on crashing
These are all only very roughly implemented at this point, but all
parts now minimally work end-to-end now, so this is a good checkpoint
commit before this gets too large.
Future CLs will polish all the above 4 penalties, including
checksumming of stacktraces and minimizing penalties for duplicate
violations.
Change-Id: Icbe61a2e950119519e7364030b10c3c28d243abe
