We compiled WebRTC based on souce code ,using code of milesone m91,and with sctp not built.
1.Our code is based at WebRTC m91
2.usrsctp is disalbed and not built by setting these values to false in WebRTC.gni,so that usrsctp won't be built.
1) rtc_enable_sctp=false
2) rtc_build_usrsctp=false
3.build libjingle_peerconnection_so.so by command
autoninja -C out/arm libjingle_peerconnection_so
4.integrate the compilied libjingle_peerconnection_so.so to App and submit it to google play store
Though usrsctp is not built,however,the google play store detects that I'm using a vulnerable versions of WebRTC use usrsctp.
Here is the FAQ from google play store.
How to fix apps with bad WebRTC versions
Here is my questions
Question1：
How does google store dectect that I'm using a vulnerable versions of WebRTC use usrsctp ?The rules are not clear to me .
by scanning the symbols in .so ?
by scanning the meta infos ?
Question2:
Is there a way to know the version of WebRTC that libjingle_peerconnection_so.so is built from ?
In other words,given a specific so file libjingle_peerconnection_so.so ,How can I know that it's built from M91 or M102 ?Is there any meta informations about the version of WebRTC we are used in the compiled products ?
WebRTC M012 or higher is required to pass this check on Play, even if usrsctp is removed. While usrsctp is our most pressing concern, many other security issues have been fixed in other components. It is highly recommended that you update to a more recent version, and be prepared to update on an on-going basis in the future if more serious vulnerabilities.
Please don't attempt to circumvent this check in Play, as you will miss important notifications about future security issues, and there is no guarantee that detection will remain the same
I've filed an issue to WebRTC Issue 14664: usrsctp is not built but detected by goolge play store
Related
Even though the Dev Board Micro is not technically out yet, I wonder if I could already download the toolchain/sdk/etc.
I'm planning on using the same MCU and the Edge TPU, so I guess I already can make some use of them!
According to this official video, there are two "development paths" available (CMake scripts and arduino-cli) plus there's an OOBE. However there are no actual links to be found, which makes sense since the product is not out yet.
But just in case I still wonder if they are already available somewhere?
I want to have Meteor as a server and Ionic2 as a client. I currently have a headache with authentifiacation. It seems that there are two different approaches:
First is use of Meteor server and Meteor client with ionic-angular library. This approach described here
https://angular-meteor.com/tutorials/socially/angular2/ionic2
I guess the advantage of this method is use of Meteor native architecture, on the other hand I guess we're using Ionic2 just like a subframework and maybe loosing some stuff from native Ionic2.
The second is using separate Meteor server ('client' folder deleted completely) and native Ionic2. This approach described here
https://angular-meteor.com/tutorials/whatsapp2/ionic/authentication
This option is vice versa: use of native Ionic2, but it has to use libraries like meteor-client-side, accounts-base-client-side, accounts-password-client-side etc, which I'm not sure are native for Meteor.
The first approach looks better, because there is a ready-to-use UI component for authentification. But I wonder what issues I would have, when I come to the step of completing my applications for different types of devices.
Thank you in advance for your help.
These approaches are essentially the same for the authentication itself.
What you are pointing out is more about what mobile platform to choose to develop and run mobile projects.
In the first case, you use Meteor's built-in Cordova platform to run the app and Meteor's compiler and bundler plugins (like TypeScript package or Meteor core packages for Babel and UglifyJS etc) to develop the app. In the second case, you develop and run the app solely on Ionic 2 CLI.
But from the app logic point of view these approaches are absolutely same: you import the same Ionic 2 components and use the same Meteor packages with the only difference in the second case is that these packages are now NPMs not Atmosphere ones (essentially though they contain the same scripts since these NPMs are built from Atmosphere packages).
The reason why What’sApp clone is built in that way that differs from the Socially’s one is simply described in the README of
the What’sApp repo (see https://github.com/Urigo/Ionic2CLI-Meteor-WhatsApp). If to repeat: since Ionic is a one of the best Web frameworks that specializes solely in building mobile apps, it’s reasonable to guess that it’ll be (and likely it is) much more powerful in building them than Meteor itself. From that point of view the second approach seems more future-proof, I would say. You could think even of building your project in some way that will allow you to substitute Meteor easily with some another framework if you decide to use it at some point in the future.
If you are though concerned about using those NPMs mentioned in the second case (e.g., if the process of building them doesn’t look transparent to you), you could try this project https://github.com/Urigo/meteor-client-bundler to bundle Atmosphere packages you need into separate scripts and use them after.
Our product version follows Semantic Versioning with an extra digit for build package identification:
major.minor.patch.build
The first 3 parts are for source code versioning, depending on API compatibility and bug fixes (patches). The last part is to keep track of multiple build packages. Multiple builds can happen with no source code changes (therefore no changes to major.minor.patch). Reasons for multiple builds are numerous all relating specifically to Android APK packaging (such Icons missing/changed, minSDKVersion increases, permission changes, SDK updates, descriptor-file changes [we are using AIR], etc)
Unfortunately, Google Play does not recognize this 4-part version. It only recognizes the first 3 parts. Example:
2.3.1.1 - Uploaded, received warning about SDK/API min version mismatch.
2.3.1.2 - No source code changes, only bumped minSDKVersion in manifest.
As far as Google Play is concerned, both are version 2.3.1 (2003001)
Why does it matter?
In order to test In-App-Billing (IAB) purchases, a version has to be published to Alpha (or Beta or Production). Once published, you cannot upload another APK without incrementing the version. As far as we are concerned, we are incrementing the version, but Google doesn't recognize that. For us, to bump the patch number when there were no source code changes is stupid and goes against the company versioning scheme which spans many more platforms then just Google Play.
So what to do for IAB testing?
- We distribute APKs to QA internally (not through Google Play), however we are still required to publish an APK to Alpha in order to test IAB.
- Without publishing an APK with increased version number, IAB testing errors out (APK version on device cannot be higher than the latest uploaded APK in Google Play)
How do others handle this?
When i try to use the statement google.load("dojo", "1.6.1") in a web app I am developing, I receive the error:
Module: 'dojo' with version '1.6.1' not found!
This latest version of dojo, enables a certain amount of support for IE 9.0, and that is why I need to reference it. Is this supported by Google as a library? Either way, if anyone has suggestions as to how I can work around this?
1.6.1 is not yet in the Google ajax library repositories. See the latest version note here. I'm sure it will be within a day or two. There is a note on the dojo download page in big red letters saying that the CDN's are still behind on 1.6.0 and saying where to get notified when they are updated.
You can always use the "1.6" nomenclature to always have the latest version and your app will move up to 1.6.1 as soon as it hits the Google CDN. If a couple days is really going to make or break you you should consider compiling and using your own local version. Dojo makes this really easy.
I have recently been browsing frameworks such as JavaScriptMVC, qooxdoo, Sproutcore and others alike which are using javascript to create desktop-like apps in the browser with minimal, or none css/html (depending on the framework).
What I know of titanium is that it uses html/css for the views, and language of choice (javascript, ruby,python,php) for everything else. Then it gets compiled(?) into a native app.
What are the quirks? if any?
Is it necessary for the user to install some sort of a runtime to execute the compiled app?
I suppose javascript is the prefered language, but how are the other ones handled?
For example, which Ruby interpreter would be included, would I be albe to use the ruby stdlib or external libraries? Would it affect the speed of the app? I.e JS > Ruby in terms of speed.
Since the views are CSS/HTML, would it still be necessary to style the elements, add them effects via JS librarier to achieve a widget-like feeling? Or does it come with some pre-made settings/classes for that?
I am not sure if it applies to the desktop package, but is there some syncing with the appcelerator's server required? What would it be necessary for?
I am sorry if the questions sound stupid, but I didn't even realise there are than many tools until recent. I am ultimately looking for something which is easy to use, has an option to work with a back-end server for data exchange, looks preferably good 'out of the box' or doesnt require that much work to get it themed nicely and works on mobile as well as desktop devices.
With Titanium you build your app out using javascript. Titanium ultimately generates its own XCode project for you that is compiled and deployed to a device.
The user does not require any runtime be installed prior to installing your app.
Unless your building custom modules to hook up your own controls you stick with javascript.
Your javascript calls end up as native controls, early versions required css like styling due to reliance on webkit but this is no longer the case.
There is no IDE but it does come with an app to create Titanium projects, test in emulator, deploy etc. It also talks back to HQ for updates.
In answer to (2), Titanium Mobile is Javascript only, but Desktop also supports Python, Perl and PHP.