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
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 following this https://cloud.google.com/community/tutorials/building-android-apk-with-cloud-build-gradle-docker-image to build Android APKs via Cloud build
Already have image (with digest): gcr.io/cloud-builders/docker
Unable to find image 'gcr.io/fullstackgcp/gradle:latest' locally
/usr/bin/docker: Error response from daemon: pull access denied for gcr.io/fullstackgcp/gradle, repository does not exist or may require 'docker login'.
See '/usr/bin/docker run --help'.
Did anyone experience this as well?
This account had been suspended for billing issues (likely because people were all referring to that image, instead of hosting it themselves); I've already reported that. Meanwhile I've created another one fully working example (without making the same mistake to share the builder image): cloudbuild-android, which is just as good, if not a tad better.
Full disclosure: I've wrote that builder, because of the problem with the image.
I also had this error. Digging deeper I figured that you first need to prepare a Docker image that will build your Android app and upload that image to Google Cloud Registry. To do that I used: Cloud Builders Community:
Checkout their repository
Go to cloud-builders-community/android/
Trigger CloudBuild to build & upload a docker for you (specify the Android SDK version you need):
gcloud builds submit --config=cloudbuild.yaml --substitutions=_ANDROID_VERSION=28
At this point you should be able to use gcr.io/$PROJECT_ID/android:28 instead of gcr.io/fullstackgcp/gradle in the cloudbuild definition provided in the tutorial.
However I decided not to risk and hit the next error, so I used this one (provided by Cloud Builders Community again). They do have a step for caching the gradle build so you would also need a tar docker:
Go to cloud-builders-community/tar/ and run:
gcloud builds submit --config=cloudbuild.yaml
After all of this is done you can build your app by running the following in the app folder:
gcloud builds submit --config=cloudbuild.yaml --substitutions=_ARTIFACT_BUCKET=<your_bucket>,_CACHE_BUCKET=<your_bucket>
The trigger you have already created as part of the tutorial will also work. You just need to add the two variables above: _ARTIFACT_BUCKET and _CACHE_BUCKET
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.
I'm working on a project and using the Google GSM Vision library to read a QR Code by adding
compile 'com.google.android.gms:play-services-vision:8.4.0'
in my app gradle.
After doing it, the project syncs and now I'm able to use the lib and I can launch the app in my own device.
The problem is. What happens if the target does not have access to internet and it does not have a Google account? Will it run or the lib needs to be downloaded after or during the installation?
Thank you.
Creation of APK, mobile vision api bundled with APK. So, internet is not required and google account is not necessary.
From Doc :
Note: ProGuard directives are included in the Play services client
libraries to preserve the required classes. The Android Plugin for
Gradle automatically appends ProGuard configuration files in an AAR
(Android ARchive) package and appends that package to your ProGuard
configuration. During project creation, Android Studio automatically
creates the ProGuard configuration files and build.gradle properties
for ProGuard use. To use ProGuard with Android Studio, you must enable
the ProGuard setting in your build.gradle buildTypes. For more
information, see the ProGuard guide.
Generally, Gradle can try to connect to the web. If you have your dependency downloaded in cache you can build the app in --offline mode.
We are struggling to come up with a good idea of how to integrate our build environments, now that we start using swagger-..codegen to generate API classes from our backend api for the android app, iOS app and the webclient.
Current situation:
we use several (private) github repositories
node.js backend: grunt build with tests and CI using cloudbased CI service- running codeGen for web- and android clients api access classes on sucessful builds, continous deployment to heroku test environement,
web Frontend, grunt build with tests and CI using cloudbased CI service and and continous deployment to herku test env.
android app, using gradle build and same CI, no continous deployment so far.
and soon there will be an iOS app as well...
This is private, non-OSS-code.
The requirement:
The different clients should be able to specify a dependency to the generated backend access libraries and get them during the build. The clients should be able to get the "latest" version or a specified fixed version, like with npm semantic dependencies. I could certainly enhance our build to upload the build artefacts to somewhere on successful CI builds, but the question is where to... what is the easiest way to set this up.
do we need one, (or even several) private artefact repositories (nexus, npm, bower, ...)
should we (ab)use github repositories to store the built artefacts in?
we could also publish the build artefacts to S3 or something similar...
any good ideas?
The only things you should really store are your separate "tasks" folders if you are doing some custom tasks, your grunt.js (.coffee), resources (that you may use for pre-build tasks -less,coffee/views, coffee/models all your custom stuff), and your package.json. That way any new developer just grabs those form source, and then runs npm install to pull all your dependencies from your package.json.
/resources
grunt.coffee
package.json
I then have some tasks that pull and run bower tasks (pull latest jqm, set that up, pull various libraries.)
As far as node_modules I wouldn't store those anywhere. This is a simple script / app I wrote that works almost end to end with compiling a JQM app, calling phonegap scripts, building the app and ultimately ending up with an xcode app package.
Maybe this will give you some ideas. So far I have found it best to do the above.
https://github.com/imaginethepoet/autojqm