| f626ca2c96f629627a8df6944c9b0d774e6e67ae |
|
08-Apr-2014 |
Narayan Kamath <narayan@google.com> |
Don't allow MemoryFiles of negative length.
Prevents us from converting a (signed) jint into an
(unsigned) size_t and having horrible things happen.
Change-Id: I0f04e2eb9852ae7fc49b435fd0974f56e86751a4
/frameworks/base/core/java/android/os/MemoryFile.java
|
| c20cadbdad0cdfe8e56431c22bd26ae666101e89 |
|
10-Jan-2014 |
Ashok Bhat <ashok.bhat@arm.com> |
AArch64: Use long for pointers in android/os/MemoryFile
Long is used in android/os/MemoryFile class to store
pointers as native pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)
Change-Id: I07afc010524c16b5c852273b89becb0c08ff27d7
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
/frameworks/base/core/java/android/os/MemoryFile.java
|
| 112d339673c379b71a989bd33b73648aafe58ce1 |
|
25-Mar-2011 |
Jesse Wilson <jessewilson@google.com> |
Fix MemoryFile's output stream to advance.
Previously it was not useful.
Change-Id: I0bcc06b65bab33a38a0b0148c020509076a51b1c
http://code.google.com/p/android/issues/detail?id=11415
/frameworks/base/core/java/android/os/MemoryFile.java
|
| a006b47298539d89dc7a06b54c070cb3e986352a |
|
14-Apr-2010 |
Bjorn Bringert <bringert@android.com> |
New API and implementation of DB and memory-backed FDs
This depends on a kernel patch that implements read(2)
in the ashmem driver.
Bug http://b/issue?id=2595601
Change-Id: Ie3b10aa471aada21812b35e63954c1b2f0a7b042
/frameworks/base/core/java/android/os/MemoryFile.java
|
| 186683923ce8d6a2d5c6fd4768b26b90308661e9 |
|
24-Mar-2010 |
Dianne Hackborn <hackbod@google.com> |
Maybe fix #2422586: Native crash in android_os_Parcel_closeFileDescriptor()
killed the phone process
Try to make sure we never have a ParcelFileDescriptor with a null
FileDescriptor. That is just wrong.
Change-Id: Ib779ad1852dd239827797cd8f93505bfe6157e58
/frameworks/base/core/java/android/os/MemoryFile.java
|
| 7bcbd511731e13b9f2778e6aa6c633417d266f5e |
|
23-Jun-2009 |
Marco Nelissen <marcone@google.com> |
Don't round size to page size. Ashmem will do this internally as needed.
/frameworks/base/core/java/android/os/MemoryFile.java
|
| ec100900e63a8374ac010e7131d9c7e54c5e6984 |
|
17-Jun-2009 |
Marco Nelissen <marcone@google.com> |
MemoryFile.isMemoryFile was internally determining the length of
the ashmem region. This is actually useful information to have,
so expose that more directly.
/frameworks/base/core/java/android/os/MemoryFile.java
|
| c1823701cc76790494fb622fe58f0942236cd7d0 |
|
01-Jun-2009 |
Bjorn Bringert <bringert@android.com> |
Handle EOF correctly in MemoryFile input stream.
Before, the variants of MemoryFile.MemoryInputStream.read() would throw
IOException or IndexOutOfBoundsException if EOF was encountered
before the requested number of bytes was read. This violates
the contract of InputStream.read().
This patch makes read() return the number of bytes available, if any.
If already at EOF, -1 is returned. The patch also adds new tests,
which checks cases where MemoryFile.MemoryInputStream.read()
should throw IndexOutOfBoundsException or return -1. several of these
tests failed with the old code and pass now.
This fixes http://b/issue?id=1881894
/frameworks/base/core/java/android/os/MemoryFile.java
|
| 963cd006c45716b034f656bf7e7179e6476f7e4d |
|
29-May-2009 |
Bjorn Bringert <bringert@android.com> |
Allow creating AssetFileDescriptors for MemoryFiles.
This allows content providers to use in-memory data to implement
ContentProvider.openAssetFile(), instead of just normal files
and sockets as before.
To test cross-process use of AssetFileDescriptors for MemoryFiles,
a test content provider and a client for it are added to
AndroidTests.
Fixes http://b/issue?id=1871731
/frameworks/base/core/java/android/os/MemoryFile.java
|
| 761e0918d30b6a3f292625b44b86dffd1538bc78 |
|
29-May-2009 |
Bjorn Bringert <bringert@android.com> |
Unmap memory in MemoryFile.close().
As reported in http://b/issue?id=1398215 MemoryFile did not
munmap(2) the ashmem region after closing it. This
causes the process to leak virtual address space.
This change fixes the problem by calling munmap(2) in
close(). The unmapping is done by a helper method deactivate().
The change also replaces the use of an int for the
file descriptor with a FileDescriptor object to
make sure that we keep track of when the file descriptor
has been closed. I chose to implement it this way because I
will need decativate() and a FileDescriptor object in an
upcoming change that allows sending MemoryFile file
descriptors between processes.
The change also adds a number of tests for the behavior
of close(). The testCloseRead() and testCloseWrite() fail
with the old MemoryFile implementation, and testCloseLeak()
causes a segfault. They all pass now.
/frameworks/base/core/java/android/os/MemoryFile.java
|
| 9fc2e9c965c68d56a0caf812f7f6d38d15317063 |
|
28-May-2009 |
Bjorn Bringert <bringert@android.com> |
MemoryFile constructor and native methods throw IOExceptions.
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
/frameworks/base/core/java/android/os/MemoryFile.java
|
| 9066cfe9886ac131c34d59ed0e2d287b0e3c0087 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/os/MemoryFile.java
|
| d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/os/MemoryFile.java
|
| 54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/java/android/os/MemoryFile.java
|