On the phone (Galaxy S (GT-I9000) and Xperia T (LT30p) running 4.4 and 4.3) of two of my friends I from time to time get this strange error that crashes the app:

java.lang.UnsatisfiedLinkError: Couldn't load gif from loader dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/org.felikz.appname.s-1.apk"],nativeLibraryDirectories=[/vendor/lib, /system/lib]]]: findLibrary returned null
at java.lang.Runtime.loadLibrary(Runtime.java:358)
at java.lang.System.loadLibrary(System.java:526)
at pl.droidsonroids.gif.GifDrawable.<clinit>(Unknown Source)
at org.felikz.ui.webservice.views.AnimatedTouchableImageView.setImageFile(Unknown Source)
at org.felikz.ui.webservice.views.WebItemView.setProItem(Unknown Source)
at org.felikz.ui.webservice.views.WebItemView$3$1.run(Unknown Source)
at android.os.Handler.handleCallback(Handler.java:733)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5142)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:791)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:607)
at dalvik.system.NativeStart.main(Native Method)

Usually this works fine. Could this be a problem of the library or rather an android bug? Thanks!

Just noticed the 1.0.7 release wasn't in the GitHub releases section yet, that'd be useful for people not using maven central.

log :Data is not in GIF format

code: public void display(String uri,Bitmap bitmap, ImageAware imageAware, LoadedFrom loadedFrom) {

if(!uri.endsWith(".gif"))
imageAware.setImageBitmap(bitmap);
else{
File file = DiscCacheUtils.findInCache(uri, ImageLoader.getInstance().getDiscCache());
try {
Lg.e("file=============" + file.getAbsolutePath() + "---------" + file.exists());
GifDrawable gf = new GifDrawable(file);
imageAware.setImageDrawable(gf);
} catch (IOException e) {
e.printStackTrace();
}
}}
}

I use
GifImageView _gif = (GifImageView) view.findViewById(R.id.effect_gif);
_gif.setImageURI(Uri.fromFile(new File(file)));
But I see only first frame. How correct show gif from sd card in GifImageView?

http://s1.dwstatic.com/group1/M00/92/68/67a52d97b54c0531e3807bfd4a71b731.gif

A/libc(10376): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 10376

Hi guys,
I've developped an app that basically consists of a FragmentActivity and each Fragment itself mainly displays one image. Many of these images are animated gifs. Previously, I used WebView to display the animated gifs, however, this has some disadvantages (mainly sliding and zooming does not work nicely).
So I've decided to use android-gif-drawable. Works pretty nice in general. However, after 60-80 images my phone and emulator runs out of memory. I've used DDMS to monitor what uses which amount of memory, and I've noticed that there is one "1-byte array (byte[], boolean[]) that increases with each animated image that has been displayed until eventually the app runs out of memory and dies.

After a bunch of images:

Is this a problem of the way I'm using the animated-gif-drawable or could it be a bug internally?
Regards,
Felix

I tried to load several GIF files from a remote server using the android-gif-drawable classes, but the following issues occurred:

• Loading single GIF file can render and playback properly
• When different GIF files are loaded, all frames from loaded GIF files are added to all GifDrawable instances, thus causing all image views using GifDrawable to playback all frames from all loaded GIF files.

The files are loaded using the following method:

URL url = new URL(requestedURL);
URLConnection conn = url.openConnection();

// Create stream to read image data
InputStream gifInputStream = conn.getInputStream();

// Create output stream
ByteArrayOutputStream bos = new ByteArrayOutputStream();

int part;
while ((part = gifInputStream.read()) > -1) {
bos.write(part);
}

byte[] ba = bos.toByteArray();
gifDrawable = new GifDrawable(ba);

And playback is controlled by:
imageView.setImageDrawable(gifDrawable);
gifDrawable.start();

I believe there were some good crash & mem fixes that haven't been released yet, could we get an aar up on maven central for 1.0.7?

It seems like that mColors has not been recycled by VM...

Creating one reusable Java's byte array per GifDrawable instance will be more efficient than allocating new array in each streamReadFun() call.

I am not entirely sure, but I have tried for a while and never successfully gotten a gif with a transparent background to have a transparent background while playing. For gifs with transparent backgrounds, the GifImageView seems to take the most common color in the gif and use that as a background for the View. Additionally, the background flickers every loop of the gif as the background changes from transparent to filled at the start of each loop.

T^T

like title

Eg. by modifying original duration of frames

I don't think this should be particularly difficult, but with other drawables, like Bitmaps, we can determine their size in bytes, which is very useful for caching strategies. But with GifDrawable, once we create one, we have no way of querying it for it's size in bytes.

Just a method like: getNumBytes() or what ever would be very useful!

The release jar provided needs a different internal directory structure for Android to be able to find the native libs at run time.

Currently the different cpu architecture directories are siblings with the top level Java package directory. Instead, the architecture directories need to be children of a lib directory. Note that it's singular lib, not the plural libs from the standard android project structure.

JAR
|
+-lib
--the native lib dirs
+-pl
--the java dirs

Gif image is almost 5M, repeat twice and then get error and force close

09-12 18:27:00.368: E/dalvikvm(20336): Unknown format 32 in dvmGetExpandedRegisterMap

09-12 18:27:00.368: E/dalvikvm(20336): VM aborting

09-12 18:27:00.368: A/libc(20336): Fatal signal 11 (SIGSEGV) at 0xdeadd00d (code=1)

Please add the sample project!

It would be very helpful to produce a .aar file for releases

It would be super sweet to get a method to reset a GIF while it's animating to the first frame. Essentially starting it over.

The core problem is in ListView items that contain an ImageView which may contain a GifDrawable. If we create a new GifDrawable object every time the item view is requested, we end up with a ton of allocations and cause some major GC thrashing when you are scrolling quickly.

For comparison: using the ImageView's setBitmap(), it internally creates a new BitmapDrawable to wrap the Bitmap object you pass in, but it does not cause the same GC thrashing that we see with GifDrawable. So I believe it's the internal allocations in GifDrawable that are the problem.

I have a seemingly working solution where I cache the GifDrawable it's self, rather than the backing byte array, and this solves the GC problem. But the question is if that is safe. If multiple ImageView's shared a single GifDrawable instance, I think it'd run into problems, since they are both modifying the same book keeping variables inside GifDrawable.

I'm not 100% sure what the solution is. BitmapDrawable has mutate() which produces a unique Drawable. But I think what we really need a way of re-using the book-keeping variables inside a GifDrawable... or something. Maybe GifImageView could have some special stuff. Storing the book keeping variables it's self, so when you give it a GifDrawable, it can set the metadata and all that junk on the Drawable. Idk.

Any ideas if there are some allocations we could cut down on during instantiation?

I attach the GifDrawable to a ImageView,but I found that while the imageview destroy,application abnormal exit.

logs are here:

10-16 09:32:15.224: D/dalvikvm(364): GC_EXTERNAL_ALLOC freed 331 objects / 12744 bytes in 107ms
10-16 09:32:15.224: D/GifDrawable(364): recycle
10-16 09:32:15.343: I/DEBUG(31): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
10-16 09:32:15.343: I/DEBUG(31): Build fingerprint: 'generic/sdk/generic/:2.2/FRF91/43546:eng/test-keys'
10-16 09:32:15.343: I/DEBUG(31): pid: 364, tid: 365 >>> cn.cnzhujie.microfunny <<<
10-16 09:32:15.354: I/DEBUG(31): signal 11 (SIGSEGV), fault addr deadbaad
10-16 09:32:15.354: I/DEBUG(31): r0 00000000 r1 0000000c r2 00000027 r3 00000000
10-16 09:32:15.354: I/DEBUG(31): r4 00000000 r5 deadbaad r6 00001728 r7 00000000
10-16 09:32:15.354: I/DEBUG(31): r8 100ffca8 r9 4203af78 10 4203af60 fp 00127320
10-16 09:32:15.354: I/DEBUG(31): ip ffffffff sp 100ffc10 lr afd154c5 pc afd11dc4 cpsr 40000030
10-16 09:32:15.504: I/DEBUG(31): #00 pc 00011dc4 /system/lib/libc.so
10-16 09:32:15.504: I/DEBUG(31): #01 pc 0000be1c /system/lib/libc.so
10-16 09:32:15.504: I/DEBUG(31): code around pc:
10-16 09:32:15.504: I/DEBUG(31): afd11da4 1c2bd00b 2d00682d e026d1fb 2b0068db
10-16 09:32:15.504: I/DEBUG(31): afd11db4 4e17d003 51a02001 4d164798 24002227
10-16 09:32:15.514: I/DEBUG(31): afd11dc4 f7fb702a 2106ee14 ef10f7fc 05592380
10-16 09:32:15.514: I/DEBUG(31): afd11dd4 6091aa01 1c116054 94012006 eab6f7fc
10-16 09:32:15.514: I/DEBUG(31): afd11de4 2200a905 f7fc2002 f7fbeac2 2106ee00
10-16 09:32:15.514: I/DEBUG(31): code around lr:
10-16 09:32:15.514: I/DEBUG(31): afd154a4 b0834a0d 589c447b 26009001 686768a5
10-16 09:32:15.514: I/DEBUG(31): afd154b4 220ce008 2b005eab 1c28d003 47889901
10-16 09:32:15.514: I/DEBUG(31): afd154c4 35544306 d5f43f01 2c006824 b003d1ee
10-16 09:32:15.514: I/DEBUG(31): afd154d4 bdf01c30 0002ae7c 000000d4 1c0fb5f0
10-16 09:32:15.526: I/DEBUG(31): afd154e4 43551c3d a904b087 1c16ac01 604d9004
10-16 09:32:15.526: I/DEBUG(31): stack:
10-16 09:32:15.526: I/DEBUG(31): 100ffbd0 00000015
10-16 09:32:15.526: I/DEBUG(31): 100ffbd4 afd1453b /system/lib/libc.so
10-16 09:32:15.526: I/DEBUG(31): 100ffbd8 afd405a0 /system/lib/libc.so
10-16 09:32:15.526: I/DEBUG(31): 100ffbdc afd4054c /system/lib/libc.so
10-16 09:32:15.534: I/DEBUG(31): 100ffbe0 00000000
10-16 09:32:15.534: I/DEBUG(31): 100ffbe4 afd154c5 /system/lib/libc.so
10-16 09:32:15.534: I/DEBUG(31): 100ffbe8 00000000
10-16 09:32:15.534: I/DEBUG(31): 100ffbec afd1450d /system/lib/libc.so
10-16 09:32:15.534: I/DEBUG(31): 100ffbf0 00000003
10-16 09:32:15.534: I/DEBUG(31): 100ffbf4 afd40328 /system/lib/libc.so
10-16 09:32:15.534: I/DEBUG(31): 100ffbf8 00000000
10-16 09:32:15.544: I/DEBUG(31): 100ffbfc 00001728
10-16 09:32:15.544: I/DEBUG(31): 100ffc00 00000000
10-16 09:32:15.544: I/DEBUG(31): 100ffc04 afd147ab /system/lib/libc.so
10-16 09:32:15.544: I/DEBUG(31): 100ffc08 df002777
10-16 09:32:15.544: I/DEBUG(31): 100ffc0c e3a070ad
10-16 09:32:15.544: I/DEBUG(31): #00 100ffc10 43a77277 /data/dalvik-cache/data@app@[email protected]
10-16 09:32:15.544: I/DEBUG(31): 100ffc14 afd15e19 /system/lib/libc.so
10-16 09:32:15.544: I/DEBUG(31): 100ffc18 afd418dc /system/lib/libc.so
10-16 09:32:15.544: I/DEBUG(31): 100ffc1c afd10510 /system/lib/libc.so
10-16 09:32:15.544: I/DEBUG(31): 100ffc20 afd40328 /system/lib/libc.so
10-16 09:32:15.544: I/DEBUG(31): 100ffc24 fffffbdf
10-16 09:32:15.544: I/DEBUG(31): 100ffc28 afd40328 /system/lib/libc.so
10-16 09:32:15.553: I/DEBUG(31): 100ffc2c afd41724 /system/lib/libc.so
10-16 09:32:15.553: I/DEBUG(31): 100ffc30 0000a000 [heap]
10-16 09:32:15.553: I/DEBUG(31): 100ffc34 afd0be21 /system/lib/libc.so
10-16 09:32:15.553: I/DEBUG(31): #01 100ffc38 afd40328 /system/lib/libc.so
10-16 09:32:15.553: I/DEBUG(31): 100ffc3c afd0be21 /system/lib/libc.so
10-16 09:32:15.553: I/DEBUG(31): 100ffc40 4203af60
10-16 09:32:15.553: I/DEBUG(31): 100ffc44 afd41724 /system/lib/libc.so
10-16 09:32:15.553: I/DEBUG(31): 100ffc48 00000000
10-16 09:32:15.553: I/DEBUG(31): 100ffc4c afd41724 /system/lib/libc.so
10-16 09:32:15.553: I/DEBUG(31): 100ffc50 00000000
10-16 09:32:15.553: I/DEBUG(31): 100ffc54 afd41850 /system/lib/libc.so
10-16 09:32:15.564: I/DEBUG(31): 100ffc58 000013fc
10-16 09:32:15.564: I/DEBUG(31): 100ffc5c afd41864 /system/lib/libc.so
10-16 09:32:15.564: I/DEBUG(31): 100ffc60 100ffca8
10-16 09:32:15.564: I/DEBUG(31): 100ffc64 0027dcd0 [heap]
10-16 09:32:15.564: I/DEBUG(31): 100ffc68 00275ce0 [heap]
10-16 09:32:15.564: I/DEBUG(31): 100ffc6c 0027eab8 [heap]
10-16 09:32:15.564: I/DEBUG(31): 100ffc70 00000000
10-16 09:32:15.564: I/DEBUG(31): 100ffc74 afd0cd81 /system/lib/libc.so
10-16 09:32:15.564: I/DEBUG(31): 100ffc78 0027dcd0 [heap]
10-16 09:32:15.564: I/DEBUG(31): 100ffc7c 80a017b5 /data/data/cn.cnzhujie.microfunny/lib/libgif.so
10-16 09:32:16.514: D/Zygote(33): Process 364 terminated by signal (11)
10-16 09:32:16.514: I/WindowManager(59): WIN DEATH: Window{46163168 cn.cnzhujie.microfunny/cn.cnzhujie.microfunny.activity.MainActivity paused=false}
10-16 09:32:16.524: I/ActivityManager(59): Process cn.cnzhujie.microfunny (pid 364) has died.
10-16 09:32:16.614: I/BootReceiver(59): Copying /data/tombstones/tombstone_02 to DropBox (SYSTEM_TOMBSTONE)
10-16 09:32:16.614: I/UsageStats(59): Unexpected resume of com.android.launcher while already resumed in cn.cnzhujie.microfunny


I find this error is cause by gif.c line 116(in function cleanUp)

free(&GifFile->Error);

I hava attache my project here:
https://github.com/cnzhujie/test

So I'm using GifImageView in a layout, and I'm setting a non-GIF src image in XML:
android:src="@drawable/not_a_gif"

And I'm getting the following exception in the layout preview:

java.lang.UnsupportedOperationException
at android.content.res.BridgeResources.getResourceTypeName(BridgeResources.java:479)
at pl.droidsonroids.gif.GifImageView.trySetGifDrawable(GifImageView.java:74)
at pl.droidsonroids.gif.GifImageView.(GifImageView.java:40)
...

I think we need to wrap what ever is in here with: if( !View.isInEditMode() )

To prevent this code from running in the layout preview.

As title metioned, I declare a ImageView in xml layou file,

    <ImageView
        android:id="@+id/image"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:contentDescription="@null"
        android:scaleType="fitCenter" />

In activity, I use it lick this

GifDrawable gDrawable = new GifDrawable(assetFileDesc);
image.setImageDrawable(gDrawable);

I tried all of scaleType enum, there is only fitXY and fitCenter don't work. It always shows in the upper left corner in ImageView. Cound you fix it ASAP? many thanks!

When I try to create a new GifDrawable(byte[]) and it fails because the file is not a gif, I am left with a dangling byte[] of the size of the image that can never be freed. Over time this leads to large memory problems.

The problem seems to be somewhere in openByteArray(), but I haven't been able to track down the exact problem in the C code.

I load lots of images that may or may not be gifs, and I was using this as an easy test to check if they are gifs. Unfortunately the memory leak is prohibitive. I'd love some input on where to look to fix this.

Just changed my project to use the new 1.0.2 release jar, and I'm getting linking errors:

Caused by: java.lang.UnsatisfiedLinkError: dlopen failed: "/data/app-lib/com.xxx.xxx-1/libgif.so" has no loadable segments

I inspected the jar and it looks fine to me, so I currently have no idea what the problem is.

However, it's not a simple "can't find lib", so maybe the actual binaries were just built wrong?

I have an issue where certain gifs wont render correctly, but others do (possibly an encoding issue?)

Ones that dont work:

http://i.imgur.com/HUvsoJR.gif
http://i.imgur.com/LV0X7iT.gif

Ones that do work:

http://s.scruffyfox.me/rqAbkSN.gif

Add info about gradle

I'm tracking down a crash in the native side.

Repro:
Create a GifDrawable from a ByteArrayInputStream: new GifDrawable( inputStream )

It will appear to create correctly, reporting proper width, height, and no error.

However, once a frame is requested from it, it will crash with the following back trace:

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 000002c0
00 pc 00001670 /data/app-lib/xxx/libgif.so
01 pc 000028c3 /data/app-lib/xxx/libgif.so (DGifGetRecordType+32)
02 pc 000018ed /data/app-lib/xxx/libgif.so (DDGifSlurp+20)
03 pc 00002123 /data/app-lib/xxx/libgif.so (Java_pl_droidsonroids_gif_GifDrawable_renderFrame+670)

Using the exact same image and loading it either as a Resource, or FileDescriptor works flawlessly. From my investigation so far, it looks like the problem likely resides in:
gif.c :: openStream() the JNI implementation

It's the only part of the code path that is different depending on the source (InputStream VS FileDescriptor)

Can you provide a .jar for the 1.0.5 release?

It would be great to get this into Maven central. Thanks for your effort, this has been a sorely missed bit of code in Android.

Currently there is no direct way to get each frame ARGB data. Two methods can be added:

• seekToFrame(int frameIndex) - will seek to frame having given frameIndex
• getPixels(int[] buffer) - will copy current frame buffer to given buffer

I'd love to get the GIF reset and the mem free fix in, what about doing a new release w\ those?

Currently it's impossible to make a GifDrawable outside of the context of the helper (GifImageView) classes because it only has package visibility.

请问如何动态更换gif？

I have put a "1.gif" at sdcard
and change the line 43 to:
GifDrawable drw=new GifDrawable("/sdcard/1.gif");

but it tell me:
java.lang.ExceptionInInitializerError

so how to use it?
thank you!

I have included the project via maven in eclipse, and when I attempt to run my project I receive the following error,

I'm aware of the force error option and I have it disabled. The odd thing is that I have other JARs in this project that also include native libraries, and they allow the project to build just fine, they also don't have the files in lib/, but in libs/...

eg. ByteBuffer

Sometimes in native function https://github.com/koral--/android-gif-drawable/blob/master/jni/gif.c#L1202 info->lastFrameReaminder becomes > 0, so after resume metadata[4] becomes < 0, so https://github.com/koral--/android-gif-drawable/blob/master/src/pl/droidsonroids/gif/GifDrawable.java#L708 will be always negative and animation stops.

I fixed it by adding check in saveReminder:

if (info->lastFrameReaminder > 0) {
        info->lastFrameReaminder = 0;
}

I can reproduce it by calling GifDrawable stop() and start() several times.

First, thanks for this amazing library, but when i pass a byte array to the GifDrawable constructor sometimes i get a NoClassDefFoundError.
This is a part of the stacktrace:

java.lang.NoClassDefFoundError: pl/droidsonroids/gif/GifIOException
    at pl.droidsonroids.gif.GifDrawable.openByteArray(Native Method)
    at pl.droidsonroids.gif.GifDrawable.<init>(SourceFile:262)
Caused by: java.lang.ClassNotFoundException: Didn't find class "pl.droidsonroids.gif.GifIOException" on path: DexPathList[[zip file "/data/app/com.mattiafranchetto.pr0gramm-1.apk"],nativeLibraryDirectories=[/data/app-lib/com.mattiafranchetto.pr0gramm-1, /vendor/lib, /system/lib]]    
    at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:497)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:457)
... 17 more

This happens on many devices, with different versions of Android.

If I have a GIf currently animating, and I call:
gifDrawable.stop();

It pauses on the current frame as expected. But calling:
gifDrawable.start();

while it is stopped does not resume it playing.

First, very good library, works on many phones/Android versions.

However, when check the CPU usage, it seems consuming a lot.

Tested on Android 2.3 on a low end phone, keeps 90% CPU usage.
on Galaxy S4, it also use 60% - 70% CPU

Any suggestions on the optimization?

.so files generated by android-maven-plugin are invalid