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
|