0

I am told that the Android OS (>=SDK14) is able in a real lean memory situation to start extinguishing tasks without sending onDistroy()-messages. It is very interesting (app quality issue) to stress test apps in such environments.

So this is a question about extreme cases, all memory is gone and the OS starts to extinguish stopped tasks to get more memory. Is it possible to provoke such a situation, to be able to test it? Shall I write a JNI program (making hello-jni looping a calloc or something)? This to chew up all the memory to provoke this situation of poverty?

How do I best memory choke my app/the Android OS environment? Any ideas? Any tried such stress tests?

Are there any total OS memory monitors available?

Can anyone explain if the Java and JNI parts of memory are from each other isolated heaps (chunks of memory) or allocated from the same common memory by the OS? Is it possible to choke the Java apps with JNI memory allocation?

So 7 years later, updated question:

Wh I know today it is not possible to provoke a JNI-memory shut down, just appears with no warning? It is not possible to test the topic in code?

This topic is a general design issue on how to design an editor the best way.

Still there are two main questions:

  1. There is not yet a message to the Java app that the OS intends to shut down the JNI memory part, as far as I understand.

    So the app can do the shut down itself instead and be aware the JNI part is shut down. It would be just as good if the app is notified that the entire app should be closed and all the mines will disappear, but that is not done either. The app may live but the JNI memory is gone and the app has no idea it happened.

    • Where the main problem is not knowing, not being able to test as it just crashes when the JNI memory is gone och det anropas.
    • Must be very tricky technically because there is such a given solution that is missing?

    Given that users who are in the middle of app work jump between apps, the app can't close down the JNI part for each jump. The best solution is still to let the app crash if the JNI part is gone and let the user restart again by pressing a second time on the app icon? It's not a pretty situation?

    • Also, you can't assume that JNI is gone after a few days and just restart from scratch. Because then you fill the memory with unused JNI memory allocations if this is not the case. You can't test because then it crashes.

    My app is a bookkeeping accounting browser and does not edit the files, but in 2023 I intend to come up with a complete accounting program based on the browser's functions with extensions. The situation is like an Office program, but works with inbdustry standard bookkeeping accounting documents/files. It requires that this question be thought through properly once more.

    • All views and suggestions are welcome

  2. Data recovery and the new regulations/restrictions for saving files in the public folders

    It means that you cannot use fopen() in JNI, but must use java byte streaming of the Picker. Where you can of course save the resolver and uri and reuse it for saving. See also NDK fopen() in the common storage of Android API 31

    I have solved this situation for "open the last opened file on startup" by saving a copy of the last opened file in the app's local storage as well as the name of the last opened file.

    • To save, you must start the Picker at least once, but if the file is opened with the picker, you can reuse the resolver and uri for the file update. While it is the last opened file, you have to start the picker for an OK.

    For the browser, this is a minimal problem. But for an accounting editor, it is a central question how to update documents that are worked on for a long time, and the user very likely jumps to other apps, during the work? If the JNI part disappears, it can be devastating.

    I think it can save in a temp file during the work and then have a save button for the user. A temp file that can be restored after a JNI is gone crash and the app is restarted from scratch. One can probably find a way to save where the user was last and arrange a rollback?

    It's so strange that there is so much trouble just because a "We intend to discard JNI stored memory for the app" message is missing, because then you have full control. Hope it still comes.

    • Also here all views and suggestions are welcome
Jan Bergström
  • 736
  • 6
  • 15
  • Is your software so mission critical that you would need to test for such unlikely situations? Or are you just curious as to what would happen and how to test for it? – Josh Chappelle Jan 04 '16 at 02:05
  • Question is how much memory can an app possess in onStop() state? Some say none, some say that the OS can extinguish an app/task without onDestroy(). That I regard as a OS bug if true, a message I kill you but I don't want your memory, when the case is the opposite. onDestroy() should be the message to realse all the (JNI) memory. It all end up if advanced apps should be possible or not. I believe the development of x86 makes Android possible to compete with Windows as netbook OS. I wonder is the entire debate is possible in practice. Is there a way of testing the OS environments behaviour. . – Jan Bergström Jan 05 '16 at 14:30

0 Answers0