I have just automated the process of new targets/flavors creation for my Android and iOS projects. For Android I use a bash script to add new flavor to Android app and then build and sign the app. For iOS I use a script which builds a target and "dynamically" sets all of the necessary parameters and then archives the app end exports to the .ipa file.
I know how to add a new build to the app "project" which already exists on Fabric, but I haven't found any way to upload completely new flavor/target for the first time from command line/script. Is there any way/hack to achieve this?
Mike from Fabric here.
There isn't a hack or workaround for this currently. We need both a build and run from the app in order to activate the app within the Fabric dashboard.
Related
I have this weird error, I've been using appcenter for a long time, but never experienced this.
I setup a build with appcenter which fetches from azure devops repo. The application is a Xamarin.Android native application. Once I run the build, everything goes well. Untill the signin step. When the step is about to start, I get this error:
##[error]No matching files were found with search pattern: /Users/runner/work/1/s/**/*.apk
Looks like the APK was not found, though the build runs successfully without error.
Please I need your help to figure out a solution to this issue.
In your csproj file for the Android Application project. Check whether <AndroidPackageFormat>apk</AndroidPackageFormat> is set to apk or aab. If it is aab then you need to change the search pattern to search for /**/*.aab instead. Otherwise, it will be looking for stuff that wasn't produced during the build.
To change the search path of appcenter, go to your build configurations and toggle the switch with label: “Build android app bundle”.
the change <AndroidPackageFormat>aab</AndroidPackageFormat> for <AndroidPackageFormat>apk</AndroidPackageFormat> works for me
If you are developing Android Apps and publishing them through Play Store, starting August 2021, new apps are required to target API level 30 (Android 11) and use the Android App Bundle publishing format. (aab)
If you want to know more about the Android App Bundle publishing format, here you have more information. As Cheesebaron is mentioning, if you are using AppCenter for building and packaging your Apps, just use the flag "Build App Bundle" in the Build configuration
I'm trying to figure out the CI portion that provided by AppCenter. I've implemented CodePush for my app and please correct me if my understanding is wrong.
We build the native android app and generate a signed apk.
Release the generated signed apk to playstore
execute command to upload bundle appcenter codepush release-react -a <owner>/<android-app> -d Production
The above are generally the way I understand CodePush and I've tested and working fine.
Now I've noticed that we can integrate our github project branch to appcenter, and whenever there is a git push, AppCenter will build it automatically and we can configure to release to playstore automatically.
Now the part I don't understand is, is this CI auto build by AppCenter actually nothing to do with CodePush?
If now my situation is only having updates on JS code side, actually when I git-push to repo, there isn't a need to auto-release to playstore right?
Correct, Build and Push are separate services in App Center. Build does the binary build of your app while CodePush simply updates the JavaScript and related code in an Apache Cordova or React Native. They're separate workflows and it seems you want to trigger them separate ways.
If you're using CodePush, you can't also use Build to auto build and deploy the native app to devices, you're duplicating work. I'm not an expert, but you probably want to manually deploy your builds whenever you make changes to the native side of the app (which should be rarely, right?) - like when there's major updates to the native framework or new plugins added to the native app
I am new to react-native app development. I wanted to know how can a developed app be shared between other developers without having a local dependency. Is an apple developer account needed for a test build to be shared in ios as well? How can the test build be created?. I wanted the build to be created and downloaded on any ios device or android for testing purpose and without having depending any of the local code changes.So the build downloaded should not get updated after any code change done after that.
Is there an easy way to do it?
To share a release build for Android please follow this guide Generating Signed APK.
But for iOS you gonna need a Apple Developer account, I don't know the whole process exactly.
I have a android build server which uses APKTool to decompile and then assemble apps again. So the same code base is used and some settings and name, package page, icon and other things are changed for each app and are assembled again. This is something that is already implemented.
I wanted to integrate crashlytics into this. But the problem is crashlytics is available as a gradle plugin and they submit to their API when you build it from source. I decompiled the class files and figured out the API call and called it manually. This works fine. But just wanted to see if we can install gradle and whatever tools required on the build server and directly execute the plugin task alone?
For iOS they have provided a tool so that solves it elegantly:
http://support.crashlytics.com/knowledgebase/articles/370383-beta-distribution-with-ios-build-servers
I've got a handful of side-project apps on the go at home, I've setup a Jenkins installation to check them out and build APKs, which I then transfer over to my handset and play around with.
I'm looking to release some of these freely on the market, so I need to sign them with a certificate and prepare the final APK.
Is it possible to do this from Jenkins? For example, could I have one build target that generates my "in development" APKs, and also have that target (or another) create the final APK files ready to go?
Any advice?
If the signing is possible to do automatically (by command line or similar), then the answer is "Yes".
There are several ways to achieve this, but firstly: Is there any good reason not to sign every build?
Signing every build would mean that you don't need any extra configuration to create a releasable artifact, and you know that what you test and what you deploy are the same things.
If you want to be selective about what builds you sign, two approaches come to mind:
Parameterized builds: These are environment variables that can be customized when you click Build now. You can add a flag that you later react on in a build step.
Add another job that picks up the artifacts from your main build job and signs them, using https://jenkins-server/job/jobname/lastSuccessfulBuild/artifact/ or one of the approaches here: How to access Hudson job1 artifacts from another job2?
In the standard Android ant build file is a release target contained. This will if started without further configuration just build an unsigned apk. As Christopher pointed out to do a signed build you can use key.store, key.store.password and key.alias,key.alias.password to configure your keystore and generate signed apks through the ant script. The documentation on this may fprovide further information on configuring the build.
Yes... the easiest way imho is to automate it with Maven Android Plugin. The samples project has the MorseFlash example I wrote in there that has the whole release process automated including jarsigning, zipaligning and proguard runs, switching between development and production config and more.
This can all be done on the command line and therefore on Hudson. Btw if you are interested I did presentations about Maven and Android as well as testing and CI for Android at AnDevCon and the slides are on my web site. http://www.simpligility.com