Jak utworzyć plik apk podpisany w wersji za pomocą Gradle?

514

Chciałbym mieć moją wersję Gradle, aby utworzyć plik apk podpisany wersją przy użyciu Gradle.

Nie jestem pewien, czy kod jest poprawny lub czy brakuje mi parametru podczas wykonywania gradle build?

Oto część kodu w moim pliku gradle:

android {
    ...
    signingConfigs {
          release {
              storeFile file("release.keystore")
              storePassword "******"
              keyAlias "******"
              keyPassword "******"
         }
     }
}

Kompilacja stopni kończy się sukcesem, aw moim build/apkfolderze widzę tylko pliki ...-release-unsigned.apki ...-debug-unaligned.apk.

Wszelkie sugestie, jak to rozwiązać?

Jan-Terje Sørensen
źródło
podpisać w wersji v1 (sygnatura jar) lub v2 (pełna sygnatura apk) z pliku stopni? rozwiązanie tutaj: stackoverflow.com/questions/57943259/…
user1506104

Odpowiedzi:

429

Łatwiejszy sposób niż poprzednie odpowiedzi:

Włóż to w ~/.gradle/gradle.properties

RELEASE_STORE_FILE={path to your keystore}
RELEASE_STORE_PASSWORD=*****
RELEASE_KEY_ALIAS=*****
RELEASE_KEY_PASSWORD=*****

Zmodyfikuj swój app/build.gradlei dodaj to do android {bloku kodu:

...    
signingConfigs {

   release {
       storeFile file(RELEASE_STORE_FILE)
       storePassword RELEASE_STORE_PASSWORD
       keyAlias RELEASE_KEY_ALIAS
       keyPassword RELEASE_KEY_PASSWORD

       // Optional, specify signing versions used
       v1SigningEnabled true
       v2SigningEnabled true
   }
}

buildTypes {
        release {
            signingConfig signingConfigs.release
        }
}
....

Potem możesz biec gradle assembleRelease


Zobacz także odniesienie do signingConfigsGradle DSL

David Vávra
źródło
12
Najlepsza metoda, jeśli mnie o to poprosisz. Nic nie zapisuje w folderze mojego projektu / SVN i mogę sprawdzić 10 wersji moich projektów bez martwienia się o klucze.
Frank
8
Jeśli używasz gradlew w Windows, musisz upewnić się, że GRADLE_USER_HOME jest zdefiniowany jako zmienna środowiskowa, aby to działało. Ustawiłem go na jeden katalog powyżej katalogu projektu i tam umieściłem mój magazyn kluczy. Ścieżka do pliku kluczy w gradle.properties powinna zawierać ukośniki do przodu (/) lub podwójne ukośniki odwrotne (\\), a nie pojedyncze ukośniki odwrotne systemu Windows. Aby utworzyć magazyn kluczy z wiersza polecenia systemu Windows, zobacz stackoverflow.com/questions/3997748/how-can-i-create-a-keystore
Anachronist
3
Czy ścieżka odnosi się do miejsca, w którym znajduje się plik build.gradle, czy do katalogu głównego maszyn?
Prem
1
@Prem, file()zawsze zakłada ścieżki względne. Użyj, new File(path)jeśli chcesz traktować go jako absolutny.
ars-longa-vita-brevis
4
To zadziałało dla mnie i najprostsze. W gradle.properties określ storeFile względem modułu build.gradle, tak jak RELEASE_STORE_FILE = .. / mykeystore. Nie dodawaj cudzysłowów, gradle szlifuje ścieżkę
Lakshman Chilukuri,
263

Udało mi się go rozwiązać, dodając ten kod i budując z gradle build:

android {
    ...
    signingConfigs {
        release {
            storeFile file("release.keystore")
            storePassword "******"
            keyAlias "******"
            keyPassword "******"
        }
    }
    buildTypes {
        release {
            signingConfig signingConfigs.release
        }
    }
}

To generuje podpisany plik apk wydania.

Jan-Terje Sørensen
źródło
33
Czy istnieje sposób, aby monitował mnie o hasło? Lub inne sugestie, aby ukryć hasła w moich repozytoriach git?
user672009,
3
Edytuję mój build.gradle, aby wyglądał jak twój, ale uruchamianie „Zbudowany> Generuj podpisany APK ...” nadal wyświetla moje okno dialogowe („Aby uzyskać więcej informacji, patrz„ Instrukcja użytkownika Gradle ”. Itd.)) I nie ma APK.
Semanticer
3
@Semanticer Wykonaj gradle buildlub gradlew buildza pomocą polecenia Terminal / Prompt
Phillip Kamikaze,
12
@ user672009 możesz umieścić hasła w pliku właściwości i wykluczyć je z repozytoriów za pomocą .gitignore. Możesz zobaczyć ten link. gist.github.com/gabrielemariotti/6856974
Gabriele Mariotti
1
@GrrieleMariotti To wciąż pozostawia niekompletne repozytorium. Lepszym sposobem byłoby utworzenie szkieletu signing.properties i po wydaniu „git update-index --assume-unchanged signing.properties”. Jednak to uniemożliwia dokonanie edycji futura. Coś jak pierwsza opcja sugerowana przez sdqali wydaje się jeszcze lepsza.
user672009,
67

Pamiętaj, że skrypt @ sdqali będzie (przynajmniej podczas korzystania z Gradle 1.6) pytać o hasło za każdym razem, gdy wywołasz dowolne zadanie gradle. Ponieważ potrzebujesz go tylko podczas wykonywania gradle assembleRelease(lub podobnego), możesz użyć następującej sztuczki:

android {
    ...
    signingConfigs {
        release {
            // We can leave these in environment variables
            storeFile file(System.getenv("KEYSTORE"))
            keyAlias System.getenv("KEY_ALIAS")

            // These two lines make gradle believe that the signingConfigs
            // section is complete. Without them, tasks like installRelease
            // will not be available!
            storePassword "notYourRealPassword"
            keyPassword "notYourRealPassword"
        }
    }
    ...
}

task askForPasswords << {
    // Must create String because System.readPassword() returns char[]
    // (and assigning that below fails silently)
    def storePw = new String(System.console().readPassword("Keystore password: "))
    def keyPw  = new String(System.console().readPassword("Key password: "))

    android.signingConfigs.release.storePassword = storePw
    android.signingConfigs.release.keyPassword = keyPw
}

tasks.whenTaskAdded { theTask -> 
    if (theTask.name.equals("packageRelease")) {
        theTask.dependsOn "askForPasswords"
    }
}

Pamiętaj, że musiałem również dodać następujące elementy (w systemie Android), aby to działało:

buildTypes {
    release {
        signingConfig signingConfigs.release
    }
}
jclehner
źródło
Po wdrożeniu tego installReleasezniknął z listy zadań ... Dlaczego?
Kaarel
1
@caspase Chciałbym poważniej potraktować twój komentarz na temat tego fałszywego „storePassword” i „keyPassword”. Bez zainicjowania tych właściwości (na przykład „”) podpisany * -release.apk nie zostanie utworzony, żaden błąd nie zostanie wyświetlony, a użytkownik będzie całkowicie zdziwiony tylko * -release-unsigned.apk w katalogu PROJECT_NAME / build / apk / . Człowiek ...: /
vizZ
Dziękujemy za uwagę dotyczącą dodania signingConfig w buildTypes -> Release. To rozwiązało dla mnie automatyczne podpisywanie!
mm2001
1
Zrobiłem prostą wtyczkę gradle, która pyta o hasła podczas budowania wersji apk (używając matematyki opisanej w tym poście, ale nie będziesz musiał definiować fałszywego hasła do sklepu i hasła). Jest również dostępny w maven central. github.com/alexvasilkov/AndroidGradleSignPlugin
Alex Vasilkov
To jest świetne. Uważaj, że zmienna środowiskowa KEYSTOREmusi zostać zdefiniowana nawet w przypadku kompilacji debugowania i „synchronizacji stopniowej” w Android Studio, w przeciwnym razie pojawi się błąd dotyczący braku wartości ścieżki.
Jerry101
63

Jeśli chcesz uniknąć zapisywania na stałe swojego pliku kluczy i hasła w build.gradle , możesz użyć pliku właściwości, jak wyjaśniono tutaj: POSTĘPOWANIE Z SYGNALIZOWANIEM KONFIGURACJI Z GRADLE

Gruntownie:

1) utwórz plik myproject.properties pod adresem /home/[nazwa_użytkownika]/.signing z taką zawartością:

keystore=[path to]\release.keystore
keystore.password=*********
keyAlias=***********
keyPassword=********

2) utwórz plik gradle.properties (być może w katalogu głównym katalogu projektu) z zawartością:

MyProject.properties=/home/[username]/.signing/myproject.properties

3) zapoznaj się z tym w swoim build.gradle w ten sposób:

    if(project.hasProperty("MyProject.properties")
        && new File(project.property("MyProject.properties")).exists()) {

    Properties props = new Properties()
    props.load(new FileInputStream(file(project.property("MyProject.properties"))))

    signingConfigs {
        release {
            storeFile file(props['keystore'])
            storePassword props['keystore.password']
            keyAlias props['keyAlias']
            keyPassword props['keyPassword']
        }
    }
}
Igor Ganapolski
źródło
1
Działa świetnie! Dziękuję Ci. Ten kod musi zostać dodany przed sekcją buildTypes {}, a sekcja musi zadeklarować signingConfig signingConfigs.release jak zwykle.
thesenssensation
W końcu znalazłem rozwiązanie tego problemu. Jedyna rzecz, która naprawdę mi pomogła! To powinna być zaakceptowana odpowiedź ...
devnull69
39

Automatyczne podpisywanie aplikacji za pomocą Gradle podczas korzystania z git

To zadziwiające, jak wiele zawiłych sposobów można tego dokonać. Oto mój własny sposób, w którym staram się przestrzegać własnej rekomendacji Googles . Jednak ich wyjaśnienie nie jest w pełni jasne, więc opiszę szczegółowo procedurę dla Linuksa.


Opis:

Domyślne instrukcje Google do automatycznego podpisywania aplikacji podczas kompilacji, bez utrzymywania haseł i plików podpisów na ścieżce rozwoju aplikacji (GIT), są raczej niejasne. Oto wyjaśnione instrukcje krok po kroku, jak to zrobić.

Wstępne założenia:

Masz aplikację o nazwie „MojaAplikacja” w katalogu określonym przez następującą ścieżkę: $HOME/projects/mydev/MyApp. Jednak katalog MyApp jest używany i kontrolowany za pomocą GIT.

wprowadź opis zdjęcia tutaj

Problem

Oczywiście nie chcemy, aby nasze pliki sygnatur i haseł były nigdzie w katalogu kontrolowanym przez GIT, nawet jeśli jesteśmy w stanie bardzo dobrze korzystać .gitignoreitp., Nadal jest zbyt ryzykowne i łatwe do popełnienia błędu. Dlatego chcemy, aby nasz plik kluczy i pliki sygnatur były na zewnątrz.

Rozwiązanie

Musimy zrobić trzy (3) rzeczy:

  1. Utwórz plik hasła, który będzie używany przez Android Studio
  2. Utwórz plik klucza podpisu
  3. Edytuj build.gradleplik modułu , aby użyć (1) i (2).

W tym przykładzie nazywamy dwa pliki:

  1. keystore.properties
  2. MyApp-release-key.jks

Oba te pliki możemy umieścić tutaj:

cd $HOME/projects/mydev/

(1) Utwórz plik hasła do magazynu kluczy

Pierwszy plik zawiera hasła tekstowe użyte w; i ścieżki do pliku klucza wydania w (2). Zacznij od wypełnienia tego, ponieważ ułatwi to kopiowanie wklejanie na następny krok.

cd $HOME/projects/mydev/

Edytuj keystore.properties, aby jego zawartość była:

storePassword=myStorePassword
keyPassword=mykeyPassword
keyAlias=myKeyAlias
storeFile=myStoreFileLocation

Jedyną trudną częścią jest tutaj myStoreFileLocation. Jest to ścieżka widziana zbuild.gradle pliku modułu podczas kompilacji. Oznacza to zazwyczaj ścieżkę podobnie jak iw stosunku do: $HOME/projects/mydev/MyApp/app/build.gradle. Aby wskazać MyApp-release-key.jks plik, musimy tutaj umieścić:

../../../MyApp-release-key.jks

Tutaj wybraliśmy również alias „myapp” dla klucza. Następnie końcowy plik powinien wyglądać:

storePassword=myStorePassword
keyPassword=mykeyPassword
keyAlias=myapp
storeFile=../../../MyApp-release-key.jks

(2) Utwórz plik podpisu

Drugi plik jest generowany automatycznie podczas tworzenia klucza podpisu. Jeśli nie masz innych aplikacji i jest to jedyny magazyn kluczy, utwórz plik za pomocą:

cd $HOME/projects/mydev/
keytool -genkeypair -v -keystore MyApp-release-key.jks -keyalg RSA -keysize 2048 -validity 10000 -alias myapp

Zostaniesz poproszony o podanie dwóch haseł i wielu informacji. (Takie same rzeczy jak w Android Studio.) Teraz skopiuj / wklej wcześniej wybrane hasła.

(3) Edytuj gradle.buildplik modułu , aby użyć powyższego

W pliku kompilacji Gradle aplikacji / modułu muszą znajdować się następujące części. Po pierwsze, należy dodać następujące linie na zewnątrz i przed swoim android {}blokiem.

//def keystorePropertiesFile = rootProject.file("$HOME/.android/keystore.properties")
def keystorePropertiesFile = rootProject.file("../../keystore.properties")
def keystoreProperties = new Properties()
keystoreProperties.load(new FileInputStream(keystorePropertiesFile))

Następnie wewnątrz w android {}bloku, należy dodać:

android {
    ...
    defaultConfig { ... }
    signingConfigs {
            release {
                keyAlias keystoreProperties['keyAlias']
                keyPassword keystoreProperties['keyPassword']
                storeFile file(keystoreProperties['storeFile'])
                storePassword keystoreProperties['storePassword']
            }
        }
    // Tell Gradle to sign your APK
    buildTypes {
        release {
            signingConfig signingConfigs.release
            ...
        }
    }
}

Teraz z powłoki możesz ponownie zbudować aplikację za pomocą:

cd $HOME/projects/mydev/MyApp/app/
./gradlew clean build

Powinno to wygenerować poprawnie podpisaną aplikację, z której można korzystać w Google Play.


AKTUALIZACJA: 02.04.2019

Nowsze wersje keytooli coś mówi ci, że powinieneś używać pliku kluczy opartego na PKCS12 zamiast oryginalnego / domyślnego, jak używam powyżej. Są one następnie przejść z informacją, należy przekonwertować do nowego formatu otwarty PKCS12. Wydaje się jednak, że narzędzia programistyczne dla Androida nie są jeszcze na to jeszcze gotowe, ponieważ jeśli to zrobisz, otrzymasz następujące dziwne błędy:

com.android.ide.common.signing.KeytoolException:Nie udało się odczytać klucza XXX ze sklepu „F: \ XXX \ XXX.jks”: Pobierz klucz nie powiódł się: Podany blok końcowy nie został poprawnie wypełniony. Takie problemy mogą wystąpić, jeśli podczas odszyfrowywania zostanie użyty zły klucz.

Więc nie używaj przekonwertowanego klucza!

not2qubit
źródło
Czy podpisywanie Konfiguracje są zapisywane w apku, a następnie może zostać zdekompilowane przez dowolnego użytkownika w celu uzyskania haseł, czy też nie pojawia się w apku?
JavierSegoviaCordoba
2
Działa jak urok. Dziękuję, to powinna być zaakceptowana odpowiedź
pratham kesarkar
Co zrobić, jeśli chcesz tylko magazyn kluczy i hasła na serwerze kompilacji? Dzięki temu rozwiązaniu każdy programista w zespole musi mieć magazyn kluczy na swoim komputerze lokalnym. W przeciwnym razie synchronizacja projektu Gradle nie powiedzie się: keystore.properties (Brak takiego pliku lub katalogu).
Diana Farin
1
Możesz zatwierdzić keystore.propertiesplik fikcyjny do kontroli źródła, więc buduje pracę na komputerach deweloperskich. Opisałem tutaj konfigurację serwera kompilacji .
dskrvk
1
Uwaga na ostatniej aktualizacji na temat keytoolgenerowania kluczy PKCS12: można przekazać -storetype JKSw keytoolkomendzie, aby ustawić typ kluczy do JKS, który jest wymagany przez Android oprzyrządowania.
Trevor Halvorson
35

Jak powiedział @Destil, ale pozwól innym, którzy nie mają klucza do zbudowania: Łatwiejszy sposób niż poprzednie odpowiedzi:

Włóż to w ~/.gradle/gradle.properties

RELEASE_STORE_FILE={path to your keystore}
RELEASE_STORE_PASSWORD=*****
RELEASE_KEY_ALIAS=*****
RELEASE_KEY_PASSWORD=*****

Zmodyfikuj swój w build.gradleten sposób:

...    
if(project.hasProperty("RELEASE_STORE_FILE")) {
    signingConfigs {    
       release {
           storeFile file(RELEASE_STORE_FILE)
           storePassword RELEASE_STORE_PASSWORD
           keyAlias RELEASE_KEY_ALIAS
           keyPassword RELEASE_KEY_PASSWORD
       }
    }
}

buildTypes {
    if(project.hasProperty("RELEASE_STORE_FILE")) {
        release {
            signingConfig signingConfigs.release
        }
    }
}
....

Następnie możesz uruchomić gradle assembleRelease OR gradle build

Gal Bracha
źródło
Jak ustawić ścieżkę w
systemie
plik storeFile („C: \\ Users \\ xxxx \\ Documents \\ yyyy \\ mykey.jks”), czy to prawda?
reza_khalafi
28

(W odpowiedzi na użytkownika 672009 powyżej.)

Jeszcze łatwiejsze rozwiązanie, jeśli chcesz trzymać swoje hasła poza repozytorium git; jednak chcę dołączyć do niego swój build.gradle, który nawet świetnie działa ze smakami produktów, to utworzyć osobny plik stopni. Nazwijmy to „signing.gradle” (dołącz to do swojego .gitignore). Tak jakby to był twój plik build.gradle bez wszystkiego, co nie jest związane z zalogowaniem się w nim.

android {
    signingConfigs { 
        flavor1 {
            storeFile file("..")
            storePassword ".."
            keyAlias ".."
            keyPassword ".."
        }
        flavor2 {
            storeFile file("..")
            storePassword ".."
            keyAlias ".."
            keyPassword ".."
        }
    }
}

Następnie w pliku build.gradle umieść ten wiersz pod „Zastosuj wtyczkę:„ Android ”

 apply from: 'signing.gradle'

Jeśli nie masz lub nie używasz wielu smaków, zmień nazwę „flav1” na „release” powyżej i powinieneś już skończyć. Jeśli używasz smaków, kontynuuj.

Na koniec połącz swoje smaki z poprawnym podpisaniem. Skonfiguruj w pliku build.gradle i powinieneś skończyć.

  ...

  productFlavors {

      flavor1 {
          ...
          signingConfig signingConfigs.flavor1
      }

      flavor2 {
          ...
          signingConfig signingConfigs.flavor2
      }
  }

  ...
jonbo
źródło
Czy możesz być trochę bardziej szczegółowy? Nie mogę go uruchomić: „nie można rozwiązać podpisywania symbolu Konfiguracja”.
Amio.io,
Jeśli do build.gradle dołączę „signing.gradle” - jestem zmuszony mieć taki w repozytorium git (w przeciwnym razie pojawia się błąd „signing.gradle nie istnieje”). A jeśli włożę do git „signing.gradle”, to pokona cel. Jak włączyć opcjonalne dołączanie signing.gradle?
Jaguar,
21

Jeśli masz już plik kluczy, może to być tak proste, jak dodanie kilku parametrów do polecenia kompilacji:

./gradlew assembleRelease \
 -Pandroid.injected.signing.store.file=$KEYFILE \
 -Pandroid.injected.signing.store.password=$STORE_PASSWORD \
 -Pandroid.injected.signing.key.alias=$KEY_ALIAS \
 -Pandroid.injected.signing.key.password=$KEY_PASSWORD

Żadne stałe zmiany w projekcie Androida nie są konieczne.

Źródło: http://www.tinmith.net/wayne/blog/2014/08/gradle-sign-command-line.htm

janpio
źródło
18

To jest odpowiedź dla użytkownika672009 i dodatku do postu sdqali (jego kod zawiesi się podczas budowania wersji debugowania przez przycisk „Uruchom” IDE):

Możesz użyć następującego kodu:

final Console console = System.console();
if (console != null) {

    // Building from console 
    signingConfigs {
        release {
            storeFile file(console.readLine("Enter keystore path: "))
            storePassword console.readLine("Enter keystore password: ")
            keyAlias console.readLine("Enter alias key: ")
            keyPassword console.readLine("Enter key password: ")
        }
    }

} else {

    // Building from IDE's "Run" button
    signingConfigs {
        release {

        }
    }

}
AChep
źródło
Czy istnieje sposób na uzyskanie wartości domyślnych? Mój magazyn kluczy jest zwykle taki sam. StorePassword zwykle jest taki sam jak keyPassword, a keyAlias ​​zwykle nazwa projektu pisana małymi literami.
user672009,
@ user672009 zawsze możesz użyć kodu Java wewnątrz skryptu.
AChep
1
możesz użyć czegoś takiego: keyPassword new String(console.readPassword("Enter key password: "))aby upewnić się, że hasło nie jest wyświetlane podczas wprowadzania danych
Alex Semeniuk
To już nie działa, patrz github.com/gradle/gradle/issues/1251
SqAR.org
16

W nowszym Androidzie Studio jest bardzo prosty interfejs GUI, który wypełnia również plik Gradle.

  1. File -> Project Structure

  2. Module -> Wybierz główny moduł („aplikacja” lub inna niestandardowa nazwa)

  3. Signing tab -> Obraz plus, aby dodać nową konfigurację

  4. Wypełnij dane po prawej stronie

  5. Plik OK i Gradle jest tworzony automatycznie

  6. Będziesz musiał ręcznie dodać linię do signingConfig signingConfigs.NameOfYourConfigśrodkabuiltTypes{release{}}

Obrazy:

wprowadź opis zdjęcia tutaj

wprowadź opis zdjęcia tutaj

Dwie ważne (!) Uwagi:

(EDYCJA 12/15)

  1. Aby utworzyć podpisany plik APK, musisz otworzyć kartę Terminal w Android Studio (na dole głównego interfejsu) i wydać polecenie ./gradlew assembleRelease

  2. Jeśli zapomniałeś keyAlias(co często mi się zdarza), będziesz musiał zainicjować, Build -> Generate Signed APKaby rozpocząć proces i zobaczyć nazwę klucza Alias.

sandalone
źródło
2
To jednak koduje twoje hasła do build.gradlepliku, prawda?
Joshua Pinter,
16

Jeśli budujesz apk za pomocą wiersza poleceń, takiego jak ja, możesz podać konfigurację podpisywania jako argumenty.

Dodaj to do swojego build.gradle

def getStore = { ->
    def result = project.hasProperty('storeFile') ? storeFile : "null"
    return result
}

def getStorePassword = { ->
    def result = project.hasProperty('storePassword') ? storePassword : ""
    return result
}

def getKeyAlias = { ->
    def result = project.hasProperty('keyAlias') ? keyAlias : ""
    return result
}

def getKeyPassword = { ->
    def result = project.hasProperty('keyPassword') ? keyPassword : ""
    return result
}

Zrób signingConfigsto tak

signingConfigs {
    release {
        storeFile file(getStore())
        storePassword getStorePassword()
        keyAlias getKeyAlias()
        keyPassword getKeyPassword()
    }
}

Następnie wykonujesz w gradlewten sposób

./gradlew assembleRelease -PstoreFile="keystore.jks" -PstorePassword="password" -PkeyAlias="alias" -PkeyPassword="password"
Egida
źródło
Co jest build.gradle? Najwyższy poziom? Dodaj więcej kodu
Vlad
Dla wyjaśnienia, to jest app/build.gradleplik, o którym mówię.
Egis
11
android {
    compileSdkVersion 17
    buildToolsVersion "19.0.3"

    defaultConfig {
        minSdkVersion 9
        targetSdkVersion 18
    }

    File signFile = rootProject.file('sign/keystore.properties')
    if (signFile.exists()) {
        Properties properties = new Properties()
        properties.load(new FileInputStream(signFile))
        signingConfigs {
            release {
                storeFile rootProject.file(properties['keystore'])
                storePassword properties['storePassword']
                keyAlias properties['keyAlias']
                keyPassword properties['keyPassword']
            }
        }
    }

    buildTypes {
        release {
            runProguard true
            zipAlign true
            proguardFile rootProject.file('proguard-rules.cfg')
            signingConfig signingConfigs.release
        }
        debug {
            runProguard false
            zipAlign true
        }
    }
}
JP Ventura
źródło
Korzystanie z Androida Studio 0.5.1, Gradle 1.11 i wtyczki Gradle 0.9.
JP Ventura
1
Tworzenie właściwości na żądanie (inaczej właściwości dynamiczne) jest przestarzałe i planowane jest jego usunięcie w Gradle 2.0
JP Ventura
10

Możesz także użyć opcji linii poleceń -P gradle, aby ułatwić podpisywanie. W swoim build.gradle dodaj singingConfigs w następujący sposób:

signingConfigs {
   release {
       storeFile file("path/to/your/keystore")
       storePassword RELEASE_STORE_PASSWORD
       keyAlias "your.key.alias"
       keyPassword RELEASE_KEY_PASSWORD
   }
}

Następnie wywołaj kompilację stopni w ten sposób:

gradle -PRELEASE_KEYSTORE_PASSWORD=******* -PRELEASE_KEY_PASSWORD=****** build

Możesz użyć -P, aby ustawić storeFile i keyAlias, jeśli wolisz.

Jest to w zasadzie rozwiązanie Destil, ale z opcjami wiersza poleceń.

Aby uzyskać więcej informacji na temat właściwości stopni, zapoznaj się z instrukcją obsługi stopni .

Andy Shiue
źródło
7

Odpowiedź @ Destil jest dobra, jeśli możesz ponownie użyć tej samej konfiguracji we wszystkich projektach. Alternatywnie, Android Studio zawiera local.propertiesplik, który może być zamiast tego używany, ale podobno jest generowany przez IDE i nie mogę znaleźć sposobu na rozszerzenie go z Android Studio.

Jest to odmiana odpowiedzi @ jonbo . Ta odpowiedź pozwala na ustawienia specyficzne dla projektu, ale wiąże się to z pewnym nakładem programistycznym. W szczególności wymagana jest znacząca podstawa do przeniesienia signingConfigsdefinicji do osobnego pliku - szczególnie, jeśli musisz to zrobić w przypadku wielu projektów, co jest głównym powodem wyboru tego rozwiązania zamiast Destil. To może być nieco złagodzony przez również w tym linię

apply plugin: 'com.android.application'

w pliku referencji, ponieważ pozwoli to na zakończenie IDE.

Wreszcie, większość rozwiązań tutaj nie pozwala na budowanie projektu w trybie debugowania - który obsługuje podpisywanie debugowania automatycznie - bez podania poprawnej składniowo, jeśli nie semantycznie, signingConfigsdefinicji. Jeśli nie musisz tworzyć kompilacji wersji z danej maszyny, ten dodatkowy krok może być postrzegany jako niepotrzebna przeszkoda. Z drugiej strony może to być pomoc przeciwko nieświadomym lub leniwym kolegom, którzy wykonują kompilacje debugowania w produkcji.

To rozwiązanie pozwoli na debugowanie kompilacji bez martwienia się o poświadczenia, ale będzie wymagało prawidłowych poświadczeń do wygenerowania kompilacji wersji i zajmuje bardzo mało danych podstawowych. Jednak ze względu na wadę może zachęcać innych do zastępowania fałszywych wartości prawdziwymi danymi uwierzytelniającymi i nie ma sposobu, aby się przed tym zabezpieczyć.

// app/build.gradle
// Define this structure in signing.gradle to enable release builds.
ext.signing = [
        storeFilePath : 'path/to/keystore',
        storePassword : 'keystore password',
        keyAlias      : 'key alias',
        keyPassword   : 'key password',
]

if (file('signing.gradle').exists()) {
    apply from: 'signing.gradle'
}

android {
    ...
    signingConfigs {
        release {
            storeFile file(project.signing.storeFilePath)
            storePassword project.signing.storePassword
            keyAlias project.signing.keyAlias
            keyPassword project.signing.keyPassword
        }
    }
    buildTypes {
        debug { ... }
        release {
            signingConfig signingConfigs.release
            ...
        }
    }
}

Tworzy to sztuczną właściwość, która służy wyłącznie do utworzenia poprawnego pod względem składniowym pliku kompilacji. Wartości przypisane do ext.signingwłaściwości są nieistotne, jeśli chodzi o kompilacje debugowania. Aby włączyć buduje uwolnienia, kopiowanie ext.signingdo signing.gradlei zastąpić wartości manekin z ważnych mandatów.

// signing.gradle
ext.signing = [
        storeFilePath : 'real/keystore',
        storePassword : 'real keystore password',
        keyAlias : 'real key alias',
        keyPassword : 'real key password',
]

Oczywiście signing.gradleVCS powinien je zignorować.

mkjeldsen
źródło
6

Prawie wszystkie platformy oferują teraz jakiś brelok, więc nie ma powodu, aby pozostawiać hasła w postaci czystego tekstu.

Proponuję proste rozwiązanie, które wykorzystuje moduł Python Keyring (głównie skrypt konsoli towarzyszącej keyring) i minimalne opakowanie wokół ['do', 'something'].execute() funkcji Groovy :

def execOutput= { args ->
    def proc = args.execute()
    proc.waitFor()
    def stdout = proc.in.text
    return stdout.trim()
}

Korzystając z tej funkcji, signingConfigssekcja staje się:

signingConfigs {
    release {
        storeFile file("android.keystore")
        storePassword execOutput(["keyring", "get", "google-play", storeFile.name])
        keyAlias "com.example.app"
        keyPassword execOutput(["keyring", "get", "google-play", keyAlias])
    }
}

Przed uruchomieniem gradle assembleReleasemusisz ustawić hasła w breloku, tylko raz:

$ keyring set google-play android.keystore # will be prompted for the passwords
$ keyring set google-play com.example.app

Szczęśliwe wydania!

naufraghi
źródło
5

Rozszerzając odpowiedź David Vavra, utwórz plik ~ / .gradle / gradle.properties i dodaj

RELEASE_STORE_FILE=/path/to/.keystore
RELEASE_KEY_ALIAS=XXXXX
RELEASE_STORE_PASSWORD=XXXXXXXXX
RELEASE_KEY_PASSWORD=XXXXXXXXX

Następnie w build.gradle

  signingConfigs {
    release {
    }
  }

  buildTypes {
    release {
      minifyEnabled true
      shrinkResources true

    }
  }

  // make this optional
  if ( project.hasProperty("RELEASE_KEY_ALIAS") ) {
    signingConfigs {
      release {
        storeFile file(RELEASE_STORE_FILE)
        storePassword RELEASE_STORE_PASSWORD
        keyAlias RELEASE_KEY_ALIAS
        keyPassword RELEASE_KEY_PASSWORD
      }
    }
    buildTypes {
      release {
        signingConfig signingConfigs.release
      }
    }
  }
SRC
źródło
5

Miałem całkiem niezłą zabawę przy rozgryzaniu tego. Oto moje przejście.

Przewodnik od A do Z na temat tworzenia pliku kompilacji stopni w IntelliJ (v.13.1.4) W tym przewodniku założono, że wiesz, jak utworzyć plik magazynu kluczy. Aby ten samouczek zadziałał, plik magazynu kluczy musi znajdować się w folderze aplikacji, a plik zipalign.exe musi znajdować się w folderze „SDK-ROOT \ tools”. Ten plik zwykle znajduje się w „SDK-ROOT \ build-tools” i pod tym folderem będzie w najwyższym folderze API (alfa lub beta, zalecam wersję alfa).

Dla tych z Was, którzy chcą wskoczyć tutaj, jest plik kompilacji stopni.

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:0.9.+'
    }
}
apply plugin: 'android'

repositories {
    mavenCentral()
}
android {
    compileSdkVersion 19
    buildToolsVersion '20.0.0'
    defaultConfig {
        minSdkVersion 8
        targetSdkVersion 19
        versionCode 1
        versionName "1.0"
    }
    signingConfigs {
        playstore {
            keyAlias 'developers4u'
            keyPassword 'thisIsNotMyRealPassword'
            storeFile file('developers4u.keystore')
            storePassword 'realyItIsNot'
        }
    }
    buildTypes {
        assembleRelease {
            debuggable false
            jniDebugBuild false
            runProguard true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
            zipAlign true
            signingConfig signingConfigs.playstore
        }
    }
}

dependencies {
    implementation fileTree(dir: 'libs', include: ['*.jar'])
    implementation 'com.android.support:support-v4:20.0.0'
    implementation 'com.android.support:appcompat-v7:20.0.0'
}

Możesz zbudować część tego pliku kompilacji (powyżej) z opcji menu: Struktura pliku / projektu Z tego miejsca wybierz Aspekty i kliknij „Android-Gradle (aplikacja). Stąd zobaczysz zakładki: „Właściwości”, „Podpisywanie”, „Aromaty”, „Typy kompilacji” i „Zależności” do tego przejścia, będziemy po prostu używać „Podpisywania” i „Typów kompilacji”. W obszarze „Typy kompilacji” (w sekcji nazwy) wprowadź dowolną nazwę, która ma identyfikować konfigurację typu kompilacji, a w pozostałych 4 polach wprowadź informacje o pliku kluczy (ustawiając ścieżkę do pliku kluczy tą pod folderem aplikacji).

Pod „Typami kompilacji” wpisz w polu nazwy wartość „assembleRelease”, „Debuggable” powinno być ustawione na false, „Jni Debug Build” powinno być false, ustawić „Run Proguard” na true, a „Zip Align” na true. Spowoduje to wygenerowanie pliku kompilacji, ale nie w sposób pokazany powyżej, będziesz musiał dodać kilka rzeczy do pliku kompilacji. Lokalizacja pliku ProGuard zostanie tutaj ustawiona ręcznie w pliku kompilacji stopni. (jak pokazano powyżej)

Kontenery DSL, które należy później dodać, są następujące:

android {
    ....
    compileSdkVersion 19
    buildToolsVersion '20.0.0'
    defaultConfig {
        minSdkVersion 8
        targetSdkVersion 19
        versionCode 1
        versionName "1.0"
    }
    ....
}

Będziesz także musiał dodać:

dependencies {
    implementation fileTree(dir: 'libs', include: ['*.jar'])
    implementation 'com.android.support:support-v4:20.0.0'
    implementation 'com.android.support:appcompat-v7:20.0.0'
}

zwróć uwagę, że powyższy kontener DSL („zależności”) powinien znajdować się na dole pliku konfiguracyjnego, ale nie powinien znajdować się w kontenerze DSL Androida. Aby zbudować kontener zależności z menu IntelliJ, wybierz: Struktura pliku / projektu. Następnie wybierz ponownie Facets, a następnie Android-Gradle (aplikacja). Zobaczysz te same 5 zakładek, jak wspomniano powyżej. Wybierz kartę „Zależności” i dodaj wymagane zależności.

Po tym wszystkim powinieneś zobaczyć plik kompilacji Gradle podobny do pliku na początku tego przewodnika. Aby zbudować podpisaną wersję dostosowaną do formatu zip, musisz otworzyć zadania Gradle. Możesz przejść do tego okna, wybierając Widok / Narzędzie Windows / Gradle. Stąd możesz dwukrotnie kliknąć „asembleAssembleRelease. Powinno to wygenerować pakiet APK do wdrożenia.

Potencjalne problemy, które mogą wystąpić podczas kompilacji wydania, to (ale nie wyłącznie): plik kompilacji Gradle znajduje się w niewłaściwym miejscu. Istnieją dwa pliki kompilacji Gradle; jeden w folderze głównym aplikacji, a drugi w folderze aplikacji w katalogu głównym aplikacji. Musisz użyć tego ostatniego.

Możesz także mieć problemy z kłaczkami. (Uwaga: Android Developer Studio jest znacznie lepszy w wykrywaniu problemów Lint niż IntelliJ, zauważysz to podczas próby wygenerowania podpisanego pliku APK z opcji menu)

Aby obejść problemy z kłaczkami, musisz umieścić następujący kontener DSL w kontenerze Androida (u góry):

android {
        ....
    lintOptions {
        abortOnError false
    }
    ....
}

umieszczenie tego w kontenerze DSL Androida spowoduje wygenerowanie pliku błędu w folderze kompilacji (bezpośrednio pod folderem aplikacji), nazwa pliku powinna być taka jak „lint-results-release-fatal.html”, ten plik powie ci klasa, w której wystąpił błąd. Kolejnym plikiem, który zostanie wygenerowany, jest plik XML zawierający „identyfikator problemu” związany z błędem kłaczków. Nazwa pliku powinna być podobna do „lint-results-release-fatal.xml”. Gdzieś w górnej części pliku zobaczysz „problem” węzła, w którym zobaczysz coś podobnego do „id =" IDOfYourLintProblem "

Aby rozwiązać ten problem, otwórz w swoim projekcie plik wymieniony w pliku „lint-results-assembleRelease-fatal.html” i wprowadź następujący wiersz kodu w pliku klasy Java tuż nad nazwą klasy: @SuppressLint („IDOfYourLintProblem” „). Być może trzeba zaimportować plik „android.annotation.SuppressLint;”

Twój plik klasy Java powinien wyglądać następująco:

package com.WarwickWestonWright.developers4u.app.CandidateArea;

import android.annotation.SuppressLint;
... other imports

@SuppressLint("IDOfYourLintProblem")
public class SearchForJobsFragment extends Fragment {... rest of your class definition}

Pamiętaj, że eliminowanie błędów kłaczków nie zawsze jest najlepszym pomysłem, dlatego lepiej zmienić kod, który spowodował błędy kłaczków.

Innym problemem, który może potencjalnie wystąpić, jest brak ustawienia zmiennej środowiskowej dla zmiennej środowiskowej Gradle HOME. Ta zmienna nosi nazwę „GRADLE_HOME” i powinna mieć ustawioną ścieżkę do katalogu domowego gradle, coś w rodzaju „C: \ gradle-1.12”. Czasami możesz również chcieć ustawić zmienną środowiskową dla „ANDROID_HOME”, ustaw ją na „YOUR- SDK-Root \ sdk '

Po tym powróć do okna zadań Gradle i kliknij dwukrotnie assembleAssembleRelease.

Jeśli wszystko się powiedzie, powinieneś być w stanie przejść do folderu app \ build \ apk i znaleźć plik APK do wdrożenia.

użytkownik2288580
źródło
+1 za wysiłek i: „lintOptions {abortOnError false}”
Raz Tourgman
4

Jeszcze inne podejście do tego samego problemu. Ponieważ nie jest zalecane przechowywanie jakichkolwiek poświadczeń w kodzie źródłowym, postanowiliśmy ustawić hasła do magazynu kluczy i aliasu kluczy w osobnym pliku właściwości w następujący sposób:

key.store.password=[STORE PASSWORD]
key.alias.password=[KEY PASSWORD]

Jeśli używasz git, możesz utworzyć plik tekstowy o nazwie na przykład secure.properties. Pamiętaj, aby wykluczyć go ze swojego repozytorium (jeśli używasz git, dodając go do pliku .gitignore). Następnie musisz utworzyć konfigurację podpisywania, jak wskazują niektóre inne odpowiedzi. Jedyna różnica polega na sposobie ładowania poświadczeń:

android {
    ...
    signingConfigs {
        ...
        release {
            storeFile file('[PATH TO]/your_keystore_file.jks')
            keyAlias "your_key_alias"

            File propsFile = file("[PATH TO]/secure.properties");
            if (propsFile.exists()) {
                Properties props = new Properties();
                props.load(new FileInputStream(propsFile))
                storePassword props.getProperty('key.store.password')
                keyPassword props.getProperty('key.alias.password')
            }
        }
        ...
    }

    buildTypes {
        ...
        release {
            signingConfig signingConfigs.release
            runProguard true
            proguardFile file('proguard-rules.txt')
        }
        ...
    }
}

Nigdy nie zapomnij ręcznie przypisać signingConfig do typu kompilacji wydania (z jakiegoś powodu czasami zakładam, że zostanie on użyty automatycznie). Ponadto włączenie proguard nie jest obowiązkowe, ale jest zalecane.

Podobało nam się to podejście bardziej niż używanie zmiennych środowiskowych lub prośba o dane wejściowe użytkownika, ponieważ można to zrobić z IDE, przełączając się na typ kompilacji w Realease i uruchamiając aplikację, zamiast konieczności korzystania z wiersza poleceń.

argenkiwi
źródło
1
Gradle nie kompiluje się przy użyciu: props = new Properties (); Nie można ustawić wartości właściwości „rekwizyty” tylko do odczytu
cesards
Masz rację @ m3n0R. Zredagowałem wiersz mojej odpowiedzi, aby odzwierciedlić poprawkę, którą musieliśmy wprowadzić w naszej aplikacji, aby nadal kompilowała się przy użyciu najnowszych wersji Gradle. Zasadniczo rekwizyty należy zadeklarować jako zmienną lokalną.
argenkiwi
jak to byłoby możliwe do zastosowania za pomocą narzędzi CI / CD w chmurze ... / path / to / keystore i /path/to/secure.props rzuca mi .... dzięki za to.
Sirvon,
4

Android Studio Przejdź do Plik -> Struktura projektu lub naciśnij Ctrl + Alt + Shift + S

Zobacz obraz

wprowadź opis zdjęcia tutaj

Kliknij OK

Następnie signingConfigs wygeneruje plik build.gradle.

wprowadź opis zdjęcia tutaj

Ahamadullah Saikat
źródło
I to jest dokładnie to, czego nie chcesz robić. W ten sposób wszystkie hasła są jawne i stanowią część projektu i bardzo łatwo przypadkowo je włączyć, nawet w rozproszonej wersji.
not2qubit
2

Miałem kilka problemów, które umieściłem następujący wiersz w niewłaściwym miejscu:

signingConfigs {
    release {
        // We can leave these in environment variables
        storeFile file("d:\\Fejlesztés\\******.keystore")
        keyAlias "mykey"

        // These two lines make gradle believe that the signingConfigs
        // section is complete. Without them, tasks like installRelease
        // will not be available!
        storePassword "*****"
        keyPassword "******"
    }
}

Upewnij się, że umieścisz części signingConfigs w sekcji Androida:

android
{
    ....
    signingConfigs {
        release {
          ...
        }
    }
}

zamiast

android
{
    ....
}

signingConfigs {
   release {
        ...
   }
}

Łatwo jest popełnić ten błąd.

Botond Kopacz
źródło
2

Jest rok 2019 i muszę podpisać APK za pomocą V1 (sygnatura jar) lub V2 (pełna sygnatura APK). Poszukałem Google „generuj podpisaną klasę APK” i to mnie tu przywiodło. Więc dodaję tutaj moje oryginalne rozwiązanie.

signingConfigs {
    release {
        ...
        v1SigningEnabled true
        v2SigningEnabled true
    }
}

Moje oryginalne pytanie: jak korzystać z V1 (sygnatura jar) lub V2 (pełna sygnatura APK) z pliku build.gradle

użytkownik1506104
źródło
Nie potrzeba średników; da ci błąd.
Takeshi Kaga,
Zgadza się. Dzięki. Zredagowałem odpowiedź.
user1506104,
1

Aby uzupełnić inne odpowiedzi, możesz również umieścić plik gradle.properties we własnym folderze modułu wraz z build.gradle, na wypadek, gdyby Twój plik kluczy był specyficzny dla jednego projektu.

cprcrack
źródło
1

pracuję w Ubuntu14.04. vim ~ / .bashrc i dodaj eksport ANDROID_KEYSTORE = eksport ANDROID_KEYALIAS =

a następnie w zestawie build.gradle.

    final Console console = System.console();
if (console != null) {

    // Building from console
    signingConfigs {
        release {
            storeFile file(System.getenv("KEYSTORE"))
            storePassword new String(System.console().readPassword("\n\$ Enter keystore password: "))
            keyAlias System.getenv("KEY_ALIAS")
            keyPassword new String(System.console().readPassword("\n\$ Enter key password: "))
        }
    }

} else {

    // Building from IDE's "Run" button
    signingConfigs {
        release {

        }
    }

}
ayyb1988
źródło
IMHO wydaje się to najlepszym rozwiązaniem, ale niestety przestało działać na nowszych wersjach Gradle : System.console()powraca null.
Antonio Vinicius Menezes Medei,
1

Alternatywą jest zdefiniowanie zadania, które działa tylko w kompilacjach wersji.

android {
  ...
  signingConfigs {
     release {
        // We can leave these in environment variables
        storeFile file('nameOfKeystore.keystore')
        keyAlias 'nameOfKeyAlias'

        // These two lines make gradle believe that the signingConfigs
        // section is complete. Without them, tasks like installRelease
        // will not be available!
        storePassword "notYourRealPassword"
        keyPassword "notYourRealPassword"

     }
  }
  buildTypes {
     ...
     release {
        signingConfig signingConfigs.release
        ...
     }
  }
  ...
}

task setupKeystore << {
final Console console = System.console();
if (console != null) {
    //def keyFile = console.readLine(“\nProject: “ + project.name + “Enter keystore path: "))
    //def keyAlias = console.readLine(“Project: “ + project.name + “Enter key alias: ")
        def storePw = new String(console.readPassword(“Project:  + project.name + “. Enter keystore password: "))
        def keyPw  = new String(console.readPassword(“Project: “ + project.name + “.Enter keystore password: "))

    //android.signingConfigs.release.storeFile = file(keyFile);
    //android.signingConfigs.release.keyAlias = keyAlias
        android.signingConfigs.release.storePassword = storePw
        android.signingConfigs.release.keyPassword = keyPw
}
}

//Validate t
def isReleaseConfig = gradle.startParameter.taskNames.any {it.contains('Release') }
if (isReleaseConfig) {
    setupKeystore.execute();
}
davidpetter
źródło
Wydaje mi się, że preferowane są: stackoverflow.com/a/19130098/3664487 Jaka jest różnica między tymi dwoma podejściami?
user2768,
1

Możesz poprosić o hasło z wiersza poleceń:

...

signingConfigs {
  if (gradle.startParameter.taskNames.any {it.contains('Release') }) {
    release {
      storeFile file("your.keystore")
      storePassword new String(System.console().readPassword("\n\$ Enter keystore password: "))
      keyAlias "key-alias"
      keyPassword new String(System.console().readPassword("\n\$ Enter keys password: "))
    } 
  } else {
    //Here be dragons: unreachable else-branch forces Gradle to create
    //install...Release tasks.
    release {
      keyAlias 'dummy'
      keyPassword 'dummy'
      storeFile file('dummy')
      storePassword 'dummy'
    } 
  }
}

...

buildTypes {
  release {

    ...

    signingConfig signingConfigs.release
  }

  ...
}

...

if-then-elseBlok zapobiega żądania haseł gdy budujesz uwolnienie. Chociaż elsegałąź jest nieosiągalna, nakłania Gradle'a do utworzenia install...Releasezadania.

Backstory . Jak zauważył https://stackoverflow.com/a/19130098/3664487 , „ Skrypty Gradle mogą pytać użytkownika o dane wejściowe za pomocą metody System.console (). ReadLine ”. Niestety, Gradle zawsze prosi o hasło, nawet podczas budowania wersji debugowania (por. Jak utworzyć plik apk podpisany wersją za pomocą Gradle? ). Na szczęście można temu zaradzić, jak wykazałem powyżej.

użytkownik2768
źródło
Moja odpowiedź wcześniej wpadł na problemy wynikające z stackoverflow.com/questions/33897802/... . Poprawiłem swoją odpowiedź, aby wyeliminować ten problem.
user2768,
@Haroon, działa od 24 listopada '15. Społeczność może być może pomóc w rozwiązaniu problemu, ale musisz podać więcej szczegółów.
user2768
Podoba mi się to rozwiązanie, ponieważ pozwala uniknąć umieszczania hasła w postaci zwykłego tekstu w pliku tekstowym, ale System.console (). ReadLine nie działa stopniowo z powodu tego irytującego problemu.
Morfeusz
@morpheus, nigdy nie miałem problemu. Powyższe działa dla mnie.
user2768,
Myślę, że uruchamiasz skrypt z IDE. jeśli skrypt zostanie uruchomiony z terminala, zobaczysz błąd. ale dziękuję za tę odpowiedź. tego szukałem.
Morfeusz
0

Dodając mój sposób, aby to zrobić w React-Native przy użyciu pakietu React-Native -config .
Utwórz plik .env:

RELEASE_STORE_PASSWORD=[YOUR_PASSWORD]
RELEASE_KEY_PASSWORD=[YOUR_PASSWORD]

Uwaga: nie powinno to być częścią kontroli wersji.

w twoim build.gradle:

signingConfigs {
        debug {
            ...
        }
        release {
            storeFile file(RELEASE_STORE_FILE)
            storePassword project.env.get('RELEASE_STORE_PASSWORD')
            keyAlias RELEASE_KEY_ALIAS
            keyPassword project.env.get('RELEASE_KEY_PASSWORD')
        }
    }
chenop
źródło
0

W moim przypadku przesyłałem niewłaściwy apk do wydania innej aplikacji.

Dewsworld
źródło
0

Dla Groovy (build.gradle)

Nie należy umieszczać poświadczeń podpisujących bezpośrednio w pliku build.gradle . Zamiast tego poświadczenia powinny pochodzić z pliku niepodlegającego kontroli wersji.

Umieść plik signing.properties w miejscu, w którym znajduje się specyficzny dla modułu build.gradle . Nie zapomnij dodać go do pliku .gitignore !

signing.properties

storeFilePath=/home/willi/example.keystore
storePassword=secret
keyPassword=secret
keyAlias=myReleaseSigningKey

build.gradle

android {
    // ...
    signingConfigs{
        release {
            def props = new Properties()

            def fileInputStream = new FileInputStream(file('../signing.properties'))
            props.load(fileInputStream)
            fileInputStream.close()

            storeFile = file(props['storeFilePath'])
            storePassword = props['storePassword']
            keyAlias = props['keyAlias']
            keyPassword = props['keyPassword']
        }
    }

    buildTypes {
        release {
            signingConfig signingConfigs.release
            // ...
        }
    }
}
Willi Mentzel
źródło
0

Dla skryptu Kotlin (build.gradle.kts)

Nie należy umieszczać poświadczeń podpisujących bezpośrednio w pliku build.gradle.kts pliku . Zamiast tego poświadczenia powinny pochodzić z pliku niepodlegającego kontroli wersji.

Umieść plik signing.properties w miejscu, w którym znajduje się plik build.gradle.kts specyficzny dla modułu . Nie zapomnij dodać go do pliku .gitignore !

signing.properties

storeFilePath=/home/willi/example.keystore
storePassword=secret
keyPassword=secret
keyAlias=myReleaseSigningKey

build.gradle.kts

android {
    // ...
    signingConfigs {
        create("release") {
            val properties = Properties().apply {
                load(File("signing.properties").reader())
            }
            storeFile = File(properties.getProperty("storeFilePath"))
            storePassword = properties.getProperty("storePassword")
            keyPassword = properties.getProperty("keyPassword")
            keyAlias = "release"
        }
    }

    buildTypes {
        getByName("release") {
            signingConfig = signingConfigs.getByName("release")
            // ...
        }
    }
}
Willi Mentzel
źródło
-1

jeśli nie chcesz widzieć Nie można wywołać metody readLine () na obiekcie o wartości null. najpierw musisz napisać w gradle.properties .

KEYSTORE_PASS=*****
ALIAS_NAME=*****
ALIAS_PASS=*****
JeasonWong
źródło