Syncing Mapbox gradle dependencies causes API V23 conflicts #4072
Comments
|
@Jayroo5245 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/.... |
|
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 |
|
@Jayroo5245
this is, as shown above, a common best practice.
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. |
|
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? Jared |
|
@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. 😃 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. |
|
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 |
|
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? |
|
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. I added a standard mapview via: <com.mapbox.mapboxsdk.views.MapView mapbox:access_token="@string/accessToken"/>And got this native crash:I/InjectionManager(27358): dispatchPrepareOptionsMenu :com.pik.kangoo.activities.MainActivity I/DEBUG ( 5618): #11 pc 0024630d /data/dalvik-cache/arm/data@[email protected]@[email protected]Btw, we (the Driversiti SDK) built our app to allow transitive exclusion.
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:
Others? Does that make sense? What do you think @bleege Anyway we can get that crash fixed @bleege or @tobrun ? Thanks Jared |
|
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 Ok... now that we've cleared that up. 😄
The Mapbox Android SDK currently compiles with 3 of the Android Support Libraries that are all set to Version 23.1.1. They are:
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? 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 In regards to the other questions:
Can you help me understand this? I don't see the issue that is perceived that Mapbox has.
Absolutely. 👍
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. |
|
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:
Again, I really appreciate all the time you are taking @bleege . You should get a raise =) Jared |
|
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) |
|
@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, 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 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
|
|
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... |
|
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.
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
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... |
|
Hello @bleege - Any updates on this issue? I'd like to get Mapbox integrated this weekend. |
|
Hey @Jayroo5245! I'm going to look at this right now. Hope to have more info for you later today.
Between you and me I'd start with the |
|
@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.
Finally, while exploring the dependencies I saw that the |
|
Thanks for helping @bleege . I updated to 4.0 snapshot and i am getting a different crash/error now: I followed the instructions here: Upgraded to v23 support libs: //Added the repo //Added the snapshot //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: |
Is caused by the move of MapView from To fix the exception above, you should update your layout xml. |
|
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) |
|
@Jayroo5245 Where you able to confirm that the Lifecycle methods were being implemented and that the Demo App runs on your Samsung S6? |
|
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. |
|
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. |
|
Hey @Jayroo5245, any update on this or is this issue safe to close? |
|
We're now tracking future work to upgrade to API level 24 (Nougat) in #6197. |
|
Hey all, feel free to resolve this if you like. Thanks for all the help. |
|
@Jayroo5245 Thank you for your feedback and comments. We'd love your thoughts btw in #6197 (not happening immediately). |
|
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". |
|
@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? |
|
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 { dependencies { } styles.xml is: and that's OK. |
|
@ANSB Thanks for the snippets. |
|
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: |
|
@dagatsoin thanks for flagging, will add it to our documentation repository. FWIW I use |
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:
When I add this line to my build.gradle dependencies per the documentation:
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:
Thanks! Jared
The text was updated successfully, but these errors were encountered: