We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3135

Summary: SDL stops drawing after a short time (android)
Product: SDL Reporter: raincomplex
Component: renderAssignee: Sylvain <sylvain.becker>
Status: RESOLVED ABANDONED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: philipp.wiesemann, sylvain.becker
Version: 2.0.3   
Hardware: All   
OS: Android (All)   
Attachments: android project exhibiting bug

Description raincomplex 2015-09-29 20:43:47 UTC 
Created attachment 2279 [details]
android project exhibiting bug

Symptom: Shortly after starting the app, it stops drawing after 0 or more successfully drawn frames (up to several seconds worth on occasion, but usually 1 or 2 frames). The app is still running and draw function is still being called, but the screen does not update. Oddly, leaving the app without closing it and then returning causes drawing to resume and the problem to apparently remain fixed until the app is closed.

It seems that the delay between draw calls is somehow involved -- reducing the delay to 10ms causes the problem to reproduce nearly immediately, while 100ms causes it to not present.

Affected device: Samsung Galaxy S6 (Android 5.1.1)
Unaffected device: Nexus 4 (Android 4.2.3). Additionally, someone on #SDL said they had a Nexus 4 on Android 5.1.1 that did not exhibit this problem, so Android version may not be relevant.

Attached is an android project which exhibits the problem: it shows a white square bouncing inside a gray rectangle. (android project template copied from 2.0.4 release candidate at https://libsdl.org/tmp/download-2.0.php - the bug was also present in 2.0.3) The source is in jni/src/main.c and the built apk is at bin/SDLActivity-debug.apk. To build it yourself you'll need to change jni/SDL to point to your SDL source directory. The app shows up as "SDL App" in the launcher.
Comment 1 Sylvain 2015-10-01 13:04:46 UTC 
Hi, I don't have the problem with a Samsung S5, android 5.0, using the latest SDL Hg version.
(I only took your main.c)

I had to re-write your 
      SDL_RenderFillRect(renderer, &(SDL_Rect){0, 0, scrw, scrh});
      SDL_RenderFillRect(renderer, &(SDL_Rect){x, y, size, size});
in 
      SDL_Rect r1 = {0, 0, scrw, scrh};
      SDL_Rect r2 = {x, y, size, size};
      SDL_RenderFillRect(renderer, &r1);
      SDL_RenderFillRect(renderer, &r2);

Because it didn't fit my compilation flags ...

A few things to try: 
- use lastest SDL Hg (you said you used SDL 2.0.4, I know it's almost the latest..)
- update to the latest NDK (r10e) + in the AndroidManitest.xml, set android:targetSdkVersion="23". 
- provide a "log cat".
- Also, did you run the binary as "arm", or "arm-v7a" ? (in jni/Android.mk) you could try to reduce the number of architecture targeted ...
Comment 2 raincomplex 2015-10-02 03:48:37 UTC 
Thanks for the response. I did a lot of log searching before and didn't find anything relevant (the S6 spits out a ton of irrelevant debug info compared to the Nexus 4). I was using NDK r10d. I'm not sure which architecture was used; I stuck with the defaults in jni/Application.mk of armeabi armeabi-v7a x86. I believe the S6 is ARMv8-A. I don't know that much about that aspect of Android. I'll try your suggestions as soon as I can and report back.
Comment 3 Sylvain 2015-10-02 06:14:10 UTC 
Yes, sorry this is in "jni/Application.mk", try with only one architecture.
The most basic is:

APP_ABI := armeabi

might be a way to narrow down the issue.
Comment 4 Philipp Wiesemann 2015-12-08 19:45:03 UTC 
The renderer is activated and deactivated by window events (e.g. to stop drawing while the window is not visible).

Maybe this is broken on some Android devices and a problem similar to the one in bug 3202.
Comment 5 Sylvain 2017-08-23 13:24:49 UTC 
@Raincomplex : have you solved your issue ?
Comment 6 Ryan C. Gordon 2018-08-06 21:20:18 UTC 
Hello, and sorry if you're getting dozens of copies of this message by email.

We are closing out bugs that appear to be abandoned in some form. This can happen for lots of reasons: we couldn't reproduce it, conversation faded out, the bug was noted as fixed in a comment but we forgot to mark it resolved, the report is good but the fix is impractical, we fixed it a long time ago without realizing there was an associated report, etc.

Individually, any of these bugs might have a better resolution (such as WONTFIX or WORKSFORME or INVALID) but we've added a new resolution of ABANDONED to make this easily searchable and make it clear that it's not necessarily unreasonable to revive a given bug report.

So if this bug is still a going concern and you feel it should still be open: please feel free to reopen it! But unless you respond, we'd like to consider these bugs closed, as many of them are several years old and overwhelming our ability to prioritize recent issues.

(please note that hundred of bug reports were sorted through here, so we apologize for any human error. Just reopen the bug in that case!)

Thanks,
--ryan.