Bağımlılıklarınızı yükselttiğinizde en yeni özelliklerine, hata düzeltmelerine ve iyileştirmelerine erişebilirsiniz. Bağımlılıklarınızı yükseltmek için Gradle'in istediğiniz sürümleri nasıl çözdüğünü, bununla ilgili riskleri ve bu riskleri azaltmak için atabileceğiniz adımları anlamanız gerekir.
Yükseltme stratejinizi göz önünde bulundurun
Yükseltme işleminin en önemli adımı risk analizidir. Yükselttiğiniz her bağımlılıkla ilgili ne kadar rahat olduğunuzu belirleyin. Yükseltme stratejinizi belirlerken dikkate almanız gereken birçok husus vardır. Örneğin:
Kitaplık oluşturma |
Kullanıcıların indirip cihazlarında çalıştıracağı bir uygulama mı geliştiriyorsunuz? Yoksa diğer geliştiricilerin uygulamalarını oluşturmasına yardımcı olacak bir kitaplık mı geliştiriyorsunuz? Bir uygulama geliştiriyorsanız uygulamanızı güncel ve kararlı tutmaya odaklanmanız gerekir. Kitaplık oluşturuyorsanız diğer geliştiricilerin uygulamalarına odaklanmanız gerekir. Yükseltmeleriniz tüketicilerinizi etkiler. Bağımlılıklarınızdan birini yükseltirseniz bu sürüm, Gradle'ın bağımlılık çözümü için aday olur ve uygulamanın bu bağımlılığı kullanması bozulabilir. Öncelikle, mümkün olduğunda kitaplığınızın bağımlılıklarını en aza indirin. Bağımlılıklarınızın sayısı ne kadar az olursa tüketicinizin bağımlılık çözümü üzerindeki etkisi de o kadar düşük olur. Yaptığınız değişiklik türlerini belirtmek için anlamsal sürüm oluşturmayı izlediğinizden emin olun. Örneğin, AndroidX semantik sürümlemeyi takip eder ve sürüm öncesi sürüm planı ekler. Tüketicilerinizin zarar görmesini önlemek için Kullanıcıların erkenden test edebilmesi için kitaplığınızın sürüm adayı (RC) oluşturmayı düşünebilirsiniz. Kitaplığınızın Uygulama İkili Arayüzü'nün (ABI) uyumluluğunu koruma hakkında ayrıntılı bilgi için Kitaplık yazarları için geriye dönük uyumluluk yönergeleri başlıklı makaleyi inceleyin. ABI değişikliklerinizin istediğiniz sürüm değişikliğiyle eşleştiğinden emin olmak için İkili uyumluluk doğrulayıcı gibi entegrasyon testlerini ve araçları kullanın. Kitaplığınızın Kitaplığınızı yeni sürüme geçirmek, tüketicileriniz için özellikle can sıkıcı olabilecek değişikliklerin bozulmasını gerektiriyorsa, eski ve yeni sürümlerin bir arada bulunabilmesi ve daha kademeli olarak kullanıma sunulabilmesi için bunları yeni bir eser olarak yayınlamayı düşünebilirsiniz. Not: Bağımlılıklarınızdan birinde yapılan yükseltme önemli bir API değişikliği içeriyorsa muhtemelen |
Lansman süreci |
Uygulamanızı veya kitaplığınızı ne sıklıkta yayınlıyorsunuz? Daha kısa geliştirme ve sürüm döngüleri
Daha uzun geliştirme ve sürüm döngüleri
|
En yeni özelliklerden haberdar olun |
Mevcut en son özellikleri ve API'leri kullanmayı mı yoksa yalnızca bir özellik veya hata düzeltmesine ihtiyacınız olduğunda yükseltme yapmayı mı tercih edersiniz? Sık sık yükseltme yapmanın avantajlarını ve dezavantajlarını göz önünde bulundurun. Gelecekteki yükseltmeler daha kolaydır (entegre edilecek daha az değişiklik vardır) ancak yükseltme risklerini daha sık alırsınız. Kitaplıkların yayın öncesi (alfa, beta, sürüm adayı) sürümlerine yapılan yükseltmeleri test etmek, kararlı sürümler kullanıma sunulduğunda hazırlıklı olmanıza yardımcı olabilir. |
Yeni bağımlılık |
Yeni bir bağımlılık ekleyecekseniz bu kitaplığın tüm risk ölçütlerine göre incelenmesini sağlayarak doğru şekilde değerlendirildiğinden emin olmak için güçlü bir inceleme süreci uygulayın. İnceleme yapılmadan yeni bağımlılıkların eklenmesine izin vermeyin. |
Özel ekip |
Özel bir derleme ekibiniz var mı? Yazılım mühendisleriniz derlemeyi mi yönetiyor? Özel bir ekip, mühendisler yeni sürümleri kullanmadan önce derlemenin düzgün çalıştığından emin olmak için genellikle yükseltme risklerini analiz etmeye ve yeni sürümleri test etmeye daha fazla zaman ayırabilir. |
Yükseltme türü |
Bazı yükseltmeler diğerlerinden daha önemlidir. Sizin için en önemli olanları düşünün. Gradle ve Gradle eklentileri gibi araç yükseltmeleri genellikle kullanıcılarınız üzerinde daha az etkiye sahiptir ve riskin çoğu derlemenizdedir. Derleme işleminin kendisi bu değişikliklerin doğrulanmasına yardımcı olur. Kitaplık ve SDK yükseltmelerinin doğrulanması daha zordur ve kullanıcılarınız için daha yüksek risk teşkil eder. Android Gradle Eklentisi (AGP): Android uygulamanızı veya kitaplığınızı derlemek için kullanılan araç. Bu, genellikle performans iyileştirmelerini, hata düzeltmelerini, yeni lint kurallarını ve yeni Android platformu sürümlerini desteklemeyi sağladığı için yapabileceğiniz en kritik yükseltmedir. Gradle: AGP veya başka bir Gradle eklentisini yükselttiğinizde genellikle Gradle'ı yükseltmeniz gerekir. Diğer Gradle eklentileri: Bazen Gradle'ın eklenti API'si değişir. Gradle'ı yeni sürüme geçirirken, kullandığınız eklentilerde yapılan yükseltme olup olmadığını kontrol edin. Kotlin ve Java: Bazı kitaplıklar ve eklentiler için Kotlin veya Java'nın minimum sürümleri gerekir ya da yeni dil özelliklerinden, API'lerden veya performans iyileştirmelerinden yararlanmak istersiniz. Android Platformu: Play Store, düzenli olarak Android SDK'sını yükseltmenizi gerektirir. Android SDK'nın yeni sürümlerini en kısa sürede test etmeniz gerekir. Bazı SDK yükseltmeleri, uygulamanızda yeni izinler veya yeni API'lerin kullanılması gibi değişiklikler yapılmasını gerektirir. Kitaplıklar: Kitaplıklara genel mimarinize olan yakınlıklarına göre öncelik vermek istiyor musunuz?
Android Studio: Android Studio'yu güncel tutarak temel IntelliJ IDEA platformundaki en son özelliklere ve hata düzeltmelerine ve en son Android SDK'larıyla çalışmak için araçlara erişebilirsiniz. |
Kullanılabilir araçlar |
Yükseltme işlemlerinize yardımcı olacak birçok araç ve eklenti vardır. Dependabot ve Renovate gibi araçlar, derlemenizdeki kitaplık sürümlerini otomatik olarak yükseltir ancak riskleri kontrol etmek için sonuçları analiz ettiğinizden emin olun. |
Belirli yükseltme türleri için stratejiler
Bazı bağımlılık türlerini yükseltmenin kademeli bir etkisi olabilir ve diğer bağımlılık türlerinin yükseltilmesini gerektirebilir. Araç ve kitaplık bağımlılıklarını inceleyerek derleme öğeleri arasındaki ilişkileri ele alıyoruz.
Her bileşen türünü yükseltirken yükseltmenin derlemedeki diğer bileşenleri nasıl etkilediğini göz önünde bulundurun.
Android Gradle eklentisi (AGP) |
Android Studio, bu görevlerde size yardımcı olabilecek bir AGP yükseltme asistanı içerir. Asistanı kullanıyorsanız veya yükseltmeyi manuel olarak gerçekleştiriyorsanız aşağıdakileri göz önünde bulundurun: AGP sürüm notlarına bakın. Gradle'ı en az listedeki sürüme yükseltin. Android Studio'yu, seçilen AGP sürümünü destekleyen bir sürüme yükseltin. Kullanmak istediğiniz Android SDK'sını destekleyen Android Studio ve AGP sürümlerini kullanın. SDK Build Tools, NDK ve JDK ile uyumluluğu kontrol edin. AGP'deki verileri genişleten veya kullanan bir Gradle eklentisi (dahili veya herkese açık kullanım için) geliştiriyorsanız eklentinizi yükseltmeniz gerekip gerekmediğini kontrol edin. Bazen AGP, API'leri desteği sonlandırıp daha sonra kaldırır. Bu da önceki eklentilerle uyumsuzluklara neden olur. |
Kotlin derleyicisi, dili ve çalışma zamanı |
Bilinen sorunlar ve uyumsuzluklar için Kotlin sürüm notlarına göz atın. Jetpack Compose'u kullanıyorsanız:
Kotlin Sembolü İşleme (KSP) kullanıyorsanız kurulum için KSP Hızlı Başlangıç Kılavuzu'na, mevcut sürümler için ise KSP Sürümleri'ne bakın. Kotlin sürümüyle eşleşen bir KSP sürümü kullanmanız gerektiğini unutmayın. Örneğin, Kotlin 2.0.21 sürümünü kullanıyorsanız KSP eklentisinin 2.0.21 ile başlayan herhangi bir sürümünü (2.0.21-1.0.25 gibi) kullanabilirsiniz. Genellikle KSP işlemcilerini (ör. derleme dosyalarınızda Kullandığınız diğer tüm Kotlin derleyici eklentilerini yükseltin. Kotlin Compiler Plugin API, sürümler arasında sık sık değişir ve eklentiler uyumlu bir API kullanmalıdır. Eklenti, Derleyici eklentileri listesinde listeleniyorsa Kotlin derleyicisiyle aynı sürümü kullanmanız gerekir. Diğer derleme eklentilerinin dokümanlarını inceleyerek uygun eşlemeyi bulun. Kotlin derleyicisinin kendisiyle birlikte korunmayan derleyici eklentilerinin, derleyici eklentisi API'sinin stabil hale gelmesini beklerken genellikle yayınlama gecikmeleri yaşandığını unutmayın. Kotlin'i yükseltmeden önce, kullandığınız tüm derleyici eklentilerinin eşleşen yükseltmelerinin mevcut olup olmadığını kontrol edin. Son olarak, Kotlin dili bazen değişir ve bu durumda kodunuzu güncellemeniz gerekir. Bu durum genellikle deneysel özellikleri denediğinizde yaşanır. Kotlin derleyicisini yükselttikten sonra kodunuz düzgün şekilde derlenmiyorsa Kotlin sürüm notlarında dil değişiklikleri veya çalışma zamanı kitaplığıyla ilgili kesinti olup olmadığını kontrol edin. |
Kotlin Derleyici Eklentileri |
Bir Kotlin derleyici eklentisini yükseltmeniz gerekiyorsa kullanılan Kotlin sürümüne yükseltin. Çoğu Kotlin derleyici eklentisi, Kotlin derleyiciyle aynı sürümü kullanır veya Kotlin derleyicinin gerekli sürümüyle başlar. Örneğin, eklenti sürümü 2.0.21-1.0.25 ise Kotlin derleyicisinin 2.0.21 sürümünü kullanmanız gerekir. Kotlin derleyici sürümünü değiştirmek bazen başka değişiklikler gerektirir. |
Kütüphaneler |
Kitaplıklar, derlemenizde en sık yükseltilen bağımlılıktır. Kullanılabilir yükseltmeleri Android Studio düzenleyicisinde veya bazı bağımlılık araçlarını ve eklentilerini kullanıyorsanız görürsünüz. Bazı kitaplıklar, kitaplığın kullanılması için gereken minimum Bazı kitaplıklarda, kullanılacak minimum Kotlin sürümü de belirtilir. Derleme dosyalarınızdaki Kotlin sürümünü en az belirtilen sürüme güncelleyin. |
Gradle |
Bazen Gradle'ın yeni sürümleri mevcut API'leri kullanımdan kaldırarak gelecekteki bir sürümde bu API'leri kaldırır. Gradle eklentisi geliştiriyorsanız özellikle herkese açıksa eklentinizi en kısa sürede yükseltin. Bazı Gradle yükseltmelerinde, kullandığınız eklentilerin yeni sürümlerini bulmanız gerekir. Bu eklentiler, en son Gradle eklenti API'leriyle eşleşecek şekilde yükseltilirken geliştirmelerinde gecikme yaşanabileceğini unutmayın. Gradle'ı yükseltmek için:
|
Gradle eklentileri |
Yükseltilen Gradle eklentileri bazen yeni veya değiştirilmiş Gradle API'leri kullanır. Bu da Gradle yükseltmesi veya derleme dosyalarınızdaki yapılandırmalarında değişiklik yapılmasını gerektirir. Her iki durumda da, uyumsuzluğu belirten derleme uyarıları veya hataları görürsünüz. Eklentileri yükseltirken Gradle'i de yükseltin. |
Android SDK |
Android Studio, bu görevlerde size yardımcı olabilecek bir Android SDK yükseltme asistanı içerir. Asistanı kullanıyorsanız veya yükseltmeyi manuel olarak gerçekleştiriyorsanız aşağıdakileri göz önünde bulundurun: Android SDK'sının her sürümü yeni özellikler ve API'ler, hata düzeltmeleri ve davranış değişiklikleri içerir. Play Store, Android SDK'sını yükseltmeden önce sürüm notlarını dikkatlice okuyun. Aşağıdakileri içeren davranış değişiklikleri bölümüne dikkat edin:
Davranış değişiklikleri bölümü oldukça uzun olabilir ancak genellikle uygulamanızda yapmanız gereken kritik değişiklikleri içerdiğinden bu bölüme dikkatlice bakın. Play Store şartlarını karşılamak için Geliştirme sırasında yeni SDK özelliklerinden yararlanmak ve derleme sırasında uyumluluğu sağlamak için Android Gradle eklentisini (AGP) ve Android Studio'yu yükseltin. Bunlar arasında yeni SDK'lar için yeni ve iyileştirilmiş araçlar da bulunmaktadır. Android API düzeyi için araçların minimum sürümleri başlıklı makaleyi inceleyin. Android SDK'yı yeni sürüme geçirirken, kullandığınız tüm AndroidX kitaplıklarını yeni sürüme geçirin. AndroidX, Android SDK sürümleri arasında daha iyi uyumluluk ve performans için genellikle yeni ve güncellenmiş API'leri kullanır. |
Android Studio |
Genellikle Android Studio'yu istediğiniz zaman yükseltebilirsiniz. AGP'yi veya Android SDK'yı yükseltmenizi isteyen mesajlar görebilirsiniz. Bu yükseltmeler kesinlikle önerilir ancak zorunlu değildir. Daha sonra AGP'yi veya Android SDK'sını yükseltmek için Android Studio'yu kullanmak isterseniz Araçlar menüsünde şu seçenekleri bulabilirsiniz: |
Java |
Android uygulamanızda Java kaynak kodunuz varsa daha yeni Java API'lerinden yararlanabilirsiniz. Her Android SDK sürümü, Java API'lerinin bir alt kümesini ve dil özelliklerini destekler. AGP, şekerleme kaldırma adı verilen bir işlem kullanarak daha eski Android SDK sürümleriyle uyumluluk sağlar. Android SDK sürüm notlarında, hangi Java düzeyinin desteklendiğini ve olası sorunları belirtir. Kotlin aynı Java API'lerine erişebildiğinden bu sorunlardan bazıları Kotlin kaynak kodunu da etkileyebilir. Java kaynak kodunuz olmasa bile sürüm notlarının davranış değişiklikleri bölümünde görünen JDK API bölümlerine dikkat edin. JDK kullanımı, derleme komut dosyalarınızdaki çeşitli yerlerde belirtilir. Daha fazla bilgi için Android derlemesindeki Java sürümleri başlıklı makaleyi inceleyin. |
Yükseltme analizi
Bir bağımlılığı yükseltmek, API ve davranış değişiklikleri, yeni kullanım şartları, yeni güvenlik sorunları ve hatta lisans değişiklikleri şeklinde riskler doğurabilir. Örneğin, şunları yapmanız gerekiyor mu:
- API değişiklikleri için kodu değiştirmeli miyim?
- Yeni izin kontrolleri eklemek istiyor musunuz?
- Davranış değişiklikleri için ek testler oluşturmalı mısınız yoksa mevcut testleri değiştirmeli misiniz?
Yükselttiğiniz bağımlılık, kendi bağımlılıklarının sürümlerini de yükseltmiş olabilir. Bu, kısa sürede çok sayıda değişiklik yapılmasına neden olabilir.
Yükseltmelerinizi otomatikleştirmek için Renovate veya Dependabot gibi bir araç kullanıyorsanız bu araçların sizin için analiz yapmayacağını unutmayın. Bu araçlar, en yeni kitaplık sürümlerine yükseltilir. Bu tür otomatik yükseltmelerden sonra her şeyin düzgün çalışacağını varsaymayın.
Yükseltmelerin başarılı olması için yükseltme analizi önemlidir:
- Yükseltme işleminizden önceki ve sonraki bağımlılık farklılıklarını belirleyin.
- Her değişikliği inceleyin ve ilgili riskleri belirleyin.
- Riskleri azaltın veya değişiklikleri kabul edin ya da reddedin.
Bağımlılık farklarını belirleme
Yükseltme analizinizdeki ilk adım, bağımlılıklarınızın nasıl değiştiğini belirlemektir. Değişiklikleri hızlıca görmek için sürüm kontrolünden (Git gibi VCS) ve DependencyGuard eklentisinden yararlanın. Amacınız, önce ve sonra anlık görüntü oluşturmak ve bunları karşılaştırmaktır.
İlk temel çizginizi belirleyin ve oluşturun
Yükseltme işleminizi başlatmadan önce projenizin başarıyla derlendiğinden emin olun.
İdeal olarak, mümkün olduğunca fazla uyarıyı çözmeli veya daha önce gördüğünüz uyarıları izlemek için temel değerler oluşturmalısınız.
- Lint: Mevcut lint uyarılarınızı inceleyin ve bir Android lint referans değeri oluşturun.
- Kotlin derleyicisi:
- Tüm uyarıları hata olarak ele almak için
-Werror
öğesini etkinleştirin. Seçenekleri tanımlama bölümüne bakın. - Kotlin Warning Baseline veya Kotlin Warnings Baseline Generator gibi eklentileri kullanabilirsiniz.
- Tüm uyarıları hata olarak ele almak için
- Diğer araçlar: Referans izlemeyi destekleyen başka statik analiz araçları (ör. Detekt) kullanıyorsanız referans noktalarını ayarlayın.
Bu uyarı referansları, bağımlılıklarınızı yükselttikçe kullanıma sunulan yeni uyarıları görmenizi kolaylaştırır.
Dependency Guard'ı kurup çalıştırarak bir bağımlılık temel çizgisi oluşturun. gradle/libs.versions.toml sürüm kataloğunuza şunları ekleyin:
[versions]
dependencyGuard = "0.5.0"
[plugins]
dependency-guard = { id = "com.dropbox.dependency-guard", version.ref = "dependencyGuard" }
Sonra da uygulamanızın derleme dosyasına şunu ekleyin:
Kotlin
plugins { alias(libs.plugins.dependency.guard) } dependencyGuard { configuration("releaseRuntimeClasspath") }
Eski
plugins { alias(libs.plugins.dependency.guard) } dependencyGuard { configuration('releaseRuntimeClasspath') }
releaseRuntimeClasspath
yapılandırması olası bir hedeftir ancak farklı bir yapılandırma kullanmak istiyorsanız mevcut tüm yapılandırmaları görmek için derleme dosyanızda listelenen bir yapılandırma olmadan ./gradlew dependencyGuard
'ı çalıştırın.
Kurulumdan sonra, app/dependencies/releaseRuntimeClasspath.txt
dosyasında rapor oluşturmak için ./gradlew dependencyGuard
dosyasını çalıştırın. Bu sizin temel raporunuzdur.
Kaydetmek için bunu sürüm kontrol sisteminize (VCS) gönderin.
Bağımlılık Koruyucu'nun yalnızca kitaplık bağımlılıklarının listesini yakaladığını unutmayın. Derleme dosyalarınızda Android SDK'sı ve JDK sürümleri gibi başka bağımlılıklar da vardır. Bağımlılık değişikliklerinizden önce VCS'nize commit yaptığınızda VCS karşılaştırma aracınız bu değişiklikleri de vurgular.
Yükseltme ve referans değerle karşılaştırma
Bir temel oluşturduktan sonra bağımlılıkları ve test etmek istediğiniz diğer derleme değişikliklerini yükseltin. Bu aşamada kaynak kodunuzu veya kaynaklarınızı yükseltmeyin.
Yeni lint uyarılarını veya hatalarını görmek için ./gradlew lint
'ü çalıştırın. Önemli sorunları giderin ve ardından ./gradlew lint
-Dlint.baselines.continue=true
'ü çalıştırarak uyarı referans değerinizi güncelleyin. Uyarı referans değerlerini yakalamak için Kotlin Warning Baseline veya Kotlin Warnings Baseline Generator gibi başka araçlar kullandıysanız yeni uyarıları ele alın ve referans değerlerini de güncelleyin.
Referans raporunuzu güncellemek için ./gradlew dependencyGuard
komutunu çalıştırın. Ardından, kitaplık dışındaki değişiklikleri görmek için VCS karşılaştırmanızı çalıştırın. Bu sürüm, sandığınızdan çok daha fazla kitaplık yükseltmesi içerebilir.
Riskleri analiz etme
Nelerin değiştiğini öğrendikten sonra, yükseltilen her kitaplığın olası risklerini göz önünde bulundurun. Bu sayede, testinize odaklanabilir veya değişiklikleri daha ayrıntılı bir şekilde inceleyebilirsiniz. Analizin tutarlı olmasını sağlamak amacıyla projeniz için analiz edilecek bir dizi risk tanımlayın.
Göz önünde bulundurulması gereken bazı noktalar:
Ana sürüm yükseltmeleri |
Ana sürüm numarası değişti mi? Bu mesajı gördüğünüzde, aşağıdaki hususlardan herhangi birini incelerken etkilenen kitaplıklara özellikle dikkat edin. Kodunuzda deneysel API'ler kullanılıyorsa (genellikle ek açıklamaları veya derleme dosyası özelliklerini etkinleştirmenizi gerektirir) 1.2.3'ten 1.3.1'e veya 1.2.3'ten 1.2.5'e geçme gibi küçük veya yama sürümü değişiklikleri bile ek riskler oluşturabilir. |
Kararsız API |
Bazı kitaplık sürümleri kararsız API'ler içerebilir. Bunlar genellikle devam eden veya kararsız başka bir API'ye bağlı olan API'lerdir. Genellikle alfa, geliştirici veya deneme sürümleri gibi önizlemelerle sınırlı olsa da bazı kitaplıklarda deneme veya kararsız olarak işaretlenmiş API'ler bulunur. Mümkünse bu tür API'lerden kaçının. Bu özellikleri kullanmanız gerekiyorsa kullanımınızı kaydettiğinizden ve sonraki sürümlerde değişiklikler veya kaldırmalar olup olmadığına dikkat ettiğinizden emin olun. |
Dinamik davranış |
Bazı kitaplıklar harici faktörlere göre farklı şekilde davranır. Örneğin, bir sunucuyla iletişim kuran bir kitaplık, söz konusu sunucudaki değişikliklere bağlıdır.
|
Manifest birleştirme |
Android Arşivi (AAR) olarak yayınlanan kitaplıklar, uygulamanızla birleştirilen kaynaklar ve manifestler içerebilir. Bunlar, yeni izinler ve dolaylı olarak çalışan etkinlikler veya yayın alıcıları gibi Android bileşenleri ekleyebilir. |
Çalışma zamanı güncellemeleri |
Bazı kitaplıklar, uygulamanızın kontrolü dışında güncellenebilen özellikler kullanır. Bir kitaplık, Android SDK'sından bağımsız olarak yükseltilen Play Hizmetleri'ni kullanabilir. Diğer kitaplıklar, bağımsız olarak güncellenen harici uygulamalardaki hizmetlere bağlanabilir (genellikle AIDL kullanılır). |
Kaç sürümü atlıyorsunuz? |
Bir kitaplığı yükseltmek için ne kadar uzun süre beklerseniz o kadar fazla riskle karşılaşabilirsiniz. 1.2.3'ten 1.34.5'e gibi önemli bir sürüm değişikliği görüyorsanız bu kitaplığa daha fazla dikkat edin. |
Taşıma kılavuzları |
Kitaplığın taşıma kılavuzu olup olmadığını kontrol edin. Bu sayede risk analizinizi ve azaltma planınızı önemli ölçüde azaltabilirsiniz. Bu tür bir kılavuzun bulunması, geliştiricinin uyumluluğu göz önünde bulundurduğu ve yükseltmeyle ilgili endişelerinizi dikkate aldığına dair iyi bir göstergedir. |
Sürüm notları |
Değiştirilen her kitaplık için sürüm notlarına (sağlanmışsa) bakın. Önemli değişiklikler veya yeni şartlar (ör. eklenen izinler) olup olmadığını kontrol edin. |
BENİOKU ANLARI |
Özellikle kitaplıkta sürüm notları sağlanmıyorsa kitaplıkla ilgili bazı README dosyalarında olası riskler belirtilir. Özellikle bilinen güvenlik sorunlarını içeren _bilinen sorunları_ arayın. |
Bilinen güvenlik açıklarını kontrol etme |
Play SDK Dizini, birçok popüler SDK'nın güvenlik açıklarını takip eder. Play Console, bilinen güvenlik açıklarına sahip listelenen SDK'lardan birini kullanıp kullanmadığınızı bildirir. Android Studio'da derleme dosyaları düzenlenirken IDE, SDK dizini kontrol eder ve güvenlik açığı bulunan kitaplık sürümlerinin kullanımını işaretler. Ulusal Standartlar ve Teknoloji Enstitüsü (NIST), büyük bir Ulusal Güvenlik Açığı Veritabanı (NVD)'nı yönetir. Bağımlılık Kontrolü Gradle eklentisi, kullandığınız bağımlılıkları NVD ile karşılaştırarak kontrol eder. Bağımlılık Kontrolü'nü kullanmak için bir NVD API anahtarı isteyin, Gradle eklentisini ayarlayın ve |
Sürüm çakışmaları |
Sürümler beklendiği gibi çözülebiliyor mu? Özellikle büyük sürüm farklılıkları olmak üzere çakışmaları arayın. Çakışmaları nasıl arayacağınızla ilgili ayrıntılar için Gradle bağımlılık çözümü bölümüne bakın. Özellikle Mümkün olduğunda bir bağımlılığın yazarlarıyla birlikte çalışarak bunların bağımlılıklarını ortaya çıkarın. Şirketiniz izin veriyorsa kitaplığın uyumluluğunu iyileştirmeye yardımcı olmak için kitaplığa (yukarı akış) yapılan değişikliklere katkıda bulunun. |
Lisansları kontrol etme |
Kitaplığınızı yükseltirken lisanslarda değişiklik olup olmadığına bakın. Kitaplığın kendisi, artık uygulamanız veya kitaplığınızla uyumlu olmayan bir lisansla değiştirilebilir. Yeni geçişli bağımlılıklar, uyumlu olmayan lisanslar da getirebilir. Bağımlılıklarınızdaki mevcut lisans grubunu kontrol etmeyle ilgili ayrıntılar için Lisansları doğrulama başlıklı makaleyi inceleyin. |
Bakım ve |
Herkese açık depoları olan kütüphaneler için:
|
Açık kaynak ve kapalı kaynak |
Kitaplık açık kaynaksa, sorunlar kodunuzda veya kitaplık kodunuzda olabilir, ancak kapalı kaynakta hata ayıklamak daha kolay olacaktır. Kapalı kaynak bağımlılıkları en aza indirin ve değerlendirme sırasında ek inceleme yapın. Kullanım alanınıza uygun iyi alternatifler var mı? Kapalı kaynak kitaplıklar için hangi hizmet düzeyi sözleşmeleri kullanılabilir? Kapalı kaynaklı bir bağımlılık kullanmayı seçerseniz riskleri sınırlandırmaya yardımcı olmak için ek test örnekleri yazmaya hazır olun. |
Derleme çalıştırma
Projenizi oluşturun. Yeni hata veya uyarı olup olmadığını kontrol edin. Bu hatalara hangi kitaplığın neden olduğunu belirleyebiliyorsanız bu kitaplığı yükseltme riski olarak not edin.
Yeni değer düşüşü uyarıları görürseniz bunları, bunları üreten kitaplık için belirli riskler olarak ekleyin. Bunlar, sonraki sürümlerde kaldırılabilir. Söz konusu kitaplığı kullanmaya devam etmek istiyorsanız kullanımdan kaldırılan API'leri kullanmayı, bunların yerine geçen API'lere dönüştürmek için zaman ayırın veya bu işlevleri ve daha sonra kaldırılıp kaldırılmayacaklarını takip etmek için kullanımdan kaldırılan API'leri not edin.
API sorunlarını tespit etmek için lint'i kullanma
Android lint, bağımlılıkların veya Android SDK'nın değiştirilmesinden kaynaklananlar dahil olmak üzere uygulamanızdaki birçok sorunu yakalayabilir. Örneğin, compileSdk
'inizi yükseltirseniz ve yeni API'lerini kullanırsanız lint, önceki SDK sürümlerinde bulunmayan API'leri raporlar.
Lint, Android Studio düzenleyicisinde çalışır ve siz değişiklik yaparken sorunları bildirir.
Ancak build
veya lint
hedeflerini kullanmadığınız sürece normalde Studio'da derlemenizin bir parçası olarak veya bir komut satırı derlemesi çalıştırdığınızda çalıştırılmaz.
Sürekli Entegrasyon (CI) kullanıyorsanız bu tür hataları yakalamak için CI derlemelerinizde (veya en azından gecelik derlemelerinizde) gradlew
build
veya gradlew lint
'i çalıştırın.
CI kullanmıyorsanız en azından ara sıra gradlew lint
çalıştırdığınızdan emin olun.
Özellikle lint hatalarına ve uyarılarına dikkat edin. Bazı kitaplıklar, API'lerinin doğru şekilde kullanılmasını sağlamak için kendi lint kontrolleriyle birlikte gönderilir. Bir kitaplığın bazı yeni sürümlerinde yeni lint uyarıları ve hataları bulunur. Bu da derleme yaparken yeni raporlara neden olur.
Riskleri azaltma
Yükseltme risklerini belirledikten sonra bunları nasıl azaltacağınıza karar verin:
- Bazı riskleri olduğu gibi kabul edin. Özellikle yükseltme süresi ve kaynakları sınırlı olduğunda bazı riskler kabul edilebilir düzeydedir.
- Bazı riskleri tamamen reddedin. Bazı yükseltmeler, özellikle de bu aşamada bunları azaltacak sınırlı zamanınız veya kaynaklarınız varsa çok riskli görünebilir. Önceliklendirme yapmanız gerekiyorsa karşılaştığınız hatalar veya ihtiyacınız olan yeni özellikler için gerekli olan yükseltmelere odaklanın.
- Kalan riskleri azaltın
- Yükseltmelerinizi daha küçük ve bağımsız değişiklik gruplarına ayırabilirsiniz. Bu, genel riski azaltır ve geri çekmenin bir kısmını sağlar.
- Değişiklikleri ayrıntılı olarak inceleyin.
- Beklenmedik değişiklikler olup olmadığını kontrol etmek için uygulamanızı test edin. Yükseltme işlemine güven duymak için gerektiğinde yeni testler ekleyin.
- Şüpheli bir şey bulunduğunda (varsa) kaynağa bakın.
- Kaynağınızda veya derlemenizde gerekli değişiklikleri yapın.
Kararlarınızı belgeleyin. Uygulamanız çalıştırılırken yükseltmeden kaynaklanan riskler sorun haline gelirse risk analizinizin belgeleri gerekli hata analizini azaltabilir.
Lisansları doğrulama
Kitaplık geliştiricileri, kitaplıkları sizin kullanabileceğiniz şekilde lisanslar. Lisans şartlarına uymanız gerekir. Aksi takdirde kitaplığı kullanamazsınız. Bazı lisanslar çok izin vericidir ve genellikle yalnızca kitaplığın ilişkilendirilmesini ve lisansının metninin son kullanıcılara gösterilmesini gerektirir. Bazıları viral olarak kabul edilir. Bu kitaplıkları kullanıyorsanız uygulamanıza veya kitaplığınıza aynı lisansı uygulamanız gerekir.
Lisanslar, herhangi bir sürümle birlikte değişebilir. Yeni sürüme her geçiş yaptığınızda, kullandığınız bağımlılıkların uygulamanız veya kitaplığınızla uyumlu bir şekilde lisanslandığını doğrulamanız gerekir.
Uyumlu olmayan (veya uyumluluğu kaldırılmış) lisanslar kitaplığın ilgili sürümünü kullanamaz. Buradan:
- Kitaplık sahibiyle iletişime geçin ve eski lisansa izin vermeye devam etmek için mevcut lisansın devam ettirilmesini veya çift lisanslama yapılmasını isteyin.
- Lisansınızı uyumlu olacak şekilde değiştirip değiştiremeyeceğinizi belirlemek için hukuk ekibinizle birlikte çalışın.
- Uyumlu lisansa sahip başka bir kitaplık bulun ve uygulamanızı gerektiği gibi değiştirin.
- Kitaplığın en son uyumlu sürümünü çatallayın (lisans, türevlere izin veriyorsa ve değişiklikler geriye dönük değilse) ve kendi değişikliklerinizi yapın.