And what about his question about Log.d()? Or does the OP need to supply more details before anyone can answer it effectively?
The latter is my guess: I can't imagine why, for example, Log.d() would fail and Log.e() would work on the real hardware on a Galaxy S. So I would suggest the OP at least answer that much: is it only Log.d() that fails, or do ALL the Log statements fail? And how is he invoking LogCat? Given the sketchy details, it is hard for me to say if he is having the same problem I used to have, but he might be. The problem I was having was that the LogCat display in Eclipse was failing. At the time, I didn't know the usual cause of this was an Eclipse bug losing track of which Device to use, so I just gave up on using the Eclipse perspective and got my logcat output by running logcat on the command line instead, usually using "logcat -v time | tee LogCatCaptureFile.txt" or the like to capture the whole thing and search through it with an editor. Later, I found out that I could usually restore the LogCat display in Eclipse by double checking the Device Window and making sure that the right device was selected. So if you are still out there, Matthew, you might want to let us know if either of these measures gets you around your inability to display Log.d() statements running on the real hardware. Also, I hope the OP has not given up completely on Android for his program. However, now that he knows the limits of the Android Java API, he might want to consider using C/C++ code and the NDK for the creation and direct manipulation of his image buffers, so that he can get around that limitation to declaring immutable bitmap buffers only. Then the rest of his application can still use the Android Java APIs. On Jan 17, 10:44 am, Romain Guy <[email protected]> wrote: > Hi Matthew, > > I am sorry that you didn't get a better answer before, but this is, > unfortunately, the only way of doing it with the existing APIs. This kind of > feedback is important to us because it tells us what APIs application > developers need. > > As for your second question, the values returned are expected. > Runtime.freeMemory() tells you how much you can still allocate on the heap > before it needs to expand. Runtime.totalMemory() indicates the current size > of the heap, and Runtime.maxMemory() tells you how big the heap can be > before your run out of memory. > > On Mon, Jan 17, 2011 at 4:18 AM, Matthew Fleming <[email protected]> wrote: > > Hi, > > > I posted earlier about my need to find a way to load a mutable bitmap. > > I need to be able to load a bitmap from an input stream, annotate it, > > and save it. At present, the only thing I seem to be able to do is > > load an immutable bitmap, copy it, annotate the copy, and then save > > that. THIS IS NOT A SOLUTION, because then I need memory for two > > copies of the bitmap, and I am working with large images. > > > COULD SOMEONE FROM GOOGLE PLEASE TELL US WHY the BitmapFactory methods > > don't have the option of creating the Bitmap as mutable? A bit heavy- > > handed to force the Bitmap to be immutable, don't you think? For that > > matter, DOES ANYONE AT GOOGLE PAY ANY ATTENTION TO THIS GROUP? You > > post to the Apple Developer groups, you get an answer (even on the > > weekend) from a real live person who knows what he's talking about, > > and who is (usually) on the Apple payroll. Not here. > > > Second question. I figured I would check the available memory before > > loading the bitmap, then load it at reduced resolution if necessary. > > But Runtime.getRuntime().freeMemory() returns values that make no > > sense. For example, if I put this in the onCreate of my first (main) > > activity: > > long freeMemory = Runtime.getRuntime().freeMemory(); > > Log.d("tag",String.valueOf(freeMemory)); > > freeMemory = Runtime.getRuntime().maxMemory(); > > Log.d("tag",String.valueOf(freeMemory)); > > I get a total memory of 16,777,216, but free memory of only 472,824. > > This can't be right. > > > The above is with the emulator. When I try it with my Samsung Galaxy > > Tab, I don't get any information, because Log.d() doesn't seem to work > > at all with the actual hardware. Why is that? > > > Some real assistance with these problems would be much appreciated. > > Google? Anyone home? > > > Matthew Fleming, MD > > Fleming Dermatopathology, LLC > > DermVision, LLC > > > -- > > 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]<android-developers%[email protected]> > > For more options, visit this group at > >http://groups.google.com/group/android-developers?hl=en > > -- > Romain Guy > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time to > provide private support. All such questions should be posted on public > forums, where I and others can see and answer them -- 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
