Im sure I saw an official guide on this on the conscrypt project site but I cannot find this at all now.
Im wondering to the possibility of building BoringSSL locally and making it available via a bundled JCE Provider i.e. Conscrypt. I can see the BoringSSL project has build instructions but cant see anything about bundling Conscrypt.
Did I dream this was a thing people were doing?
Maybe updating the provider through GPlay, is good enough, but I would like to avoid interfacing with GPlay services if poss (as it can be quite frustrating) but maybe in this case its the lesser of two evils!
Thanks for any info :)
EDIT: Just found this barebones guide to building conscrypt. Conscrypt has a JNI component but assuming this talks direct to BoringSSL. Quoting the BoringSSL intro
We don’t recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
How would I make sure that Conscrypt JNI -> BoringSSL are compatible versions I wonder?
Related
In my current project we're working on mantaining/developing mobile (android/iOS) apps that use the services of the client's website (liferay 6.2). Whenever the guys in Backend generate new services (or just update an existing service to a new version with new features) we need to use the Liferay Mobile SDK 6.2.18, which uses really dated gradle 1 and http protocol, to generate a new jar library to allow the app call those new services.
As I guess many will know already, gradle recently deprecated HTTP in favour of HTTPS, and maven shortly after followed suit, so now we are completely unable to generate the jar libraries.
Unfortunately, our client won't accept upgrading Liferay to 7 - which Backend guys tell me would solve this bump in the road - so we need to find a workaround to this situation. I've tried searching both google in general (filtering by last month results) and SO in particular, but no dice.
Has anyone else here who found themselves in this situation managed to work around it?
I have a project using an old version of google play services that I need to keep otherwise it would need to be heavily rewritten. Now I have added a new library that uses a newer version of google play services and I get a duplicate class error.
How can I force android studio to use the newer version of google play services in the library for the library but also be able to use the older version in my app?
Unfortunately, this isn't possible. The classes for your app and the library are combined to form your APK, so you can only have one version of a given library. You could force it to use one of the two versions (for example, something like this), but based on your statement that it would need to be extensively rewritten, I assume that the two versions are not API compatible.
There are utilities like Jar Jar Links that can solve this in some cases, but (especially based on the embedded proguard rules, which reference classes found via reflection) I'd be surprised if it worked in the case of something as complex as Google Play Services, which is likely depending on its class names remaining unchanged.
Please note: although I specifically mention AngularJS, Ionic and Cordova here, I'm really talking about any mobile app (hybrid and native alike) that produces binaries for iOS and Android platforms. As such, I believe that anybody with experience in mobile dev should be able to address the question!
I am building a mobile app for iOS and Android using AngularJS, Ionic and Cordova. My concern is that iOS and Android release updates all the time, some may be buggy or just might be outright breaking changes and all of the sudden become incompatible with the plugin/library versions that I'm using.
This will cause apps to crash spontaneously in production. But it sheds light on an even nastier problem under the hood: making the decision to pin your builds against specific dependency (plugins/libraries/etc.) versions or just always pull in the latest/stable versions of them!
Option 1: Pin your dependency versions
Here we specify the exact version of all dependencies to use. We then fight with the Ionic build to get the app built, but are now good to go. I can expect that if I don't change any of my code, that each subsequent build of the app against the exact same dependency versions will always result with a successful build.
However, when iOS/Android does release a breaking change or bug (or anything that prompts the library/plugin maintainers to go into a frenzy and publish new versions of themselves), because I've pinned my previous build to specific versions of dependencies, I may actually be running on very old dependency versions and it will now be a massive headache to get my app building again against all the latest versions.
Option 2: Use latest/stable versions at all times
If I don't specify dependency versions (and just let the build always use latest and greatest), then I could work fervently to get my app building, then wait a few days (and not change any of my own code) and then try building it again and the compile/build might fail! This is because in between those few days, some project upgraded itself and/or its own dependencies and introduced a build-breaking change.
However, when iOS/Android releases a breaking change that requires me to upgrade to latest dependencies, the headache would likely be considerably less then Option 1 since I'll be on a relatively much newer version of all my dependencies.
Are there any tools/strategies/techniques/etc. that the mobile community leverages to stabilize builds and make it so that I can have more consistent, repeatable builds?
It is recommend to use specific version of your dependencies, you may consider using the notion * at the minor patch level X.Y.* to get the lastest bug fixes.
Your build should be automatic and consistent, there are products that do this for you, e.g BuddyBuild and Buddy support both Android and IOS.
Successful builds is not the whole thing, The app should pass all the functionality and QA tests before a release. So you need to write as much as UnitTests and FunctionalTest to cover the quality checks. There are other QC tools for even further assurance, For example static code analysis tools help you to discover potential bugs and failures, And test coverage tools let you know which parts of your code has not been tested yet.
Here is a Simple CI/CD workflow
Code -> Push -> CI Test -> CD Publish Release
You can set a job to build your project on a weekly basis on the CI server and Publish a Release only if it passes all the Quality Checks
Apps crashing on the new OS versions is not a catastrophic problem, it's common and has its solution, Google and Apple don't release new OS versions to users just like that, Developers are provided with preview builds of the OS and new APIs, Developers usually have more than 2 month to adopt thier apps with the new changes and even use the new API features.
And by the way you have access to crash reporting tools like Fabric.io and Firebase which helps you to discover problems at production.
Cheers
I'm really new with android developing. But I know how to upload a library to GitHub and include it in an android project. Recently, I'm working on some android apps, and I realized that I need to use some layouts and classes for all the apps. So, I created an android library and kept that inside all the project files. Then I came to know that I can simply upload that library to GitHub and use it for all the projects. But I'm not sure if it's a good idea. Is there any advantage if I upload it to GitHub?
In general, using a source control (git or other ones) is always a good idea given that your local filesystem can crash or you may want to revisit certain revisions you made to your project. Github is very popular and hosts several highly used projects, so it is no doubt a good place to upload. However, you must know that if you don't have their paid account, the project will be public (at this time, free accounts don't have a way to create private projects). Are you developing as hobby and do you mind if others see / take the code and reuse (hopefully under the licensing terms you specify)? Or is that something you're doing for an employer? In that case you should consult with the employer if this is OK.
Now as for sharing this module across projects, I don't think github has a secret sauce here. You could always build your library once and drop it in as dependency into all your apps, without having to copy its source code into each project. You may also want to look into integration with maven / gradle build systems, which Android Studio uses. For example, third party libraries often are available as downloadable libraries from maven central, and you can add a couple of lines to your build.gradle to go fetch a specific version of your library from maven central, rather than manually adding that library jar to the project that is using it. If your library code is on github, there are ways to publish to maven central from github ( http://datumedge.blogspot.com/2012/05/publishing-from-github-to-maven-central.html ) but I don't have experience with that step.
Does anyone know how to configure this correctly in Eclipse? Somehow I have both google-api-client-1.16.0-rc.jar (as an example) and 1.17 libs on the client. The 1.16 libs are generated by the GAE project when generating endpoints, not sure how the 1.17 libs got there. If I delete all the 1.16 libs on the client the app runs fine but I would really like to configure to the latest version.
I wouldn't mess with the libs generated for cloud endpoints. If it generates 1.16 then that is what endpoints is tested with, and probably what everyone else using endpoints is using. And I believe 1.16 is correct anyway - that's what my projects are using. The fact that it is one version behind (1.17 is current) is not a problem really - the google java client libraries have changed very little over the last few versions.
You can make sure you have the latest GPE (and you probably do since you get notified when updates are available), since this plays a role in endpoints, but like I said, I think 1.16 is correct for endpoints.
If you need Google Java Client Library for your own stuff, in the same project, I would personally stick to that same version - 1.16 - but you don't have to.