If feasible, you might want to send smaller encrypted chunks instead of the whole encrypted file. Just a thought....... (without knowing all the specifics).
This would reduce the required amount of memory. I'm familiar with this approach but going the other way (uploading files to the server). The last step would be reconstructing the complete file (more steps but lighter in terms of memory). Again it is just a thought. On Nov 16, 3:31 pm, manayv <[email protected]> wrote: > I learned from several discussions of this group that > BitmapFactory.decodeFile() allocates heap memory outside of the "java > heap". > My app receives encrypted files from a remote server. Decoding those > files needs a lot of heap space. After finishing this decoding step > most of the allocated heap space will be freed by the GC. But the > (total) heap size - as displayed by the DDM - remains large. In this > situation there is not enough heap space outside of the "Java heap" to > decode even medium sized image files using BitmapFactory.decodeFile(). > At the moment I limit the size of encrypted files to ensure that the > Java heap space never increases to more than 10 MB. This ensures that > there is enough memory for BitmapFactory.decodeFile(). > But this is not very elegant. > > Is it possible to tell the dalvik-vm to reduce the (total) heap size > to have more space for decoding images or is there another solution? > > Thanks, > > manayv -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
