4

I have an android app and I am trying to set up the CICD in Azure Devops for our team. However I cannot get the "Build" stage to complete. It fails in the "Android Signing" sub-task with error message:

[error]Error: The process '/Users/vsts/Library/Android/sdk/build-tools/19.1.0/zipalign' failed with exit code 1

It works when I deselect the optional "zipalign" feature on the signing task. But as I've read you are not supposed to deploy applications without using zipalign first.

The app is built in Android Studio (Kotlin). All similar issues I have found online have been related to xamarin, which I am not using at this point.

I am deploying on a arm64 device if that is relevant. Building and signing in Android Studio is no problem (Although I am not sure if it uses the zipalign by default there as it is not clear from using the Generate Signed APK wizard. I would assume it will do it for you without asking?). Anyways I'm of course trying to automate the build-deploy in DevOps on pull-requests to the master branch, which is how I usually do it with other projects.

Here is my azure-pipelines.yaml

# Android
# Build your Android project with Gradle.
# Add steps that test, sign, and distribute the APK, save build artifacts, and more:
# https://learn.microsoft.com/azure/devops/pipelines/languages/android

trigger:
- master

pool:
  vmImage: 'macos-latest'

steps:
- task: Gradle@2
  inputs:
    workingDirectory: ''
    gradleWrapperFile: 'gradlew'
    gradleOptions: '-Xmx3072m'
    publishJUnitResults: false
    testResultsFiles: '**/TEST-*.xml'
    tasks: 'assembleDebug'

- task: AndroidSigning@3
  inputs:
    apkFiles: '**/*.apk'
    apksignerKeystoreFile: 'key.jks'
    apksignerKeystorePassword: 'XXXX'
    apksignerKeystoreAlias: 'key0'
    apksignerKeyPassword: 'XXXX'

- task: CopyFiles@2
  inputs:
    contents: '**/*.apk'
    targetFolder: '$(build.artifactStagingDirectory)'
- task: PublishBuildArtifacts@1
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
    ArtifactName: 'drop'
    publishLocation: 'Container'

The tail-end of the log below. I am getting a bunch of (BAD - 1-2-3) messages for various resources. Not sure if this is related to the error itself.

enter image description here

Community
  • 1
  • 1
RoleyBaxter
  • 223
  • 3
  • 14
  • Could you better show us the completed debug log? This exit code is very general. Maybe could find something abnormal from it. (Please set System.debug=true) – Mengdi Liang Oct 18 '19 at 02:16
  • @MerlinLiang-MSFT sorry about the late reply. Thanks for the response. I've added the tail-end of the log to the post above. Does this help ? – RoleyBaxter Feb 19 '20 at 15:44
  • 2
    @RoleyBaxter did you get this working? I also have this issue. – Wouter van Vegchel May 05 '20 at 08:30
  • 1
    @WoutervanVegchel sadly no. We don't do releases that often and the app is only for internal use. I have been building the releases manually in Android Studio so far. I believe it is possibly to do with the compression status returning as "BAD" on some files, but I don't know how to fix this. Please let me know if you have better luck :) – RoleyBaxter May 07 '20 at 12:49
  • 1
    Changing assembleDebug to assembleRelease worked for me. See this answer https://stackoverflow.com/a/54357104 – Graeme English May 08 '20 at 11:43

2 Answers2

2

Please check the discussion here. https://github.com/microsoft/azure-pipelines-tasks/issues/13863. It seems that in the latest Gradle release the apk is built using a new library (zipflinger) which automatically alignes the apk, and zipalign fails when trying to align the apk that is already aligned (zipalign verification returns success on the initial apk)... This sounds really strange, but apparently zipalign is not needed anymore.

So the solution is to disable zipalign in your zure-piplelines.yml

 - task: AndroidSigning@3
  inputs:
    apkFiles: '**/*.apk'
    ...
    zipalign: false
flame3
  • 2,812
  • 1
  • 24
  • 32
0

I had exactly the same problem and it turned out that I had my release build still set to being debugabble. Setting "debuggable false" in my gradle file solved it.

Luigi_Papardelle
  • 161
  • 4
  • 16