Hi,

I don't know if the SDK call exists or not. But maybe a work around
also helps..

Here is a function in \frameworks\base\tests\AndroidTests\src\com
\android\unit_tests\HeapTest.java
    public void testOomeLarge() throws Exception {
        /* Just shy of the typical max heap size so that it will
actually
         * try to allocate it instead of short-circuiting.
         */
        final int SIXTEEN_MB = (16 * 1024 * 1024 - 32);

        Boolean sawEx = false;
        byte a[];

        try {
            a = new byte[SIXTEEN_MB];
        } catch (OutOfMemoryError oom) {
            //Log.i(TAG, "HeapTest/OomeLarge caught " + oom);
            sawEx = true;
        }

        if (!sawEx) {
            throw new RuntimeException("Test failed: " +
                    "OutOfMemoryError not thrown");
        }
    }

try {} catch {} with a few loops could approach an acceptable value, i
think.

Azraes

On Oct 15, 10:03 pm, String <[email protected]> wrote:
> Here's my situation: I have an app which does a bunch of image
> manipulations, and those images are ideally full-screen sized. It
> works on a G1 (or HVGA emulator), but runs out of memory on a WVGA
> emulator instance, because full-screen images use twice as many
> pixels. Fine, I can work around it by manipulating smaller images,
> then scaling up to WVGA at the end. There's some loss of image
> quality, but this is unavoidable on a WVGA device with a 16MB heap
> limit, so I'll live with that.
>
> When a real WVGA device hits the streets in the next couple of months,
> though, it's likely to have more than 16MB heap per app, for just this
> kind of reason. So for best image quality, I'd like my app to adapt to
> this situation, and use full-screen-sized images on such a device.
> IOW, I'd like to implement a heuristic which sets the image size based
> on heap size.
>
> In order to do so, however, the app needs to know what the maximum
> heap size is, and I haven't yet found an SDK call which will return
> this information. The various Debug.get* memory calls all seem to be
> to do with how much heap you have *allocated*, not how much you
> theoretically *can* allocate. I understand that this isn't necessarily
> a hard number, that issues like fragmentation and GC mean that you may
> not actually be able to allocate every last byte, but a theoretical
> number would still be useful.
>
> Can anyone point me to an SDK call I've missed?
>
> Thanks,
>
> String

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to