codenameone / CodenameOne

Cross-platform framework for building truly native mobile apps with Java or Kotlin. Write Once Run Anywhere support for iOS, Android, Desktop & Web.
https://www.codenameone.com/
Other
1.72k stars 408 forks source link

App stops execution when back command of a Form is executed #1985

Open hrugani opened 7 years ago

hrugani commented 7 years ago

We have a serious and strange problem.

It happens in one specific device, precisely Samsung Galaxy Duos, Model:SM-G360M, using Android 5.0.2 (with security patch 2016-09-01). This model is used by a lot of ours customers. So, this is a big problem for us. The App stops its execution (APP CRASH).

This problem doesn't occurs in other devices with others version of android operational system. We only perceive it on device described previously.

The problem occurs in several points on app, but always in situations where a Back Command of a form is executed.

Follows a typical piece of code where the problem appears:

final Form f =
       new IwFormSummaryRecord(Long.parseLong(idAdmission));

String backTitle = “Back”;
Command backCommand = new Command(backTitle) {
        @Override
         public void actionPerformed(ActionEvent ev) {
                 IwFormAdmissionNavig.this.showBack();  // <<====== here
         } 
 }; 
 f.setBackCommand(backCommand);
 f.show(); 

Also follows a part of logcat captured on device (Samsung SM-G360M) using ADB (command: ./adb logcat -d > log.txt) I guess it can show you some relevant information:

W/ActivityManager( 984): Force finishing activity com.iw.mobile/.IwCareAppStub E/JavaBinder( 984): !!! FAILED BINDER TRANSACTION !!! W/DropBoxManagerService( 984): Dropping: data_app_native_crash (984 > 0 bytes) W/InputDispatcher( 984): channel '2703a121 com.iw.mobile/com.iw.mobile.IwCareAppStub (server)' ~ Consumer closed input channel or an error occurred. events=0x9 E/InputDispatcher( 984): channel '2703a121 com.iw.mobile/com.iw.mobile.IwCareAppStub (server)' ~ Channel is unrecoverably broken and will be disposed! W/InputDispatcher( 984): Attempted to unregister already unregistered input channel '2703a121 com.iw.mobile/com.iw.mobile.IwCareAppStub (server)' I/WindowState( 984): WIN DEATH: Window{2703a121 u0 com.iw.mobile/com.iw.mobile.IwCareAppStub} I/Zygote ( 289): Process 26095 exited due to signal (11) W/ActivityManager( 984): Exception thrown during pause W/ActivityManager( 984): android.os.DeadObjectException W/ActivityManager( 984): at android.os.BinderProxy.transactNative(Native Method) W/ActivityManager( 984): at android.os.BinderProxy.transact(Binder.java:496) W/ActivityManager( 984): at android.app.ApplicationThreadProxy.schedulePauseActivity(ApplicationThreadNative.java:710) W/ActivityManager( 984): at com.android.server.am.ActivityStack.startPausingLocked(ActivityStack.java:905) W/ActivityManager( 984): at com.android.server.am.ActivityStack.finishActivityLocked(ActivityStack.java:2860) W/ActivityManager( 984): at com.android.server.am.ActivityStack.finishTopRunningActivityLocked(ActivityStack.java:2717) W/ActivityManager( 984): at com.android.server.am.ActivityStackSupervisor.finishTopRunningActivityLocked(ActivityStackSupervisor.java:2744) W/ActivityManager( 984): at com.android.server.am.ActivityManagerService.handleAppCrashLocked(ActivityManagerService.java:13566) W/ActivityManager( 984): at com.android.server.am.ActivityManagerService.makeAppCrashingLocked(ActivityManagerService.java:13463) W/ActivityManager( 984): at com.android.server.am.ActivityManagerService.crashApplication(ActivityManagerService.java:14175) W/ActivityManager( 984): at com.android.server.am.ActivityManagerService.handleApplicationCrashInner(ActivityManagerService.java:13691) W/ActivityManager( 984): at com.android.server.am.NativeCrashListener$NativeCrashReporter.run(NativeCrashListener.java:86)

Click on link below to get the entire logcat file: LOGCAT.TXT

OTHERS IMPORTANT INFORMATIONS:

We have a apk generated a couple of months ago where this problem DOESN'T occurs.

We are facing this problem after sucessives updates of "Codename One" infrastructure on the cloud.

For illustrate that, we have a version of our App (IW-Mobile Version b127 that is currently in Google Play and it was upload in google play at 09 Aug 2016). This App works fine. The problem doesn't happen in this apk.

But , today, using the same sources files and commanding the generation of a new apk, this one presents the problem.

In summary, the same source files in different moments offer apk(s) with different behaviors. The old one works fine , but the new one doesn't work.

I suppose this must be at the root of the problem. Maybe it can help you discover cause and fix it.

With the objective of better documentation, I added links for both apk(s) files. The old one (generated at Ago- 9-2016, it works fine) and the new one (generated at Nov-21-2016. it has problems).

Any help with that issue will be well appreciated.

codenameone commented 7 years ago

Try sending a build with 21 API level and see if this works around the issue, if so it will give us a framework to evaluate this regression. See https://www.codenameone.com/blog/switching-on-android-marshmallow-permission-prompts.html

hrugani commented 7 years ago

As you requested, I am sending you a new apk. It was generated using build hint android.tragetSDKVersion=21 and the same sources files as input for CodeName One builder.

Vesrion b127 with API level 21

I installed this apk on device Sumsung (Model:l:SM-G360M). The problem remains.

codenameone commented 7 years ago

We can't do anything with an APK I just asked for you to test it. If you have a pro subscription please try a 3.5 build and see if it works around the issue.

hrugani commented 7 years ago

Sorry my mistake. I tested it and the problem remains as I said in last comment. The new package that was built using "android.tragetSDKVersion=21" also presents the same problem. I don't have a pro subscription. (I have a basic subscription).

I saw another issue (#1973) that seems similar.

1973 was closed newly.

I'm using last distributed version of CodeName One Plugin (3.8). When this fix will be available?

codenameone commented 7 years ago

That issue was closed by the submitter who provided a pull request with the workaround to the Android bug in the browser component.

It looks like you are facing a different native browser component crash:

W/google-breakpad(26243): -----BEGIN BREAKPAD MICRODUMP-----
W/google-breakpad(26243): V WebView:45.0.2454.95
W/google-breakpad(26243): O A arm 04 samsung/coreprimelteub/coreprimelte:5.0.2/LRX22G/G360MVJU1BPI2:user/release-keys
W/google-breakpad(26243): S 0 BEBD12C8 BEBD1000 00003000
W/google-breakpad(26243): S BEBD1000 

I'm not sure how we can workaround it, the browser component itself crashes hard and this doesn't really get to our code. I don't see a place where we can stick an exception handler to try and recover. We can recover failures in the Java side but if the native browser crashes we're stuck...

You will notice that neither your package nor codename1 packages are mentioned in any of the stacks, the crash happens in the native layer and the OS kills the entire app without giving us a chance to recover. I'm not sure why an older version of Codename One worked, maybe Samsung pushed out an update that broke something or maybe it's something minor that we changed that is unrelated to this that somehow triggered this crash. But this is pretty much a needle in a haystack...

Assuming you have access to the device you have the following options:

If you find a workaround within Codename One we'd be happy to incorporate it.

hrugani commented 7 years ago

Thank you for your rich comments. They will help me continue my research. I'll try some of yours suggestions and others that I have in my mind. If I discover news about this problem that can contribute to fix it, I'll add new comments.

hrugani commented 7 years ago

IMPORTANT news: Something changed on Builder between the date when this issue was opened and December 23, 2016. Currently, the new apks generated doesn't have the problem. As a magic all works again. No Crashes. Starting December 23, 2016, "BUIDER" returned to generate apks that no longer present the problem. Would You know what has changed in the "Codename One environment" that could have fixed this problem?