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:
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
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
Related
Before some one close this due to the reason that it may have been asked earlier kindly read the following note
Note: Another question here with almost same scope of information and usage has been asked earlier but it does not contain any answer! Tried googling a lot but did not find any satisfactory answer!
My Question is about the EditText in android, how much text it can hold in it?
I write a code of server which receives a request from clients and display the history of all requests received so after 2650+ requests my app begin to not respond and finally crashes. I noticed that due to some reason very large text makes the EditText unresponsive one request contains almost 85 chars data!
Platform Nokia 6.1 with Android One 9.0 Pie
There should not be any real limit, but as you see you may run out of memory or require too much computation power.
My advice: Load the visible partof the log you want to inspect / edit.
Eclipse starts "scalability mode" when you have more than ~ 5k lines of code.
WhatsApp and Telegram only show the latest ~50 messages, but quickly load more when you scroll up a lot.
9Gag, Facebook etc. will load more posts on demand.
So you should think about something like that, or google scalable textEdit solutions. My advice would be to store the logs in separate files and load dynamically.
I'm using a SG Note 4 and when I open the Google Maps app and then go to task manager it never shows up, it does when you go to settings, applications, cached..., how can I achieve the same with my app. Im using a map fragment and when moving the camera the cache increases and increases, I imagine people with little knowledge going to task manager and seeing my app using 500mb of ram might end up getting scared and kill it, or worse uninstalling it. Maybe not all manufacturers give users this option but for those that do how can I do this if it's even possible thanks!!
I would like to write a program in java that copies mp3 files from my PC, renames them so they sort correctly, and transfers them to the sdCard on my Android phone via USB. I assumed this would be a trivial task since I have already successfully written a similar program for transferring files to an external HDD, however I reached an immediate stumbling block. It seems that java (and indeed other desktop applications) cannot locate the device's file system even when given the exact path that windows explorer reports (This PC\SAMSUNG-SM-G900V\Card).
I've tried researching and the problem seems to have to do with the device being considered a Portable Device rather than a drive (maybe) but I have not found a concrete solution. An answer to the following question seems to suggest it is impossible but I find that hard to believe.
Can Android's internal memory be mapped to a drive letter on PC?
Does anyone know of a way to access Portable Device storage through java? If if it indeed impossible, can someone perhaps help me understand why it is possible through Windows Explorer but not through other programs.
I am currently creating an app and would like to create a demo version (free) and a full version.
However, I am wondering how I can set some sort of flag so that when the demo version has been used 5 times, you have to buy the full version to continue using. This usage will be detected on a submit button.
I was considering setting a flag in the app, however releasied that the user could uninstall the app and then re-install it overcoming my set flag (as this would set it back to 0).
Has anyone got any clever solutions for my little dilema?
Thanks
You might want to try one of the techniques in this answer: https://stackoverflow.com/a/996288/1205715
I think that is not possible with an local application.
File saving to sdcard with strange filename can be a way but It is not perfect.
In my opinion, Right way is using an application server that manages user run times with unique UUID.
It might also be worth thinking about an alternative approach.
In app purchases are now available, so you could have a free and a restricted section in your app, and use the in app purchase to unlock the restricted section. You see more developers going with this approach these days, rather than managing two versions of the app.
Also worth considering the fact that if you have a paid version of the app it can be pirated pretty quickly, one person just needs to get their hands on the full apk. However, if you go with the in app purchase model you will be letting google handle a lot of these issues for you.... just a thought, and the road I will be taking with my next app.
I write an app which will continuously request data from a sensor board and send data to server. I use a Motorola Droid phone which have not be activated to test my app. I find that sometimes after several hours the phone will reboot. I just want to know does it cause by my app run out of memory. And if an app runs out of phone's memory, should just the app be force closed or the phone be reboot?
If this causes by app running out of memory how could I release and clear variables. Should the system automatically do this? I think the main problem might be that I set a global json variable to receive and send all data. After sending the data, I just user new JSONObject() to initiate the variable. I just want to know does the old one will be released automatically? If not, how can I do to release it?
Thanks
If an app runs out of phone's memory, an exception will be thrown and if the exception will not be catched - an app will be force closed.
System automatically clean unused memory. Yes, your old JSONObject should be autoreleased by garbage collector.
To learn how to find memory leaks in Android programs, read the article in Android developers blog: Memory Analysis for Android Applications