Vaiheittainen opas Android-koodin allekirjoittamiseen ja koodin allekirjoittamiseen Codemagicilla

Sovellusten rakentaminen on intohimoa, jonka jakavat ohjelmistokehittäjät ympäri maailmaa. Mutta koodin allekirjoittamisen hallinnoinnista aiheutuva hallinnollinen taakka on ikävää. Miten saamme sen tehtyä oikein ensimmäisellä kerralla? Lewis Cianci tutkii asiaa.

Sallikaa minun sanoa tämä heti aluksi.

Koodin allekirjoittaminen on niin tylsää, että hampaita särkee. Se on käsite, joka on olemassa hyvästä syystä. Tarkoitan, että haluat ihmisten olevan varmoja siitä, että ohjelmistopakettisi on todella peräisin sinulta, eikö niin?! Silti niin monet kehittäjät kamppailevat sen kanssa päivittäin. Se on kuin veroilmoituksen tekeminen koko työvuoden jälkeen, kun on täytettävä niin monta lomaketta. Yippee.

Rullaa alaspäin, jos haluat vain nähdä vaiheittaisen oppaan Android-koodin allekirjoittamisesta etkä ole kiinnostunut siitä, miksi me teemme tämän😉

Miksi me koodin allekirjoitamme

Signoimme pakettimme, jotta ihmiset, jotka lataavat pakettimme Play-kaupasta, todella tietävät, että se on meistä. Teemme tämän allekirjoittamalla pakettimme luomallamme avaimella. Kun lataamme allekirjoitetun pakettimme Google Playyn, se muistaa avaimen, jota käytettiin alkuperäisen paketin lataamiseen, ja varmistaa, että seuraavat paketit allekirjoitetaan samalla avaimella.

Tämän tavoitteen saavuttamiseksi Android-pakettien allekirjoittaminen hyödyntää itse asiassa Java-kehityskehyksen sisältämää työkalua nimeltä keytool. Keytool on ollut olemassa luultavasti yhtä kauan kuin itse JDK, joten se on melko vanha. Tämä sopii luultavasti joihinkin syihin, miksi APK:n tai AAB:n (android-sovellusnipun) allekirjoittaminen on niin hämmentävää kuin se on.

Miksi Play Store ei voi vain hoitaa koodin allekirjoittamista puolestamme?

Meillä olisi houkutus pyytää nirvanaa, jossa voisimme vain antaa kaikki allekirjoittamattomat sovelluspakettimme Play Storen haltuun ja antaa heidän vain selvittää ja allekirjoittaa ne puolestamme. Sen logiikka kuitenkin hajoaa nopeasti. Jos kirjoittaisit kirjan, antaisitko jonkun muun signeerata sen? En. Sinä allekirjoittaisit sen, koska olet itse tekijä.

Nykyään koodin allekirjoittaminen on paljon helpompaa kuin ennen. Niin kauan kuin allekirjoitamme pakettimme aina samalla avaimella (”latausavaimella”), Google Play itse asiassa luo ja hallinnoi koodin allekirjoitusavaimemme puolestamme.

Jos olet erityisen yritteliäs, voit yrittää lukea ja ymmärtää kaiken täällä olevan, mutta olen kehittänyt Androidille suurimman osan kolmesta vuodesta, ja joudun valitettavasti toteamaan, että edes minä en ymmärrä sitä täysin. Tiedän vain sen, että kun se hajoaa, sen korjaaminen on valtava tuska.

Vietetään aikaa ymmärtääksemme paitsi miten koodaamme merkkejä, myös miksi koodaamme merkkejä. Kun ymmärrämme tämän prosessin tarpeellisuuden, se helpottaa sen suorittamista.

Mitä tarvitsemme koodisignointiin?

Lyhyt versio on tässä. Koodin allekirjoittamista varten tarvitsemme:

• luoda JDK-tiedoston (Java Development Kit);
• kirjoittaa sovelluspakettimme tai APK:n yksityisellä avaimellamme;
• muokata build.gradle-tiedostoa;
• lähettää paketti jakelijalle (Google Play).

Tämän artikkelin lopussa kerrotaan myös, miten koodin allekirjoittaminen onnistuu koodin allekirjoittajalta Codemagicilla.

Nyt hieman pidempi versio, jossa on vaiheittainen opas siitä, mitä tarvitsemme Android-koodin allekirjoittamiseen ja miten se tehdään.

Vaiheittainen opas Android-koodin allekirjoittamiseen

VAIHE 1: Java-kehityspaketti (Java Development Kit, JDK)

Jos olet kehittämässä Androidille, sinulla on luultavasti jo nämä asennettuna.

Tarvitsemme JKS-tiedoston (Java Key Store, Java-avaimen säilytyspaikka)

Meidän pitää luoda Java Key Store (JKS) tiedosto, joka pitää sisällään allekirjoituksen tiedot. Luodessamme JKS-tiedoston sovellustamme varten luomme itse asiassa yksityisen avaimen tietokoneellamme. Tämä yksityinen avain on suojattu asettamallamme salasanalla.

Komentokehotteesta voimme kirjoittaa seuraavaa saadaksemme JKS:n.

keytool -genkey -v -keystore %DESKTOP%/key.jks -storetype JKS -keyalg RSA -keysize 2048 -validity 10000 -alias DEVELOPERNAME

Käskemme keytoolluoda Java Key Storen ja laittaa sen työpöydällemme. Tämä avain on voimassa 10 000 päivää eli noin 27 vuotta, jolloin voimme työntää päivityksiä sovelluksemme eliniän ajan. Meidän on myös asetettava alias. Teen tästä vain kehittäjänimeni tai jotain, jonka muistan.

keytool kysyy matkan varrella erilaisia tietoja. On tärkeää määrittää nämä oikein, sillä määrittelemme pohjimmiltaan yksityisen avaimemme tiedot.

Sinulta kysytään:

• Keystore-salasana – tarvitset tätä avataksesi avainsäilön uudelleen tulevaisuudessa. Jos kadotat tämän salasanan, sen palauttaminen on melko mahdotonta.
• Syötä keystore-salasana uudelleen
• Henkilökohtaiset tiedot siitä, mitä laitetaan henkilökohtaiseen varmenteeseen

Meitä pyydetään täyttämään joitakin tietoja meistä. Nämä tiedot liittyvät yksityiseen avaimeemme, joten niiden pitäisi olla jokseenkin merkityksellisiä. On sinusta kiinni, mitä laitat näihin kenttiin, mutta nyrkkisääntönä en tekisi niistä liian hulluja.

Tässä on keytool:n tuloste.

C:\code\signingtest\android\app>keytool -genkey -v -keystore key.jks -storetype JKS -keyalg RSA -keysize 2048 -validity 10000 -alias androidappsEnter keystore password:Re-enter new password:What is your first and last name?: Codemagic Article DudeWhat is the name of your organizational unit?: Fantastic Apps And Where To Find ThemWhat is the name of your organization?: GreatappsWhat is the name of your City or Locality?: EstoniaWhat is the name of your State or Province?: TartuWhat is the two-letter country code for this unit?: EEIs CN=Codemagic Article Dude, OU=Fantastic Apps And Where To Find Them, O=Greatapps, L=Estonia, ST=Tartu, C=ES correct?:

Katsokaa! Jos vain roskapostitat Enteriä tämän prosessin läpi, luonti vain silmukoituu yhä uudelleen ja uudelleen, kun vastaat ”ei” viimeiseen kysymykseen.

Tämässä olemme luoneet JKS:n ja laittaneet siihen oman generoidun yksityisen avaimemme. Koska olemme luoneet sen ja asettaneet salasanan, voimme olla varmoja siitä, että kuka tahansa, jolla on tämä JKS-tiedosto, on joko me tai hänellä on erityinen lupa käyttää sitä.

Jos jollakulla on sinun JKS:si ja oikeat tunnukset, hän voi allekirjoittaa paketit sinuna tai yrityksenäsi. Pidä se turvassa, älä laita sitä lähdekoodinhallintaan.

Nyt meillä on Java Key Store, joten olemme puolivälissä! Iloitse vastaavasti.

VAIHE 2: Sovelluspakettimme tai APK:n allekirjoittaminen yksityisellä avaimellamme

Nyt haluamme allekirjoittaa sovelluspakettimme juuri tekemällämme JKS:llä. On mahdollista allekirjoittaa APK- tai julkaisubuildimme manuaalisesti koodilla joka ikinen kerta, mutta todellisuudessa meidän olisi parempi konfiguroida se niin, että kun ajamme flutter build apk --release, se vain allekirjoittaa pakettimme automaattisesti oikealla latausavaimella. Flutterin dokumentaatiossa puhutaan Gradle-tiedostojen päivittämisestä tässä kohtaa, mutta käymme sen läpi hitaasti ja selitämme sen matkan varrella.

Aloitetaan avaamalla flutter_app/android/app/build.gradle-tiedostomme. Noin rivillä 49 näemme tämän:

buildTypes { release { // TODO: Add your own signing config for the release build. // Signing with the debug keys for now, so flutter run --release works. signingConfig signingConfigs.debug }}

Tärkeintä tässä on se, että rakennuksemme allekirjoitetaan debug-keystorella, joten release-rakennuksemme toimii edelleen. Haluamme muuttaa tämän niin, että julkaisumme allekirjoitetaan omalla avainsäilöllämme. Näin ne voidaan ladata Google Play -kauppaan.

Aluksi luomme key.properties sovellushakemistossamme. Luomme tämän flutter_app/android/key.properties.

key.properties sisältää kaikki tiedot, joita tarvitsemme pakettimme onnistuneeseen allekirjoittamiseen.

storePassword=The JKS store passwordkeyPassword=The key passwordkeyAlias=The alias for your keystoreFile=Where to look for your keystore file

Pikahuomautus lähdekoodinhallinnasta

Tulee miettiä, ennen kuin kirjaa tämän koodin lähdekoodinhallintaan. Jos pahat toimijat pääsisivät käsiksi avainsäilöön ja näihin tunnistetietoihin, ja heillä olisi hallussaan tilisi, he voisivat mahdollisesti työntää sovellukseesi uuden päivityksen, joka sisältää haittaohjelmia tai muita pahoja asioita. Useimmat CI/CD-ratkaisut antavat sinun antaa nämä tiedot ”salaisuuksina”, mutta toteutus vaihtelee alustakohtaisesti.

VAIHE 3: Yhteenveto & build.gradle-tiedoston muokkaaminen

Olemmekin tehneet avainsäilytystiedoston ja määrittäneet aliaksen sekä salasanan suojaamaan avainsäilytystietoja. Jos käytämme Google Play -sovelluksen allekirjoitusta (jota käytät oletusarvoisesti), luomaamme avain toimii latausavaimena. Ensimmäinen Google Play -konsolin kautta lataamamme paketti allekirjoitetaan tällä avaimella. Tämä todistaa Googlelle, että olemme sitä, keitä väitämme olevamme.

Tuntuuko järkevältä? Siistiä, laitetaan se allekirjoittamaan osana Flutterin rakentamisprosessiamme.

Muokkaa build.gradle

Avaa flutter_app/android/app/build.gradle. Noin rivillä 31 sinun pitäisi nähdä tällaista tekstiä:

android { compileSdkVersion 29` lintOptions { disable 'InvalidPackage' }...

Haluamme kertoa Gradlelle, mistä avainsäilö löytyy. Teemme sen laittamalla nämä tiedot noin riville 28, android {-lausekkeen yläpuolelle.

def keystoreProperties = new Properties()def keystorePropertiesFile = rootProject.file('key.properties')if (keystorePropertiesFile.exists()) { keystoreProperties.load(new FileInputStream(keystorePropertiesFile))}

Kerrotaanpa edellä oleva…

Määrittelemme keystoreProperties-muuttujan. Sitten tarkistamme, onko key.properties olemassa suhteessa android-projektimme (ei Flutter-projektin) juureen.

Kun buildimme suoritetaan, se lataa key.properties. key.properties yksilöi avainsäilön sijainnin sekä tarvittavat tunnistetiedot, joilla Java Key Store avataan paketin allekirjoittamista varten. Kun kaikki tarvittavat tiedot ovat hallussa, Gradle allekirjoittaa nyt sovelluspaketin tai APK:n osana julkaisubuildiamme.

Tarkistetaan vielä, että kaikki tiedostomme ovat oikeassa paikassa.

Muuttamamme build.gradle:n tiedosto on kohdassa flutter_app/android/app/build.gradle.

Meidän key.jks -tiedostomme on osoitteessa flutter_app/android/app/key.jks.

Meidän key.properties-tiedostomme on osoitteessa flutter_app/android/key.properties.

Kun olemme varmoja edellä mainituista, meidän pitäisi pystyä ajamaan flutter build apk --release nyt ja allekirjoittamisen pitäisi toimia hienosti.

VAIHE 4: Lähettäminen Google Play Storeen

Nyt voimme ladata APK:n tai sovelluskokonaisuutemme Play Storeen. Kun teemme tämän allekirjoitetun pakettimme kanssa ja Google Play Signingin ollessa päällä (joka on oletusarvoisesti päällä), Google tunnistaa paketin allekirjoittamiseen käyttämämme avaimen ja muistaa sen latausavaimena. Google allekirjoittaa sitten APK- tai sovelluspakettimme omalla avaimellaan. On tärkeää, että kaikki tämän sovelluksen myöhemmät päivitykset allekirjoitamme tällä samalla avaimella. Google Play tunnistaa tämän avaimen latausavaimeksemme, emmekä voi julkaista päivityksiä ilman sitä.

En ymmärrä mitään edellä mainituista ja arvostaisin uskomattoman visuaalista havainnollistusta siitä, mitä tarkalleen ottaen tapahtuu.

Voin tehdä! Näin tapahtuu.

1. Luomme supersalaisen tavan tunnistaa itsemme, melkein kuin tekisimme itsellemme passin.
2. Koska kuka tahansa, jolla on tämä ”passi”, pystyy tunnistamaan itsensä positiivisesti meikäläiseksi (eli: esittämään meitä ilman suurempaa vastarintaa), lukitsemme sen salasanan taakse kassakaappiimme (JKS eli Java Key Store).
3. Luomme sovelluspaketin eli APK:n ja allekirjoitamme paketin samalla allekirjoituksella, jota käytimme passissa. Jotta pääsemme käsiksi tähän passiin, meidän on avattava kassakaappi, jossa passi on (antamalla salasana ja alias Gradle build -prosessille).
4. Lähetämme paketin jakelijalle (Google Play). Jakelija, joka näkee paketin ensimmäistä kertaa, panee merkille allekirjoituksemme, jota käytimme tässä paketissa, ja ottaa siitä kopion.
5. Kun lähetämme jatkossa paketteja jakelijalle (Google Play), allekirjoitamme nämä paketit samoilla tiedoilla, joita käytimme alun perin. Jakelijamme, joka muistaa paketin lähettämiseen alun perin käyttämämme tiedot, joko hyväksyy tai hylkää paketin. Jos tiedot täsmäävät (jos latausavain on sama kuin alun perin käyttämämme avain), paketti hyväksytään ja jaetaan. Muussa tapauksessa sitä ei hyväksytä.
6. Jakelijamme, joka tietää, että alkuperäinen paketti ja mahdolliset tulevat paketit ovat varmasti meiltä, jakaa paketin.

Koodin allekirjoittamisen saaminen toimimaan Codemagicilla

Haluamme viime kädessä allekirjoittaa tämän osana CI/CD-työnkulkua, mutta samalla emme halua tarkastaa avaintallennustietokansiotamme ja ominaisuustiedostoa lähdekoodinhallintaan. Sen sijaan haluamme, että CI/CD-palveluntarjoajamme rakentaa paketin ja allekirjoittaa sen sitten myöhemmin rakentamisprosessin aikana tarjoamallamme avainsäilöllä.

Asennus Gitillä

Jos meillä on täysin uusi Flutter-sovellus, voimme siirtyä kansioon ja kirjoittaa git init aloittaaksemme lähdekoodinhallinnan käytön sovelluksen kanssa.

Oletusarvoisesti tarkistamme vain iloisesti keystore- ja keystore-ominaisuustiedostomme, mikä on tietoturvan kannalta huono idea.

Tämä kannattaa tehdä heti alusta alkaen

Jos tarkistat vahingossa keystore-ominaisuutesi ja keystore-tiedostosi ja tyrkytät nuo muutokset, ihmiset pystyvät nyppimään nuo tiedostot ulos milloin tahansa tulevaisuudessa katsomalla Git-historiaasi. Voit poistaa tiedostot manuaalisesti Gitistä tulevaisuudessa tai voit alustaa arkistosi uudelleen ilman kyseisiä tiedostoja, mutta on parempi olla tarkistamatta niitä alun perin.

Haluamme lisätä nämä rivit .gitignore-tiedostomme loppuun:

# Don't check in the keystore files or equivalent*.jkskey*.properties

Javan avaintallennustietokantaa (JKS) tai koodin allekirjoittamiseen tarkoitettuja ominaisuuksia ei tarkisteta lähdekoodinhallintaan. Kuinka ihanaa.

Making build.gradle not sign when running on CI/CD

While your project is building, the keystore and settings are not available. Haluamme, että build tuottaa silti julkaisubuildin, vaikka sitä ei ole allekirjoitettu.

Tämä osa build.gradle:ssani mahdollistaa tämän:

signingConfigs { file(rootProject.file('key.properties')).with { propFile -> if (propFile.canRead()) { release { keyAlias keystoreProperties keyPassword keystoreProperties storeFile file(keystoreProperties) storePassword keystoreProperties } } else { print('not signed') } }}buildTypes { release { file(rootProject.file('key.properties')).with { propFile -> if (propFile.canRead()) { // because we can read the keystore // we are building locally // so sign locally // otherwise build an unsigned apk for later signing by the CI/CD provider signingConfig signingConfigs.release } } applicationVariants.all { variant -> variant.outputs.all { output -> output.outputFileName = "app-release.apk" } } // TODO: Add your own signing config for the release build. // Signing with the debug keys for now, so `flutter run --release` works. // signingConfig signingConfigs.release }}

Codemagicin asettaminen allekirjoittamaan buildimme

Build-prosessissasi etsi Android-koodin allekirjoittamista koskeva osio (se on Publish-osiossa). Se näyttää tältä:

Lataamme nyt avaintallennussäilömme ja asetamme salasanamme, avaimen aliaksen ja avaimen salasanan (jotka ovat samat, jotka asetimme alun perin keystore.properties-tiedostossamme).

Sitten painamme painiketta ”Tallenna”. Kun Codmagic ajaa rakentamisprosessimme, se tuottaa meille automaattisesti allekirjoitetun APK:n tai App Bundlen.

Ja siinä se suurin piirtein on! Tämän allekirjoitetun APK:n tai App Bundlen avulla voit ottaa sovelluksesi käyttöön Play Storeen.

Voit katsoa Git-repostani esimerkin täältä (luonnollisesti ilman avaintallennustietokantaa tai ominaisuuksia).

Se on siinä.

Jos olet vielä hukassa, ilmoita minulle osoitteeseen @azimuthapps, niin yritän auttaa. Voi olla turhauttavaa saada se oikein, mutta kun se on tehty, sen pitäisi toimia lähitulevaisuudessa.

Lewis Cianci on ohjelmistokehittäjä Brisbanessa, Australiassa. Hänen ensimmäisessä tietokoneessaan oli nauha-asema. Hän on kehittänyt ohjelmistoja ainakin kymmenen vuotta, ja hän on käyttänyt aika monta mobiilikehityskehystä (kuten Ionic ja Xamarin Forms) sinä aikana. Siirryttyään Flutteriin hän ei kuitenkaan koskaan palaa takaisin. Voit tavoittaa hänet hänen blogissaan, lukea muista ei-fluttermaisista asioista Mediumista tai ehkä nähdä hänet vilaukselta lähimmässä ja hienoimmassa kahvilassasi hänen ja hänen rakkaan vaimonsa kanssa.

Lisää artikkeleita Lewis: