Apk Built from AppStudio 3.3 Crashes

[RonnieMa1]

Hello,

I have been customizing an application from a template of  3.2 Map Viewer in AppStudio 3.2.

Recently, after an upgrade to AppStudio 3.3, my application crashes as soon as my map loads (and before the features points can be loaded) on the AppStudio Run -- without any messages in the QtCreator General Message pane. I suspect it is an AppStudio version problem, as I return to AppStudio version 3.2, the features can be loaded without problem (on AppStudio Run).

Therefore, I have attempted:

1) cloud make for Android: same problem appears.

2) cloud build on a MacBookPro (for iOS version): same problem.

Please advice if anyone has workarounds or potential solutions to this. Would it be some outdated packages that I have implemented?

 ^Updated  So I have discovered in my code that I added the line in red and lead to the error, it was NOT in the original MapViewer template. (I believe it was in the 100.2 API though? It is in the 100.5 API, but I am unable to find the older API references)

            Map {

                initUrl: mapPage.portalItem.type === "Web Map" ? mapPage.portalItem.url : ""

                // Line below leads to error
                autoFetchLegendInfos: true
                 
                  ...
               }

My question now, is how may I trace trace these errors -- are there procedures that I have omitted? I believe that there must be some methods to traceback to the error. The app did not crash on the devices, but only closed itself. I did not know how I could find the error output -- on Android, iOS and desktop, but to compare the template to my own code.

Thanks,

Ronnie

Sample crash message from Android logcat (cloud build)

--------- beginning of crash
2019-04-23 16:39:54.112 1369-1386/? A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x4900 in tid 1386 (qtMainLoopThrea)
2019-04-23 16:39:54.238 3276-3276/? E/audit: type=1400 audit(1556008794.232:955): avc: denied { search } for pid=1454 comm="crash_dump32" name="com.esri.xxxxxxxxxxxxxxxxxxx" dev="dm-1" ino=329648 scontext=u:r:crash_dump:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=dir permissive=0 SEPF_SM-G930F_8.0.0_0018 audit_filtered
2019-04-23 16:39:54.244 3276-3276/? E/audit: type=1400 audit(1556008794.232:988): avc: denied { search } for pid=1454 comm="crash_dump32" name="com.esri.xxxxxxxxxxxxxxxxxxx" dev="dm-1" ino=329648 scontext=u:r:crash_dump:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=dir permissive=0 SEPF_SM-G930F_8.0.0_0018 audit_filtered
2019-04-23 16:39:54.278 1454-1454/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2019-04-23 16:39:54.279 1454-1454/? A/DEBUG: Build fingerprint: 'samsung/heroltexx/herolte:8.0.0/R16NW/G930FXXS4ESC7:user/release-keys'
2019-04-23 16:39:54.279 1454-1454/? A/DEBUG: Revision: '8'
2019-04-23 16:39:54.279 1454-1454/? A/DEBUG: ABI: 'arm'
2019-04-23 16:39:54.279 1454-1454/? A/DEBUG: pid: 1369, tid: 1386, name: qtMainLoopThrea >>> com.esri.xxxxxxxxxxxxxxxxxxx <<<
2019-04-23 16:39:54.279 1454-1454/? A/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4900
2019-04-23 16:39:54.279 1454-1454/? A/DEBUG: r0 a763add8 r1 00004900 r2 00000000 r3 c8cf44b8
2019-04-23 16:39:54.279 1454-1454/? A/DEBUG: r4 0000000c r5 dbdea8e8 r6 9008001c r7 c8c7e680
2019-04-23 16:39:54.279 1454-1454/? A/DEBUG: r8 90080010 r9 9d93b678 sl 0000000b fp a7850dd0
2019-04-23 16:39:54.279 1454-1454/? A/DEBUG: ip ea473d58 sp c8c7e668 lr ea44aec1 pc c4198ec0 cpsr a00f0030
2019-04-23 16:39:54.283 1454-1454/? A/DEBUG: backtrace:
2019-04-23 16:39:54.283 1454-1454/? A/DEBUG: #00 pc 0052bec0 /data/app/com.esri.xxxxxxxxxxxxxxxxxxx-BpTejyBNnNe0RFnYDq7bKw==/lib/arm/libEsriCommonQt.so (offset 0x51a000)
2019-04-23 16:39:54.283 1454-1454/? A/DEBUG: #01 pc 0051f7a5 /data/app/com.esri.xxxxxxxxxxxxxxxxxxx-BpTejyBNnNe0RFnYDq7bKw==/lib/arm/libEsriCommonQt.so (offset 0x51a000)
2019-04-23 16:39:54.283 1454-1454/? A/DEBUG: #02 pc 00582b17 /data/app/com.esri.xxxxxxxxxxxxxxxxxxx-BpTejyBNnNe0RFnYDq7bKw==/lib/arm/libEsriCommonQt.so (offset 0x51a000)
2019-04-23 16:39:54.283 1454-1454/? A/DEBUG: #03 pc 00582f51 /data/app/com.esri.xxxxxxxxxxxxxxxxxxx-BpTejyBNnNe0RFnYDq7bKw==/lib/arm/libEsriCommonQt.so (offset 0x51a000)
2019-04-23 16:39:54.283 1454-1454/? A/DEBUG: #04 pc 0015b0e7 /data/app/com.esri.xxxxxxxxxxxxxxxxxxx-BpTejyBNnNe0RFnYDq7bKw==/lib/arm/libQt5Core.so (_ZN14QMetaCallEvent13placeMetaCallEP7QObject+30)
2019-04-23 16:39:54.283 1454-1454/? A/DEBUG: #05 pc 0015baf3 /data/app/com.esri.xxxxxxxxxxxxxxxxxxx-BpTejyBNnNe0RFnYDq7bKw==/lib/arm/libQt5Core.so (_ZN7QObject5eventEP6QEvent+250)
2019-04-23 16:39:54.283 1454-1454/? A/DEBUG: #06 pc 00107357 /data/app/com.esri.xxxxxxxxxxxxxxxxxxx-BpTejyBNnNe0RFnYDq7bKw==/lib/arm/libQt5Widgets.so (_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent+152)
2019-04-23 16:39:55.160 3335-3335/? E//system/bin/tombstoned: Tombstone written to: /data/tombstones//tombstone_09
2019-04-23 16:39:55.289 3664-3692/? E/PhoneWindow_APM :: isCalledPackage return false
2019-04-23 16:39:55.300 3187-3187/? E/Sensors: inject_scontext_data: New ssp_data_injection_fd(27)
2019-04-23 16:39:55.371 3197-3197/? E/SurfaceFlinger: removeLayer called with a layer whose parent has been removed
2019-04-23 16:39:55.371 3197-3197/? E/SurfaceFlinger: removeLayer called with a layer whose parent has been removed

[nakulmanocha · Accepted solution]

Hi Ronnie,

Yes, you are correct. This issue has been addressed in the Runtime 100.5 (which got shipped with AppStudio 3.3). Basically, this line is not required at all in the code and should be removed. As in MapViewer we are creating Legends manually to have a better control on which layers to show. In 100.5 Runtime you cannot have both auto Legend creation and manual creation as it leads to a crash. This is more of an internal change. Infact, MapViewer Map control shouldn't have this line at the first place. Initially, template was written to have an automatic legend creation and in the subsequent version I believe (3.0) the manual creation of Legend was added. 

Hence, you should remove that line. It was addressed in the blog below

https://community.esri.com/groups/appstudio/blog/2019/03/01/what-s-new-in-templates-for-appstudio-33...

I hope this helps.

Thanks,

Nakul

[ErwinSoekianto]

cc: ArcGIS Runtime SDK for Qt‌

[RonnieMa1]

Thank you for your response Nakul.

May I follow up with another question.

I'm glad that this can be solved by removing one line of code. But since I have customized quite a bit in my Qml code, would there be other ways to use an older version of Cloud Make? It is not impossible to migrate my code to the new version AppStudio templates, but it is sure a tedious task.

I see that there is a Cloud Make Service URL in the options of cloud make settings, does that mean I can Cloud Make using older api? I tried accessing the following link

https://appstudio.arcgis.com/3.2.79/api

and it results in a JSON like:

{"appfactory":"3.3.110","nodeJS":"v0.10.25","development":true}

Does that imply even using older versions of AppStudio, I cannot build according to the API version corresponding to my AppStudio -- but would be forced to use the latest api?

Thanks again,

Ronnie

[nakulmanocha]

Yes, unfortunately it will be build against Runtime 100.5. But Runtimes are backward compatible. So your functionality won't get affected. This issue mainly about a bug which got addressed in 100.5. Hence it got exposed in Map Viewer.

Another way out is that you can do a Local Make of your app which requires full Qt license.

Thanks,

Nakul

[RonnieMa1]

Okay, thank you Nakul.

Ronnie