[MOD-2428] Module will not build following update of SDK from 7.0.2 -> 7.1.0+
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Critical |
| Status | Closed |
| Resolution | Done |
| Resolution Date | 2018-06-28T18:13:58.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | n/a |
| Components | n/a |
| Labels | n/a |
| Reporter | Greg |
| Assignee | Yordan Banev |
| Created | 2018-05-23T09:32:11.000+0000 |
| Updated | 2018-06-29T10:06:57.000+0000 |
@jquick I would very much appreciate your insight on this issue.
[~jquick], Can you please take a look at this? Thanks.
Thanks for looking into this Yordan - it's good to now have an understanding of why it is broken! I've two questions really now: 1) what is the implication of using this module (ti.goosh) compiled against GPS 11.8 with sdk 7.0.2 in our app built with 7.1.x ? we include the updated 11.8 ti,playservices in another module as we need to support the updated google sign-in api. I presume the app when built now contains the updated version of playservices base and the 11.0.4 base included in the SDK? (though doesn't seem to complain when being built) - sorry if I sound confused, I'm just not sure how this all gets assembled into the runtime. 2) going forward, when will the platform officially support the updated play services libraries? as 11.0.4 is really out of date at this point and can't support many newer features. Separately, is it not the case that really the SDK should have no tied in GPS version, or to put it another way, is it not possible to support the GPS supported SDK functionalities through the ti.playservices module? thus making GPS independently versionable?
Thanks Yordan, As I understand it, the updated ti.playservices module i'm using must be packaged in the app build as it is a dependency of both modules I'm using (ti.goosh and our own module) - AND - the required new google sign in functionality (not present in 11.0.4 jars) works well. My real concern then is that there are potentially duplicated albeit different versions of the SDK included jars classes (GPS base,basement,location & tasks). I could possibly patch the SDK locally with updated versions of the jars as per the updated 11.8 ti.playservices module, but I'm not sure if that would cause any breaking changes to the SDK as I'm not presently compiling it from source? Is there a good reason the SDK now has a new GPS tied dependency? This seems pretty inflexible and is something we definitely need to resolve to be able to continue to update inline with GPS api enhancements. IMO This really should be out-factored to the ti.playservices module or one that has a dependency on this if possible. I'm familiar with the explanation provided in TIMOB-25665, and in our case we've implemented the prompts through our own module for the user to update GPS and confirm the availability. I don't think this as a reason in itself is good enough to now in mid-2018 add a tied dependency to an older GPS version in the latest SDKs. I need a workaround until there is official support for later GPS versions, what would you suggest for now?
[~miniman42], one of the intentions of "ti.playservices" is to resolve library version conflicts between modules. This has been a very common issue for us in the past. For example, if 2 modules included their own copy of Google Play Services of different versions and the older version happened to "win" and be the one to be included in the app build, the other module would crash because the newer APIs could not be found. So, the way to resolve this for now is for all modules to agree to use the same Google Play Services library via our new "ti.playservices" module. Now, the only reason why "ti.playservices" isn't using the newest version of Google Play Services is because this module is not set up to auto-update/install the Google Play Services APK background service on app startup yet (see: [TIMOB-25726]). If the installed Google Play Services APK is older than the library, then the library's APIs will fail to work and/or throw exceptions. So, until this is done, "ti.playservices" needs to use an older version of Google Play Services to avoid this issue for the moment. But once done, we'll take the responsibility of keeping "ti.playservices" up-to-date. (And while you might be displaying the dialog to install/update Google Play Services, the vast majority of Titanium developer are not. So, this avoids a massive tech-support issue on our end.) Here's what you can do to work-around this and use the newest version.
Create the following folder under your Titanium project:
./modules/android/ti.playservicesCopy and paste the newest installed "ti.playservices" folder version to the above folder. On a Mac, this module can be under
~/Library/Application Support/Titanium/modules/android/ti.playservices/11.0.40.Under your project, you should now have a folder like this:
./modules/android/ti.playservices/11.0.40.Rename the
11.0.40folder name to the version you want to use. For example,11.8.00.Under this module's "lib" folder, replace all of the AAR files with the newer versions.
The above will work because modules under your project's directory take priority over the globally installed ones. Just note that you still need to ensure that the modules you are using (ti.goosh) is set up to depend on "ti.playservices" and its Google Play Services libraries. Meaning that if you use any modules that keep their own copy of Google Play Services libraries, then you still run the risk of version conflict. The idea here is that all modules need to delete their copies of the Google Play Services libraries and use the ones bundled under "ti.playservices", avoiding version conflicts.Thanks Joshua, I fully understand the concerns you’ve listed above and infact your suggested workaround is exactly what I’m doing! The point I’m making is now that with the release of SDK 7.1.x things are broken due to a hard playservices 11.0.4 dependency in the SDK source directly (not in the ti.playservices module). This is why we now cannot build modules with updated ti.playservices as a module dependency. Please see my earlier comments as we now need a workaround to avoid the clash of the 11.0.4 dep in the SDK!
Okay. I see what the issue is. Starting with Titanium 7.1.0, the following libraries are being included with Titanium core libraries. Note that these libraries are *NOT* supposed to be there. Especially since they're useless to Android apps that are not deployed on Google Play, such as Amazon's Android app store: * play-services-base-11.0.4.jar * play-services-basement-11.0.4.jar * play-services-location-11.0.4.jar * play-services-tasks-11.0.4.jar On a Mac, you can see the above by going to the following folder. These are causing the version conflict.
~/Library/Application Support/Titanium/mobilesdk/osx/7.x.x/androidHow it is supposed to work is that Titanium's core "geolocation" code will dynamically check for the Google Play Services classes via reflection, and if available, use them. It's not supposed to include the libraries, but it looks likes our packaging system has inadvertently included them by release. I apologize for the confusion. For now, I recommend that you delete the above 4 JAR files from the Titanium version you are using. They are not supposed to be there. And our geolocation code does correctly work without them. I've re-tested it and confirmed that our geolocation code will fall-back to the OS' location APIs in this case.Thanks Joshua, that's great - I'll give it a go!
I've scheduled to have these 4 JAR files removed from the SDK in the near future. Thank you for reporting this issue. Ticket: [TIMOB-26131]
[~miniman42], did what I recommend solve the problem? I'm just following up here.
Hi Joshua, yes it works perfectly now with the jars removed from the SDK sources. Thanks for the help.
[~miniman42], [~jquick] Should we close the ticket as it has provided a workaround and we have a fix for the problem in another one (already resolved)?
[~miniman42], for your info, the 4 conflicting JAR files will be removed in Titanium 7.3.0.
Thanks Joshua, appreciate the support.