I was trying to run an A/B test using Firebase A/B testing, but just for specific versions of the app. There were no results and no users exposed to the experiment after 5 days of running it.
After that, I tried to run the same A/B test but without a version restrictions and the first results were available the next day.
So I thought that the way I was defining version restrictions was wrong. I tested it in Remote Config, but the Remote Config was returning the correct values when I applied the same version restriction. Here is how I defined the version restriction in both cases:
The app's version names are in the following format X.Y.Z (e.g. 6.51.0, 6.51.1)
Is there something that I am missing? Is the test significantly slower to start if specific versions are being targeted?
This should work. I have tried this many times. Make sure that you're targeting the correct value based on your app configuration. The Version targeting criterion...
For Android app, you should target the "versionName", not the "versionCode".
For iOS app, you should target the "CFBundleShortVersionString", not the "CFBundleVersion".
In addition, you should put the exact number on the console. For example, if the versionName or CFBundleShortVersionString is 1.0.0, then you should put 1.0.0 and not just 1.0.
Related
running gradle build on an android project or module yields the following lint report entry:
Potentially insecure random numbers on Android 4.3 and older. Read https://android-developers.blogspot.com/2013/08/some-securerandom-thoughts.html for more info.
This provides an easy to implement patch for said issue. But I'm wondering if it needs to be applied, given that it's 5 years old, or can this be ignored?
Thanks
That depends on whether your app must support Android versions 4.3 and earlier, as well as why you are using SecureRandom in your app (e.g., for information security or secure communications), and the security risk of not using the fix suggested at that page to patch uses of SecureRandom in your app in older versions. Note, however, that according to the Distribution Dashboard, only about 3.5% of Android devices that recently visited the Google Play store ran version 4.3 and earlier. This percentage will likely be less for your app if the minSdkVersion is higher than 10, and this percentage will likely dwindle as time goes by.
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
In recent update Xamarin made it possible to publish android apps straight to the Google play (before you had to generate apk and upload it manually). More info
These are my version numbers. I was at version 10437 when the update came, I made some changes and raised version number to 10438 and tried the new way of publishing. What happened is that my version number became 141510 for some reason and when I tried to do it again it became 207046. After that I set the number to 320000 and started uploading manully again.
I suspect that the reason for this is that I had Multiple supported architectures and xamarin was uploading multiple apks and I was getting some errors about that. Since then I changed supported architectures to armeabi-v7a only.
Question is:
Can I somehow tell google to forget about these screwed up numbers so I can continue with my 10438 (it won't let me now, I get an error that version number must be bigger then the last one)? Also all versions after 10437 are private and this is the current version on beta (image is from beta channel).
Also do I lose mobile devices if I set my supported architecture as armeabi-v7a only?
versionCode vs. versionName:
The versionCode is not shown to the user:
An integer used as an internal version number. This number is used only to determine whether one version is more recent than another, with higher numbers indicating more recent versions. This is not the version number shown to users
Ref: https://developer.android.com/studio/publish/versioning.html
ABI Architecture:
Google does not breakdown the CPU Information/ABI Architectures in a Dashboard like they do for API level or screen resolution. You can get a device breakdown for your app install:
Ref: https://developer.android.com/distribute/googleplay/developer-console.html#app-stats
Assuming your app is not dependent on a 3rd-party NDK library that only supports a subset of all the ABIs, there is no general reason not to support multi-ABIs as you are just pre-limiting your applications available user-based.
Current API and Screen Sizes and Densities Distributions:
Ref: https://developer.android.com/about/dashboards/index.html
I have built an android tablet application which is installed only from my web site - manual install.
I will need to be able to provide updates to existing users through the same site - without obliging users to uninstall the existing application.
What do I need to change in my (eclipse) project to permit this ?
Simon -
Apps are designed to be upgraded in place on Android. All you need to do is ensure that the version number of the app being installed is greater than the previous version.
You can still provide debug releases, simply increment a portion of the version to reflect that change and your users can keep getting updates. Otherwise, you may want to have an explicitly Debug and Release version that can be installed side by side and not conflict with each other, but that may be more trouble and confusing than its worth.
I have uploaded two APK files into the Google Play store. One is a newer version and one is an older version. The newer version is the active one since it has a higher versionName and Code. Now I found some bugs in the newer version and I want to delete it from the Play Store and activate the older version. Google Play won't let me deactivate the newer one and activate the older one again, since it has a lower versionName and code.
The problem is that I'm am not the developer and did not build the app. The developer is in another country and it is difficult to get hold of them.
What can I do to reactivate the older version again? I know one solution would be to change the versionName and Code. I only have the apk file, can I change those details in Eclipse with only the apk file and very little experience in eclipse or developing android apps?
Thank You
You can't rebuild a new version of an apk from the apk itself.
Have the app developer do the following:
Rebuild project in its previous state with higher version number (must be higher than all previously submitted versions)
Resubmit
From Google's Android "Developer Console" page:
Note that rollbacks aren’t supported due to the app versioning
requirements of the Android platform. If you need to rollback,
consider launching a previous APK with a new version number. However,
this practice should be used only as a last resort, as users will lose
access to new features and your old app may not be forward-compatible
with your server changes or data formats, so be sure to run alpha and
beta tests of your updates.
A good strategy is, when creating a build, modify the manifest to build say a version 2.0 = 39 AND again 2.05 = 45 and generate these two apks which will obviously do the same thing.
Later, when build 2.01 = 40 is in production and you find an error, you can jump back to the old version by uploading the 2.05 = 45 you created earlier.
You have 5 opportunities to back track while releasing 40, 41, 42, 43 and 44 to go back to earlier functionality!
Do this for each build and you can always go back to an earlier version which has been pre compiled and built but with a higher version number than currently in production.
You will not be able to change the APK file without having the signing certificate.
You should be able to revert to an older version, assuming you didn't change the level of API support.
Presumably, go to the Dev console, select the APK tab, hit the "Advanced Mode" option, deactivate the current version and hit "Reactivate" for the version you want.