Recently I've been working on integrating a GRPC API in a size sensitive android app. The API only had a couple of Unary calls. I noticed that the resulting APK had io.grpc (613KB) & io.opencensus (178.9KB) which was further reduced to 387.2KB and 39.4KB respectively using Proguard. I noticed that Proguard was able to remove many streaming call related classes/methods from the APK. However, I noticed that the app already had com.google.protobuf package, which I suspect is from something like Firebase SDK.
If Firebase SDK imported com.google.protobuf, why didn't it need io.grpc for transport? Does it use something else?
The protobuf protocol is used by some Firebase SDKs as part of their internal communications. The first one that comes to mind is Firebase Analytics, but there are others too.
The Cloud Firestore SDK in Firebase uses grpc as part of its transport protocol. If you're not using Cloud Firestore then the grpc library will not be included as far as I know.
To ensure that unused methods are removed, be sure to use ProGuard as part of your release build.
Related
In our javafx mobile application, we are using Okhttp3 4.9.1 for http requests. One of our developers told me that even if we specify Okhttp as an external dependency, in android device it will only use the Okhttp bundled with android. So I just wanted to verify it and tried to print the okhttp versions at the runtime like this one. It didn't work (ClassNotFoundExceptions). So, my question is,
Do javafx mobile apps use 'okhttp bundled with android' or the one that we specified as a dependency?
How to get the version of 'okhttp' bundled with android in javafx mobile application?
If you bundle OkHttp in your app it will use that version instead of the built in Android version. They differ in package also, so you can't easily mistake them. I don't think you can directly use https://android.googlesource.com/platform/external/okhttp/+/master/repackaged/okhttp/src/main/java/com/android/okhttp/OkHttpClient.java in your app, but I'm not certain.
You should be able to use okhttp3.OkHttp.VERSION directly, but it has a bug that it's const value and so inlined at compile time. So you can read this using reflection, assuming proguard isn't applied and moving the classes.
You can also look at the default user agent in an interceptor which uses this version field.
Class.forName("okhttp3.internal.Version") won't work because it's an internal detail and has since moved. It got moved in 4.7.0 https://github.com/square/okhttp/commit/72cb889c867481c578bce663d3ea0d92e648fcac#diff-6e62984ccabc6dc7bb9bbda58768b4af28bf789f6415d09c2d89de4387ecf816
I have an apk and ipa, I was wondering if it is possible to inject Firebase analytics to them. Similar to other wrapper applications that allow to inject their code into an apk or ipa. Is this possible with Firebase? I have not been able to find information regarding Firebase injection.
I won't tell you that it's impossible to add Analytics to an existing APK, but what you're trying to do definitely isn't supported by Firebase. The only supported course of action is to add the SDK at compile and build time.
If you wanted to add the SDK after the app is built, you would have to go through the trouble of decompiling the APK, modifying the decompiled app components to include the SDK, then rebuild the APK altogether. There is no way to easily "inject" the SDK into an existing app.
I have built a project with all Firebase features including Firebase Performance Plugin. Now we are trying to make it as Library, While trying to convert from Application to Library we are facing an issue from Firebase as
ERROR: FirebasePerformancePlugin must only be used with Android application projects. Need to apply the 'com.android.application' plugin with this plugin.
May I know the reason why I am facing this issue. I am excepting a quick reply from the Team.
Thanks in advance
As the error suggests, Firebase Performance Monitoring is not supported for libraries, only apps. You currently can't use the product to collect performance information for you library if it gets integrated into other apps. You can only use it for monitor the behavior of a specific app that's added to your Firebase project.
If this is not what you want, you can file a feature request with Firebase support. Though, for this request, I suspect nothing will happen in the short term.
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.
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.