Syncing Mapbox gradle dependencies causes API V23 conflicts

[Jayroo5245]

Hello all, I am attempting to include mapbox maps into an application and I am building with target 22 but it is attempting to make me upgrade to appcompatv7 23.0.1.

IE:

     compileSdkVersion 22
     buildToolsVersion "22.0.1"

When I add this line to my build.gradle dependencies per the documentation:

    //MapBox - https://www.mapbox.com/android-sdk/#gradle
    compile ('com.mapbox.mapboxsdk:mapbox-android-sdk:3.2.0@aar'){
        transitive=true
    }

1. Error here: https://drive.google.com/file/d/0B-K7GJrF0w9RSmxFNFBTVVBxSG8/view?usp=sharing
2. build.gradle: https://drive.google.com/file/d/0B-K7GJrF0w9RaWNQNUFLWV9IcDg/view?usp=sharing
3. Here is a video: https://drive.google.com/file/d/0B-K7GJrF0w9ReU5OVkpnay1aX28/view?usp=sharing

Spamming @zugaldia and @tobrun

PS: One other item, if i upgrade my target sdk to 23 and all my com.android.supports to 23's then it compiles fine.

IE:

    compile 'com.android.support:appcompat-v7:23.0.0'
    compile 'com.android.support:design:23.0.0'
    compile 'com.android.support:cardview-v7:23.0.0'
    compile 'com.android.support:recyclerview-v7:23.0.0'

Thanks! Jared

[tobrun]

@Jayroo5245 Thank you for reaching out and giving such much detail!

Before getting into the details, I must indicate that we at Mapbox try to follow conventions Google is preaching. One of these is keeping our dependecies, target SDK and updated to the newest version. I'm guessing you want to use build tools 22.0.0 to work around not having to deal with runtime permissions?

Now getting into the details why you are seeing the following error:

I believe that error is coming from an android support library. We are using multiple of them in our SDK. Trying to compile them with older build tools will result in these type of errors because those libraries are referencing resources with newest SDK. Building against older SDKs will make these resources unfindable.

The only workaround I'm currently seeing is that you build the SDK from source with older dependencies/buildtools/targetSDK/....

[Jayroo5245]

I wouldn't say I am trying to not have to deal with runtime permissions, but yes that is certainly a benefit. I am confused, why would you require an integrating application to build with API 23? That would rule out a lot of apps I would think.

What is the benefit? I see a huge downside, there are tons of devs out there are still targeting ICS/JB/KitKat. IE Developers like me deciding to look elsewhere for their mapping options. API 23 is only available on 1.2% of all devices as of this morning: http://developer.android.com/about/dashboards/index.html

I think this is a major issue, if I were an engineer at MapBox I would bump it to blocker, and should be addressed as soon as possible.

Again, what is the benefit? Perhaps I do not understand... @tobrun or @zugaldia

Thanks for the quick response =)

Jared

[tobrun]

@Jayroo5245 I think you misunderstand how minSDKVersion, targetSDKVersion, buildtools and compileSDK relate to each other. Since this is not directly related to the Mapbox SDK I will not get in to all the details but here is a brief answer:

why would you require an integrating application to build with API 23?

this is, as shown above, a common best practice.

What is the benefit? I see a huge downside, there are tons of devs out there are still targeting ICS/JB/KitKat. IE Developers like me deciding to look elsewhere for their mapping options. API 23 is only available on 1.2% of all devices as of this morning.

This statement is not true, Android uses something called backwards compatibility. Targeting a certain SDK level doesn't mean your app will not run on lower SDK levels. Our testapp within this repo can run from ICS->Marshmallow.

FYI an app will run fine on older SDK levels until you start using a API that was only introduced later by a newer SDK. This is where support libraries come in to play. They fill up the not implemented APIs with their own implementation. Thus you are able to use new API on older devices.

[Jayroo5245]

I believe I understand minSDKVersion, targetSDKVersion, buildtools and compileSDK quite well.

I understand how they work and how they relate to each other.

What you are saying is that you DO require integrating with API 23 because it is a "common best practice". Google, obviously, would love everyone to move over to the latest API level and this "common best practice" is their way of encouraging you to do so. However, as you pointed out, you do not have to use the latest targetAPI to have your app run due to backwards compatibility.

As an Android SDK library, you are forcing applications to upgrade to the latest API version to integrate. That is going to severely impact your customer base, especially when Google makes a very impactful change such as a new permissions model. The library should not be dictating what sdk version to target or customers will go elsewhere.

"What is the benefit? I see a huge downside, there are tons of devs out there are still targeting ICS/JB/KitKat. IE Developers like me deciding to look elsewhere for their mapping options. API 23 is only available on 1.2% of all devices as of this morning." - What part of this statement is not true? API 23 is only installed on 1.2% of devices that connect to the Google Play store (see above url). So in effect you are forcing developers like me to support a new runtime model that will only be used on 1.2% of devices, for now. That is my point.

Btw, my day job is building an Android SDK library and I would be hung out to dry if I forced my clients to upgrade to an API level that they did not want.

I am not trying to be critical, I understand you have a business to run, but I would very much like to use your library without this requirement. Does that make sense? Wouldn't changing this requirement increase the number of customers that would integrate your library?

Thanks @tobrun and @zugaldia

Jared

[bleege]

@Jayroo5245 Thank you for the super detailed video showing exactly what's going on. It saves a lot of back and forth trying to discern the actual issue. I wish more people would do this when they have questions. :smiley:

I understand that you want to compile your app with Support Libraries at Version 22, while the Mapbox Android SDK has moved on to the latest Version 23. As @tobrun mentioned above our practice is to keep current with Google's latest Support Library releases and that this does allow apps using the Mapbox Android SDK to run on devices in our current support range of Android API 15 / Ice Cream Sandwich and above.

It's unclear what the perfect solution is here, as if we changed the Support Libraries to Version 22 then we'd miss out on bug fixes and other improvements that come via Version 23 which would then impact other customers of the SDK. It's also unclear what to do when the inevitable question would arise from someone who wanted to use Support Library Version 21 or 20 or 19 in their apps instead of "being forced to use Version 22".

We're open to suggestions on this topic and would be happy to consider them.

[Jayroo5245]

Thanks for the response @bleege . I understand the trade offs pretty well. As I mentioned to @tobrun, I have to look at them myself when supporting our customers (More info you are interested: http://driversiti.com/).

I think it comes down to a dinner plate of mashups around what customers want, what engineering can provide with a few sides of tech-debt//performance/ease-of-implementation and a few cool-new-features for desert.

If you surveyed a large group of Android developers, who already have to deal with a fragmented ecosystem, and told them that they were required to change something that is considered sacred (targetSDK version) to pull in a new library, There would be a lot of hesitancy, unhappiness and maybe/maybe not acceptance.

Changing your Java runtime version from 1.6 to 1.7, can be a massive undertaking in most distributed systems. Yes there is "backwards compatibility" and we devs know how well that works. When you do something like change the version of a platform that you compile against, at a minimum you are going to perform a full regression and fix the bugs you find. I do not want to do that just to add a library, no matter how beautiful, fluid or useful it is.

As an Android engineer who builds lots of apps (I've been building them since 2010), I rarely jump on top of the latest version without careful consideration. When Google completely changes how you handle runtime permissions, which is a platform, systemic and user flow change, there are far reaching consequences. Not the least which is that I have to handle an iOS-esque permission model and change the UI/UX of my user flow.

Can I as a dev do it? Sure. Do I want to implement the new permissions model, perform a new build, unit testing, bug fixes (as needed) and full regression before I actually implement anything using MapBox? I think you can answer that for me.

The bottom line is that API 23 is not backwards compatible and is a "braking" change, in that a dev will have to do work to support it. If a customer of mine wants to update to a new version of my SDK and I required API 23, then they would have to make code level changes to support it. That adds friction to an already difficult process.

Make sense @bleege ? I would be interested to hear your thoughts.

Jared

[bleege]

I understand where you're coming from, especially with an existing app's code base that may or may not be targeted at a particular device or version of Android. It's still unclear how we'd support customers who want and expect to use the latest Support Libraries though. Thoughts?

[Jayroo5245]

Why would an integrating app "need" the support library provided by an underlying library?

If the integrating app needs the support library then they include it themselves, right? Why would they need it from MapBox?

Btw, you got me thinking, and an answer to this issue might be "transitive exclusion". There are probably issues based on how MapBox uses these classes, but I excluded your support libraries that were causing the issues and it compiled okay.

---

compile ('com.mapbox.mapboxsdk:mapbox-android-sdk:3.2.0@aar'){
    transitive=true
    exclude group: 'com.android.support', module: 'design'
    exclude group: 'com.android.support', module: 'appcompat-v7'
    exclude group: 'com.android.support', module: 'support-v4'
    exclude group: 'com.android.support', module: 'recyclerview-v7'
}

---

I added a standard mapview via: https://www.mapbox.com/help/first-steps-android-sdk/

---

<com.mapbox.mapboxsdk.views.MapView android:id="@+id/mapview" android:layout_width="fill_parent" android:layout_height="fill_parent"

mapbox:access_token="@string/accessToken"/>

And got this native crash:

I/InjectionManager(27358): dispatchPrepareOptionsMenu :com.pik.kangoo.activities.MainActivity E/libEGL (27358): validate_display:255 error 3008 (EGL_BAD_DISPLAY) E/mbgl (27358): {Main}[OpenGL]: eglCreateWindowSurface() returned error 12296 F/libc (27358): Fatal signal 6 (SIGABRT), code -6 in tid 27358 (ik.kangoo.debug) I/DEBUG ( 5618): * * * * * * * * * * * * * * * * I/DEBUG ( 5618): Build fingerprint: 'Verizon/zerofltevzw/zerofltevzw:5.1.1/LMY47X/G920VVRU4BOK7:user/release-keys' I/DEBUG ( 5618): Revision: '10' I/DEBUG ( 5618): ABI: 'arm' I/DEBUG ( 5618): pid: 27358, tid: 27358, name: ik.kangoo.debug >>> com.pik.kangoo.debug <<< I/DEBUG ( 5618): signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- I/DEBUG ( 5618): r0 00000000 r1 00006ade r2 00000006 r3 00000000 I/DEBUG ( 5618): r4 f7205e38 r5 00000006 r6 0000000b r7 0000010c I/DEBUG ( 5618): r8 1306ef00 r9 f4828000 sl 79e1cae0 fp ff84f318 I/DEBUG ( 5618): ip 00006ade sp ff84f2b8 lr f7059cf9 pc f707d558 cpsr 600f0010 I/DEBUG ( 5618): I/DEBUG ( 5618): backtrace: I/DEBUG ( 5618): #00 pc 0003b558 /system/lib/libc.so (tgkill+12) I/DEBUG ( 5618): #01 pc 00017cf5 /system/lib/libc.so (pthread_kill+52) I/DEBUG ( 5618): #02 pc 00018907 /system/lib/libc.so (raise+10) I/DEBUG ( 5618): #03 pc 000151a5 /system/lib/libc.so (libc_android_abort+36) I/DEBUG ( 5618): #04 pc 00012fec /system/lib/libc.so (abort+4) I/DEBUG ( 5618): #05 pc 003c38b0 /data/app/com.pik.kangoo.debug-1/lib/arm/libmapbox-gl.so I/DEBUG ( 5618): #06 pc 003c3a24 /data/app/com.pik.kangoo.debug-1/lib/arm/libmapbox-gl.so I/DEBUG ( 5618): #07 pc 003b4038 /data/app/com.pik.kangoo.debug-1/lib/arm/libmapbox-gl.so I/DEBUG ( 5618): #08 pc 003b3274 /data/app/com.pik.kangoo.debug-1/lib/arm/libmapbox-gl.so (cxa_throw+240) I/DEBUG ( 5618): #09 pc 000d5ad8 /data/app/com.pik.kangoo.debug-1/lib/arm/libmapbox-gl.so (mbgl::android::NativeMapView::createSurface(ANativeWindow*)+776) I/DEBUG ( 5618): #10 pc 000dbc74 /data/app/com.pik.kangoo.debug-1/lib/arm/libmapbox-gl.so

I/DEBUG ( 5618): #11 pc 0024630d /data/dalvik-cache/arm/data@app@com.pik.kangoo.debug-1@base.apk@classes.dex

Btw, we (the Driversiti SDK) built our app to allow transitive exclusion.

1. I do not want to run into the problem that MapBox is facing.
2. I want to be able to use whatever library I want. For example we use a very standard android library called Volley. Almost half of the major apps that integrate our SDK use Volley. So I allow them to exclude my version of volley and include their version. My SDK uses the version that they include. It would be very similar to a solution for MapBox.

Back to the original question, why would an integrating 3rd party need MapBox to include the google support libraries when they can easily include it themselves?

I can think of a few minor uses:

1. You want to provide a map widget or control that is only available in API 23.
2. Or you want to use some kind of new open gl library provided by the platform. However, looking at the list of stuff there, nothing jumps out: http://developer.android.com/about/versions/marshmallow/index.html

Others?

Does that make sense? What do you think @bleege

Anyway we can get that crash fixed @bleege or @tobrun ?

Thanks

Jared

[bleege]

Good thinking by trying to use the exclusion in the Gradle build file. Before we dive into that any further though, first we need to clarify that this issue is related to the version of the Android Support Libraries that are dependencies of the Mapbox Android SDK and NOT the targetSdkVersion value in the AppManifest of the implementing app. Apps that implement the Mapbox Android SDK can still choose any targetSdkVersion from API 15 to API 23 and run successfully on devices that use these versions of Android.

Ok... now that we've cleared that up. :smile:

Back to the original question, why would an integrating 3rd party need MapBox to include the google support libraries when they can easily include it themselves?

The Mapbox Android SDK currently compiles with 3 of the Android Support Libraries that are all set to Version 23.1.1. They are:

• com.android.support:support-annotations - Annotations Support Library
• com.android.support:support-v4 - V4 Support Library
• com.android.support:design - Design Support Library

The Mapbox Android SDK uses these Support Libraries much in the way that most Android apps and libraries use them... to provide support for functionality that was included in Android versions that come after the minimum versions that we need to support (API 15 in this case). We try to keep use of these to an absolute minimum as we value small dependency graphs and code-bases. It's our goal to provide the best possible maps with as minimal footprint as possible.

So, all that being said how does Mapbox use these? Annotations is pretty straightforward, it's used to provide development and compile time annotation warnings to help limit coding errors and regressions. The Design library is used to provide a consistent user experience / UI with Material Design where we need to utilize Android UI Widgets. Finally, the V4 Support Library is used to provide access to the ContextCompat, ViewCompat, ViewPropertyAnimatorCompat, and GestureDetectorCompat classes so that Mapbox can provide functionality that spans many of the API divides that are inherent in Android.

From what I understand of your issue, your app is fine using these Libraries it's just that the preferred versions are at 22. Is this correct? If so one option around this would be to compile the .aar yourself after changing the version of the Support Libraries to the desired one and then include the dependencies. Another option would be to update to the same versions of the Support Libraries and set the targetSdkVersion to 22 or lower in the app.

In regards to the other questions:

Btw, we (the Driversiti SDK) built our app to allow transitive exclusion.

1. I do not want to run into the problem that MapBox is facing.

Can you help me understand this? I don't see the issue that is perceived that Mapbox has.

1. I want to be able to use whatever library I want.

Absolutely. :+1:

For example we use a very standard android library called Volley. Almost half of the major apps that integrate our SDK use Volley. So I allow them to exclude my version of volley and include their version. My SDK uses the version that they include. It would be very similar to a solution for MapBox.

Yep, Volley is a very popular and widely used library and it's totally possible to use Volley and the Mapbox Android SDK in the same app.

As for the crash that's noted could you tell us what type of device and version of Android it's being run on? This will help us recreate the issue locally so that we can help you resolve it.

[Jayroo5245]

Hello @bleege,

First off I want to say that you and your team have shown great responsiveness and provided in depth discussions during this process. I wish more library providers would give even half the level of support you all have provided.

To your comments:

1. "Apps that implement the Mapbox Android SDK can still choose any targetSdkVersion from API 15 to API 23 and run successfully on devices that use these versions of Android." - Ehhh ok you are "mostly" correct =). To be clear the crux of the issue is that if an app that implements Mapbox, and wants to use the android support libraries (which happens way more then not), then they have to upgrade to API 23 to use Mapbox. Fair?
2. "From what I understand of your issue, your app is fine using these Libraries it's just that the preferred versions are at 22. Is this correct?" - My app just happens to use 22, other apps may want to use mapbox with support libraries below 22.
3. "I do not want to run into the problem that MapBox is facing. Can you help me understand this? I don't see the issue that is perceived that Mapbox has." - I think it is an issue with Mapbox and is how it compiles with high API numbered android support libraries. Does Mapbox really "NEED" to compile with those support libraries? Are there new APIs in the v23 support libraries that Mapbox has to have? All the Widgets, Material design and ViewCompats are probably available in lower support libraries. If Mapbox used v21 or even v22 support libraries then they would allow MANY more customers to use their library, and reduce friction. What shiny new widget is available in v23 that is not available in v20+? I am sure there are some, but I would look for specific examples and decide if you can either do without/use an alternative (likely) or build a custom view for it.
4. "As for the crash that's noted could you tell us what type of device and version of Android it's being run on? This will help us recreate the issue locally so that we can help you resolve it." - Samsung Galaxy S6 - API version 5.1.1

Again, I really appreciate all the time you are taking @bleege . You should get a raise =)

Jared

[Jayroo5245]

Hey @bleege - Just wanted to let you know, I got the same error after tried changing to API 23 and running it. Seems like excluding the libs is not the issue as related to the crash.

---

E/libEGL (13117): validate_display:255 error 3008 (EGL_BAD_DISPLAY) E/mbgl (13117): {Main}[OpenGL]: eglCreateWindowSurface() returned error 12296 F/libc (13117): Fatal signal 6 (SIGABRT), code -6 in tid 13117 (ik.kangoo.debug) I/DEBUG ( 5618): * * * * * * * * * * * * * * * * I/DEBUG ( 5618): Build fingerprint: 'Verizon/zerofltevzw/zerofltevzw:5.1.1/LMY47X/G920VVRU4BOK7:user/release-keys' I/DEBUG ( 5618): Revision: '10' I/DEBUG ( 5618): ABI: 'arm' I/DEBUG ( 5618): pid: 13117, tid: 13117, name: ik.kangoo.debug >>> com.pik.kangoo.debug <<< I/DEBUG ( 5618): signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- I/DEBUG ( 5618): r0 00000000 r1 0000333d r2 00000006 r3 00000000 I/DEBUG ( 5618): r4 f7205e38 r5 00000006 r6 0000000b r7 0000010c I/DEBUG ( 5618): r8 1307e5c0 r9 f4828000 sl 79e31ca0 fp ff84f318 I/DEBUG ( 5618): ip 0000333d sp ff84f2b8 lr f7059cf9 pc f707d558 cpsr 600f0010 I/DEBUG ( 5618): I/DEBUG ( 5618): backtrace: I/DEBUG ( 5618): #00 pc 0003b558 /system/lib/libc.so (tgkill+12) I/DEBUG ( 5618): #01 pc 00017cf5 /system/lib/libc.so (pthread_kill+52) I/DEBUG ( 5618): #02 pc 00018907 /system/lib/libc.so (raise+10) I/DEBUG ( 5618): #03 pc 000151a5 /system/lib/libc.so (libc_android_abort+36) I/DEBUG ( 5618): #04 pc 00012fec /system/lib/libc.so (abort+4) I/DEBUG ( 5618): #05 pc 003c38b0 /data/app/com.pik.kangoo.debug-1/lib/arm/libmapbox-gl.so I/DEBUG ( 5618): #06 pc 003c3a24 /data/app/com.pik.kangoo.debug-1/lib/arm/libmapbox-gl.so I/DEBUG ( 5618): #07 pc 003b4038 /data/app/com.pik.kangoo.debug-1/lib/arm/libmapbox-gl.so I/DEBUG ( 5618): #08 pc 003b3274 /data/app/com.pik.kangoo.debug-1/lib/arm/libmapbox-gl.so (cxa_throw+240) I/DEBUG ( 5618): #09 pc 000d5ad8 /data/app/com.pik.kangoo.debug-1/lib/arm/libmapbox-gl.so (mbgl::android::NativeMapView::createSurface(ANativeWindow*)+776) I/DEBUG ( 5618): #10 pc 000dbc74 /data/app/com.pik.kangoo.debug-1/lib/arm/libmapbox-gl.so I/DEBUG ( 5618): #11 pc 0025b48d /data/dalvik-cache/arm/data@app@com.pik.kangoo.debug-1@base.apk@classes.dex D/CustomFrequencyManagerService( 5939): releaseDVFSLockLocked : Getting Lock type frm List : DVFS_MIN_LIMIT frequency : 2100000 uid : 1000 pid : 5939 tag : LAUNCHER_APP_BOOSTER_CPU@3 I/DEBUG ( 5618): I/DEBUG ( 5618): Tombstone written to: /data/tombstones/tombstone_02 E/ ( 5618): ro.product_ship = true E/ ( 5618): ro.debug_level = 0x4f4c E/audit ( 6156): type=1701 msg=audit(1456363821.442:10569): auid=4294967295 uid=10440 gid=10440 ses=4294967295 subj=u:r:untrusted_app:s0 pid=13117 comm="ik.kangoo.debug" reason="memory violation" sig=6 W/ActivityManager( 5939): Force finishing activity 1 com.pik.kangoo.debug/com.pik.kangoo.activities.MainActivity

[bleege]

@Jayroo5245 Thanks for the update on your progress. Can you share what other library dependencies are in use in the the app? Specifically are there any that also contain compiled native code (ie, .so files) in addition to the Mapbox Android SDK?

The reason I ask is it looks like there may be an issue with cross ABIs in play here as the debug lines consistently refer /lib/arm/libmapbox-gl.so, meaning that the app is looking for the arm ABI version of the Mapbox renderer library and trying to call methods on it. This would be why the Mapbox related error debug lines are referring to OpenGL things such as:

E/libEGL (13117): validate_display:255 error 3008 (EGL_BAD_DISPLAY)
E/mbgl (13117): {Main}[OpenGL]: eglCreateWindowSurface() returned error 12296

The problem is coming about because when Android loads native code in an app it does so only for one ABI and then expects any other native code that the app needs to call to also be accessible to it in that same chosen ABI. In this case the app on your Samsung S6 is choosing the arm ABI and then expects there to be a native .so library for Mapbox. The Mapbox Android SDK currently ships with the following Android supported ABI:

• armeabi
• armeabi-v7a
• mips
• x86
• x86_64

[Jayroo5245]

My gradle file: https://drive.google.com/file/d/0B-K7GJrF0w9RaWNQNUFLWV9IcDg/view?usp=sharing

The only other dependency I have is: https://github.com/logentries/le_android. But I doubt that uses native code.

I haven't done a lot of Native development, but I know the Samsung S6 is using ART runtime which is 64 bit. Perhaps you need to support http://developer.android.com/ndk/guides/abis.html#arm64-v8a ?

I would assume this normally works on an S6 as it is widely distributed...

[bleege]

Thanks for sharing the project dependencies. I'll review the libraries to see which ones are and aren't shipping native code too and post back. Regardless this will help us rule this theory in or out.

I haven't done a lot of Native development, but I know the Samsung S6 is using ART runtime which is 64 bit. Perhaps you need to support http://developer.android.com/ndk/guides/abis.html#arm64-v8a ?

Yep, the Mapbox Android SDK does work on 64 bit devices such as the Samsung S6 (we actually test internally on this device) as well as ART runtime. As for the arm64 ABI, yep that's something that needs to get added and is on the TODO list.

I would assume this normally works on an S6 as it is widely distributed...

It does. If you're interested we have a simple Demo app on the Play Store that we update to use the latest released version of the SDK, in this case 3.2.0. Please feel free to run this app on your Samsung S6 or any other device.

More soon...

[Jayroo5245]

Hello @bleege - Any updates on this issue? I'd like to get Mapbox integrated this weekend.

[bleege]

Hey @Jayroo5245! I'm going to look at this right now. Hope to have more info for you later today.

I'd like to get Mapbox integrated this weekend.

Between you and me I'd start with the 4.0.0-SNAPSHOT. :wink:

[bleege]

@Jayroo5245 I just finished looking through the top level of dependencies in the Gradle build file. As far as I can tell they don't contain any native code. Perhaps a dependency of one of theirs does though? Before diving any further into the dependency graph though, let's pause and confirm some other things first.

1. Does the app implement the Lifecycle methods? The Mapbox Android SDK uses OpenGL which needs to have it's lifecycle managed directly otherwise problems can arrise. For more information on how to do this, please checkout the Examples page.
2. Does the Mapbox Demo App run on the Samsung S6?
3. Does the libs/logentries-android-2.1.5.jar contain any native code? It's not publicly available so I wasn't able to check. Odds are it doesn't, but I'm just covering the bases here.

Finally, while exploring the dependencies I saw that the com.facebook.android:facebook-android-sdk:4.8.2 POM file lists the Android Support Library support-v4 as using Version 23.0.1. It's com.android.support:support-v4:23.0.1. Could that also be impacting the app?

[Jayroo5245]

Thanks for helping @bleege . I updated to 4.0 snapshot and i am getting a different crash/error now:

I followed the instructions here: https://www.mapbox.com/android-sdk/#gradle

Upgraded to v23 support libs:

compile 'com.android.support:appcompat-v7:23.1.1'
compile 'com.android.support:design:23.1.0'
compile 'com.android.support:cardview-v7:23.0.0'
compile 'com.android.support:recyclerview-v7:23.0.0'

//Added the repo repositories { maven { url "http://oss.sonatype.org/content/repositories/snapshots/" } }

//Added the snapshot compile ('com.mapbox.mapboxsdk:mapbox-android-sdk:4.0.0-SNAPSHOT@aar'){ transitive=true }

//Syncs successfully

//And added a mapview to a fragment:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:mapbox="http://schemas.android.com/tools"
    android:orientation="vertical" android:layout_width="match_parent"
    android:layout_height="match_parent">
    <TextView android:text="@string/welcome"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:padding="16dp"/>
    <com.mapbox.mapboxsdk.views.MapView
        android:id="@+id/mapview"
        android:layout_width="fill_parent"
        android:layout_height="fill_parent"
        mapbox:access_token="@string/mapbox_access_token"/>
</LinearLayout>

Crash: I/ActivityManager( 5418): Start proc 18172:com.amazon.kindle/u0a138 for content provider com.amazon.kindle/.map.StandaloneMAPInformationProvider E/AndroidRuntime(18103): FATAL EXCEPTION: main E/AndroidRuntime(18103): Process: com.pik.kangoo.debug, PID: 18103 E/AndroidRuntime(18103): java.lang.RuntimeException: Unable to start activity ComponentInfo{com.pik.kangoo.debug/com.pik.kangoo.activities.MainActivity}: android.view.InflateException: Binary XML file line #10: Error inflating class com.mapbox.mapboxsdk.views.MapView E/AndroidRuntime(18103): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3143) E/AndroidRuntime(18103): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3242) E/AndroidRuntime(18103): at android.app.ActivityThread.access$1000(ActivityThread.java:205) E/AndroidRuntime(18103): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1695) E/AndroidRuntime(18103): at android.os.Handler.dispatchMessage(Handler.java:102) E/AndroidRuntime(18103): at android.os.Looper.loop(Looper.java:145) E/AndroidRuntime(18103): at android.app.ActivityThread.main(ActivityThread.java:6895) E/AndroidRuntime(18103): at java.lang.reflect.Method.invoke(Native Method) E/AndroidRuntime(18103): at java.lang.reflect.Method.invoke(Method.java:372) E/AndroidRuntime(18103): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1404) E/AndroidRuntime(18103): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1199) E/AndroidRuntime(18103): Caused by: android.view.InflateException: Binary XML file line #10: Error inflating class com.mapbox.mapboxsdk.views.MapView E/AndroidRuntime(18103): at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:764) E/AndroidRuntime(18103): at android.view.LayoutInflater.rInflate(LayoutInflater.java:813) E/AndroidRuntime(18103): at android.view.LayoutInflater.inflate(LayoutInflater.java:511) E/AndroidRuntime(18103): at android.view.LayoutInflater.inflate(LayoutInflater.java:415) E/AndroidRuntime(18103): at com.pik.kangoo.fragments.HomeFragment.onCreateView(HomeFragment.java:33) E/AndroidRuntime(18103): at android.support.v4.app.Fragment.performCreateView(Fragment.java:1962) E/AndroidRuntime(18103): at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1067) E/AndroidRuntime(18103): at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1248) E/AndroidRuntime(18103): at android.support.v4.app.BackStackRecord.run(BackStackRecord.java:738) E/AndroidRuntime(18103): at android.support.v4.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:1613) E/AndroidRuntime(18103): at android.support.v4.app.FragmentController.execPendingActions(FragmentController.java:330) E/AndroidRuntime(18103): at android.support.v4.app.FragmentActivity.onStart(FragmentActivity.java:547) E/AndroidRuntime(18103): at android.app.Instrumentation.callActivityOnStart(Instrumentation.java:1250) E/AndroidRuntime(18103): at android.app.Activity.performStart(Activity.java:6538) E/AndroidRuntime(18103): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3106) E/AndroidRuntime(18103): ... 10 more E/AndroidRuntime(18103): Caused by: java.lang.ClassNotFoundException: Didn't find class "com.mapbox.mapboxsdk.views.MapView" on path: DexPathList[[zip file "/data/app/com.pik.kangoo.debug-2/base.apk"],nativeLibraryDirectories=[/data/app/com.pik.kangoo.debug-2/lib/arm, /vendor/lib, /system/lib]] E/AndroidRuntime(18103): at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56)

[tobrun]

java.lang.ClassNotFoundException: Didn't find class "com.mapbox.mapboxsdk.views.MapView" 

Is caused by the move of MapView from com.mapbox.mapboxsdk.views.MapView to com.mapbox.mapboxsdk.maps.MapView. Reasoning behind this was to be more Google maps API compliant from #3500.

To fix the exception above, you should update your layout xml.

[Jayroo5245]

Thanks for the update @tobrun - That resolved the xml crash,

However, I am back to the native crash.

E/libEGL ( 4915): validate_display:255 error 3008 (EGL_BAD_DISPLAY) E/mbgl ( 4915): {Main}[OpenGL]: eglCreateWindowSurface() returned error 12296 F/libc ( 4915): Fatal signal 6 (SIGABRT), code -6 in tid 4915 (ik.kangoo.debug) I/DEBUG ( 5153): * * * * * * * * * * * * * * * * I/DEBUG ( 5153): Build fingerprint: 'Verizon/zerofltevzw/zerofltevzw:5.1.1/LMY47X/G920VVRU4BOK7:user/release-keys' I/DEBUG ( 5153): Revision: '10' I/DEBUG ( 5153): ABI: 'arm' I/DEBUG ( 5153): pid: 4915, tid: 4915, name: ik.kangoo.debug >>> com.pik.kangoo.debug <<< I/DEBUG ( 5153): signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- I/DEBUG ( 5153): r0 00000000 r1 00001333 r2 00000006 r3 00000000 I/DEBUG ( 5153): r4 f7239e38 r5 00000006 r6 0000000b r7 0000010c I/DEBUG ( 5153): r8 1305b600 r9 f4828000 sl 79e342d0 fp ffdd1aa8 I/DEBUG ( 5153): ip 00001333 sp ffdd1a48 lr f708dcf9 pc f70b1558 cpsr 600d0010 I/DEBUG ( 5153): I/DEBUG ( 5153): backtrace: I/DEBUG ( 5153): #00 pc 0003b558 /system/lib/libc.so (tgkill+12) I/DEBUG ( 5153): #01 pc 00017cf5 /system/lib/libc.so (pthread_kill+52) I/DEBUG ( 5153): #02 pc 00018907 /system/lib/libc.so (raise+10) I/DEBUG ( 5153): #03 pc 000151a5 /system/lib/libc.so (libc_android_abort+36) I/DEBUG ( 5153): #04 pc 00012fec /system/lib/libc.so (abort+4) I/DEBUG ( 5153): #05 pc 003e1c70 /data/app/com.pik.kangoo.debug-1/lib/arm/libmapbox-gl.so I/DEBUG ( 5153): #06 pc 003e1de4 /data/app/com.pik.kangoo.debug-1/lib/arm/libmapbox-gl.so I/DEBUG ( 5153): #07 pc 003d23f8 /data/app/com.pik.kangoo.debug-1/lib/arm/libmapbox-gl.so I/DEBUG ( 5153): #08 pc 003d1634 /data/app/com.pik.kangoo.debug-1/lib/arm/libmapbox-gl.so (cxa_throw+240) I/DEBUG ( 5153): #09 pc 000e2290 /data/app/com.pik.kangoo.debug-1/lib/arm/libmapbox-gl.so (mbgl::android::NativeMapView::createSurface(ANativeWindow*)+776) I/DEBUG ( 5153): #10 pc 000e83bc /data/app/com.pik.kangoo.debug-1/lib/arm/libmapbox-gl.so I/DEBUG ( 5153): #11 pc 0025b36d /data/dalvik-cache/arm/data@app@com.pik.kangoo.debug-1@base.apk@classes.dex D/CustomFrequencyManagerService( 5455): releaseDVFSLockLocked : Getting Lock type frm List : DVFS_MIN_LIMIT frequency : 2100000 uid : 1000 pid : 5455 tag : LAUNCHER_APP_BOOSTER_CPU@3 I/DEBUG ( 5153): I/DEBUG ( 5153): Tombstone written to: /data/tombstones/tombstone_00 E/ ( 5153): ro.product_ship = true E/ ( 5153): ro.debug_level = 0x4f4c E/audit ( 7195): type=1701 msg=audit(1456669567.765:1902): auid=4294967295 uid=10452 gid=10452 ses=4294967295 subj=u:r:untrusted_app:s0 pid=4915 comm="ik.kangoo.debug" reason="memory violation" sig=6 W/ActivityManager( 5455): Force finishing activity 1 com.pik.kangoo.debug/com.pik.kangoo.activities.MainActivity

[bleege]

@Jayroo5245 Where you able to confirm that the Lifecycle methods were being implemented and that the Demo App runs on your Samsung S6?

[Jayroo5245]

Hey Brad, sorry i missed some of that. I will verify the lifecycle methods sometime later, i expect that may be part of the problem. In regards to you item number 3, logentries - Here is their repo - https://github.com/logentries/le_android . I don't see a jni folder so they probably aren't using native code.

[bleege]

No worries @Jayroo5245. Just trying to rule things out before moving on to looking for other potential sources of trouble. Speaking of which, I think you're right about the Log Entries library... no native code that I could see in there either. Let us know when you confirm the Lifecycle Methods next.

[cammace]

Hey @Jayroo5245, any update on this or is this issue safe to close?

[zugaldia]

We're now tracking future work to upgrade to API level 24 (Nougat) in https://github.com/mapbox/mapbox-gl-native/issues/6197.

[Jayroo5245]

Hey all, feel free to resolve this if you like. Thanks for all the help.

[zugaldia]

@Jayroo5245 Thank you for your feedback and comments. We'd love your thoughts btw in https://github.com/mapbox/mapbox-gl-native/issues/6197 (not happening immediately).

[ANSB]

After struggling a lot wih same problem, I start to think we were not looking in the right direction. I've an App running on API 15 and I cant' let it run in more recent API. It's a firefifghter app and our volunter firestation have only old Chinese tabletes. While adding the Mapbox code inside may app (coce part from mapBox developper part of the web site) I was unable to compile because of the famous Error:(3) Error retrieving parent for item: No resource found that matches the given name 'android:Widget.Material.Spinner.Underlined'. This have nothing to do directly with MapBox but seems to be an AppCompat problem. After struggling a lot I decided to create a new project (so from scratch) and used Jayroo5245's example code. After 10min I had the Chicago's map on my old chinese device running a prehistorical version of Android. So... it works! After that, it was easy to cut and past part of my main App to add them, step by step inside this example. Rather than adding a "stranger" code we know a little about, inside our app, in many cases it's easier to create the basic "stranger app" and then add our own code, which about we know a lot, inside this "stranger app".

[zugaldia]

@ANSB Thanks for the feedback. Once you compared both versions of the app, did you manage to identify the root cause of the error? Was it a library? Was it some code?

[ANSB]

Seems to have a link with AppCompat. Even if you are able to avoid the "'android:Widget.Material.Spinner.Underlined'" you'll get imediatly a second problem with another object. Now my gradle is:

repositories { mavenCentral() }

dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) androidTestCompile('com.android.support.test.espresso:espresso-core:2.2.2', { exclude group: 'com.android.support', module: 'support-annotations' }) compile 'com.android.support:appcompat-v7:24.2.1' testCompile 'junit:junit:4.12'

compile('com.mapbox.mapboxsdk:mapbox-android-sdk:4.1.1@aar'){
    transitive = true
}
compile ('com.mapbox.mapboxsdk:mapbox-android-services:1.1.0@aar') {
    transitive = true
}

}

styles.xml is:

``` ```

and that's OK. So, nothing to do with the code.

[zugaldia]

@ANSB Thanks for the snippets.

[dagatsoin]

I think this should deserve a part in the doc. I am not sure how to generalize this, but I have struggled for hours on this while updating the cordova mapbox plugin dep to 5.0.1

This snippet worked like a charm:

compile ('com.mapbox.mapboxsdk:mapbox-android-sdk:5.0.1@aar'){
    transitive=true
    exclude group: 'com.android.support', module: 'design'
    exclude group: 'com.android.support', module: 'appcompat-v7'
    exclude group: 'com.android.support', module: 'support-v4'
    exclude group: 'com.android.support', module: 'recyclerview-v7'
}

[tobrun]

@dagatsoin thanks for flagging, will add it to our documentation repository. FWIW I use ./gradlew :module_name:dependencies to analyse these kind of conflicts.