Infeasible
Status Update
Comments
vi...@google.com <vi...@google.com>
su...@google.com <su...@google.com> #2
a concerning line is:
emulator: WARNING: Host CPU is missing the following feature(s) required for x86 emulation: SSSE3
what is the CPU in your computer?
The new emulator system requirements are posted here:
http://tools.android.com/tech-docs/emulator
emulator: WARNING: Host CPU is missing the following feature(s) required for x86 emulation: SSSE3
what is the CPU in your computer?
The new emulator system requirements are posted here:
su...@google.com <su...@google.com> #3
The processor is an AMD Phenom II x6 1075T, and it has AMD-V, as required by the new Android emulator in Linux (please see this link for more info on this CPU : http://www.cpu-world.com/CPUs/K10/AMD-Phenom%20II%20X6%201075T%20-%20HDT75TFBK6DGR.html )
It does not have SSSE3, but I don't see it as a requirement in the Android emulator specs.
It does not have SSSE3, but I don't see it as a requirement in the Android emulator specs.
Description
I was wondering if there is some API on Android to overcome the creation of the file on storage, and store it inside the RAM instead.
Sadly there isn't, except for using tmpfs of Linux, which requires root.
For example, suppose there is `SomeFileParser.parseFile(filePath)` , I want to give it a path to a place that doesn't really exist in the storage file system, but one that I've created that is stored only in RAM.
Please offer such an API.
The important notes about this:
1. You choose how private this data is, and by default it should be only for your app's processes (maybe even just the current process)
2. The folder will be gone when the process that created is gone.
3. It should be easy to check how much RAM you can use for using this functionality. It should be bounded by how much free RAM the device has (or some large percentage of it), and not related to the heap
4. Once you create such a folder, you can create/delete/modify/rename files there like normal storage.
5. For each operation, you should be able to check if it succeeded or not, and none should cause a crash of the app (OOM for example). Instead, you can use either try-catch, or a returned value for each operation, as for the normal file system operations.
6. There should be a way to release it all, completely.