Google Android geliştirmenin mahkûmları

 (solutional.ee)
2 puan yazan GN⁺ 2023-08-28 | 1 yorum | WhatsApp'ta paylaş
  • Eski bir Android uygulamasının targetSdkVersion değerini Google’ın gereksinimlerine uygun şekilde yükseltmeye yönelik küçük bir bakım işi, Android 13’te üretim çökmesine ve Google Play’de uzun inceleme bekleme süresine dönüştü
  • Mevcut uygulamanın daha yüksek Android sürümüne sahip cihaz kullanıcılarına sunulmaya devam edebilmesi için API level 31 ve üzerini hedeflemesi gerekiyordu; yazar da uygulamayı API level 30’dan 33’e yükseltip yayımladı
  • İlk sürüm 1 saat içinde onaylandı, ancak gerçek Android 13 cihazlarında girişten hemen sonra çökme yaşandı ve önceki sorunsuz sürüme geri dönmenin bir yolu yoktu
  • Düzeltme derlemesi kod değişikliğinin hemen ardından gönderildi, ancak yaklaşık 72 saat boyunca inceleme kuyruğunda kaldı; ardından ancak 4 Eylül’de, 11 gün sonra üretime alındı
  • Yerel mobil uygulamalarda kaynak kodu ve altyapıyı doğrudan siz işletseniz bile, son dağıtım kanalını uygulama mağazası işletmecileri kontrol ettiği için acil düzeltme, geri alma ve dağıtım hızı açısından kısıtlamalar oluşuyor

Küçük bir SDK güncellemesi nasıl üretim olayına dönüştü

  • Bakım yapılan şey, müşterinin kullandığı eski bir Android uygulamasıydı
    • İşlevleri yıllar önce tamamlanmıştı ve aktif olarak geliştirilen bir uygulama değildi
    • İdeal durumda kararlı sürümü olduğu gibi bırakmak isteniyordu
  • Google, 18 Ağustos 2023’te bir e-postayla Android API seviyesi gereksinimlerini bildirdi
  • Google’ın mesajının özü, mevcut uygulamanın daha yüksek Android sürümüne sahip cihaz kullanıcılarına sunulmaya devam edebilmesi için API level 31 veya üzerini hedeflemesi gerektiğiydi
  • Bunun halihazırda yüklü uygulamalar üzerindeki etkisi tam olarak açık değildi; daha güvenli yorum doğrultusunda güncelleme önceliklendirildi
  • Son tarihe 3 haftadan az kalmıştı ve Google bu gereksinim için daha erken bir hatırlatma göndermemişti

targetSdkVersion 30’dan 33’e geçiş

  • Çalışma 23 Ağustos’ta başladı ve uygulamanın targetSdkVersion değeri API level 30’dan 33’e çıkarıldı
  • İlk derleme, uyumsuz bir analiz bağımlılığı nedeniyle başarısız oldu
    • Bu bağımlılık iş mantığıyla yakından ilişkili değildi, bu yüzden kaldırılabildi
  • Ardından uygulama Android emülatöründe çalıştırıldı ve temel işlevler önceki gibi çalışıyor görünüyordu
  • Bu değişiklik, yeni bir iş değeri üretmeyen bir politika uyum güncellemesiydi

İlk Google Play dağıtımı ve Android 13 çökmesi

  • Google Play’e dağıtım süreci ilk başta sorunsuz ilerledi
    • Eski uygulama yılda yalnızca bir ya da iki kez güncellendiği için çeşitli anketlerin doldurulması gerekti
    • Sürüm 1 saat içinde incelemeden geçip üretime dağıtıldı
  • Aynı akşam yaklaşık 21:30’da, müşterinin yeni uygulama sürümünde kullanıcıların giriş yapamadığını bildirmesiyle sorun ortaya çıktı
  • Gerçek bir Android cihazda test edildiğinde uygulama girişten hemen sonra çöküyordu
  • Ek incelemede sorunun o dönemdeki en güncel Android sürümü olan Android 13 üzerinde ortaya çıktığı, önceki sürümlerin ise normal çalıştığı görüldü
  • İlk çalışmada yalnızca eski emülatör imajları test edildiği için uyumluluk sorunu ortaya çıkmamıştı
  • Birden fazla Android sürümü test edilseydi sorun yakalanabilirdi
    • Değişiklik kapsamının küçük olması ve son tarih baskısı yanlış bir güven oluşturdu, ancak test kapsamının yetersizliği ekibin hatasıydı

Geri almayı engelleyen dağıtım yapısı

  • En güvenli ilk tepki, önceki sorunsuz sürümü geri yükleyip çökme sorununu bir sonraki çalışma saatinde araştırmak olurdu, ancak Google Play’de bu seçenek yoktu
  • En son üretim sürümünü geri çekip önceki sürümü yeniden etkinleştirmenin bir yolu bulunmuyordu
  • Sonraki seçenek olarak targetSdkVersion değerini 30’a geri çekip uygulama sürümünü artırarak yeni bir derleme yayımlamak istediler, ancak Google Play bunu reddetti
    • Yayımlanan yönerge, 1 Eylül’e kadar daha düşük hedefe izin veriliyor gibi görünse de, yeni güncellemenin API level 33’ü hedeflemesi gerektiğini söyleyen bir hata alındı
  • API level 30 için 1 Kasım’a kadar uzatma talep edildi, ancak yayımlama hatası devam etti
  • Geriye kalan tek olası yol, Android 13 çökmesini düzeltip yeni bir sürüm göndermekti

Baskı altında düzeltme ve uzun inceleme bekleyişi

  • Bozuk sürüm otomatik güncellemeler yoluyla kullanıcılara kademeli olarak ulaşıyordu ve düzeltme derlemesi ne kadar hızlı üretime çıkarsa etkilenen müşteri sayısı o kadar azalacaktı
  • Çökme Android 13 emülatöründe yeniden üretilebiliyordu ve gerekli kod değişikliği büyük değildi
  • Ancak iş geç saatlerde ve baskı altında yürütülmek zorundaydı; kapsamlı regresyon testi için zaman sınırlıydı
  • O andaki plan daha çok pratik bir müdahaleydi
    • Bilinen tüm çökmeleri düzelt
    • En kritik akışları test et
    • Düzeltme sürümünü hemen gönder
    • Daha geniş testlere devam et ve gerekirse ek güncellemeler hazırla
  • Yeni derleme Google Play’e gönderildi, ancak 2 saat geçmesine rağmen hâlâ inceleme kuyruğundaydı ve yaklaşık 01:00’de de onaylanmamıştı
  • Ertesi sabah da uygulama hâlâ in review durumundaydı
  • Günün büyük kısmı Android 13 testi yapmak ve Google Play Console’u kontrol etmekle geçti; giriş çökmesi kadar ciddi olmayan birkaç küçük sorun bulunup düzeltildi
  • Gün sona erdiğinde bile üretim düzeltmesi onaylanmamıştı
  • O sırada düzeltme derlemesi yaklaşık 72 saat boyunca beklemedeydi; kod düzeltilmişti ama dağıtım görünmez bir inceleme kuyruğuna takılmıştı

Sonraki güncellemeler: inceleme, destek sohbeti, kademeli dağıtım

  • 27 Ağustos’ta Hacker News’e bir yazı gönderildi ve tartışmada Android sürüm stratejileri ile eleştiriler birlikte yer aldı
    • Yazı ana sayfaya çıktı ve birkaç gün içinde yaklaşık 130 bin tekil ziyaretçi aldı
    • Aylık yaklaşık 5 € maliyetli bir VPS üzerinde çalışan statik site bu trafiği kaldırdı
    • Bu ilgi Google’dan bir yanıt getirmedi ve uygulama güncellemesi incelemede kalmaya devam etti
  • 1 Eylül’de Google Play Console’daki soru işareti simgesinin arkasında destek sohbeti olduğu fark edildi
    • Destek görevlisi incelemeyi hızlandıracaklarını söyledi, ancak net bir takvim ya da çözüm sunmadı
    • Büyük Hacker News tartışmasında kimsenin bu yolu anmamış olması dikkat çekiciydi
    • Bunun nedeni, Google desteğine erişmenin zor olduğuna dair itibar yüzünden geliştiricilerin doğrudan yardım beklememesi olabilir
  • 4 Eylül’de düzeltme güncellemesi, 11 günlük incelemenin ardından nihayet yayımlandı
  • Ardından hemen kullanıcıların %100’üne dağıtmak yerine, kademeli dağıtım kullanan daha küçük bir takip sürümü gönderildi ve bu güncelleme 1 saat içinde incelemeyi geçti
  • 7 Eylül’de kullanıcıların %99,9999’una ulaşmış sürümün yerini almak için bir küçük güncelleme daha gönderildi
    • Yeni sürüm incelemeye girer girmez Google, önceki dağıtımı uyarı vermeden otomatik olarak durdurdu
    • Yeni inceleme birkaç gün sürseydi, kalan kullanıcılara önceki sürüm de sunulamayacaktı
    • Yeni gönderim geri çekilse bile önceki dağıtım geri yüklenmedi
    • Neyse ki bu inceleme 1 saat içinde tamamlandı

Platform kontrolünün değiştirdiği üretim sorumluluğu

  • Mobil geliştiriciler, Google ya da Apple’ın acil üretim düzeltmelerini geciktirdiği, uygulamaları kaldırdığı ya da kararları için neredeyse hiç açıklama sunmadığı benzer birçok durum yaşadı
  • Teknik ekipler hataları hızla teşhis edip düzeltebilse bile, kullanıcıların çözüme ne zaman ulaşacağını uygulama mağazası işletmecileri belirliyor
  • Sıradan kullanıcıya yönelik uygulamalarda güvenilir bir geri alma seçeneği, alternatif dağıtım kanalı ya da incelemeyi hızlandırmanın güvenilir bir yolu olmayabilir
  • Kaynak koduna ve altyapıya sahip olsanız bile, son dağıtım kanalını kontrol edemiyorsanız üretim sahipliğinin niteliği değişiyor
  • Yerel mobil uygulama zorunlu değilse, açık web platformunu tercih etmek için nedenler artıyor
    • Web uygulamaları çoğu durumda gerekli işlevleri sağlarken dağıtım, izleme ve geri alma işlemlerinin doğrudan ekip tarafından yapılmasına olanak tanıyor
  • Yerel uygulamalar için de geçerli kullanım alanları var
    • Cihaz özelliklerine bağımlılık
    • Arka plan çalışması
    • Uygulama mağazası dağıtımının gerekli olması
  • Mobili seçmek, ürün avantajlarının yanında güçlü bir üçüncü tarafın sürüm sürecine girmesinin getirdiği operasyonel maliyeti de kabul etmek anlamına geliyor

İlgili okumalar

1 yorum

 
GN⁺ 2023-08-28
Hacker News yorumları

  • Bu e-postayı hem kişisel olarak hem de iş için aldım.
    Kişisel olarak 16 şehrin toplu taşıma sistemleri için gönüllü olarak açık kaynaklı bir uygulama geliştirip işletiyorum; kimseye faydası olmayan bir iş yüzünden 16 uygulamayı 2 hafta içinde güncellemek zorunda kaldım.
    Uygulamam bir PWA; Android sürümü ise Cordova ve birkaç eklentiyle biraz yerel seçenek eklenmiş bir biçimde. Yeni hedef Android API'sini desteklemek için Cordova'yı yükseltince, henüz güncellenmemiş eklentiler bozuldu ve bütün hafta sonu çalışıp test yapmak zorunda kaldım.
    Dürüst olmak gerekirse uygulamayı kaldırıp kullanıcıların web sitesine giderek PWA'yı yüklemesini istiyorum, ama ortalama kullanıcı bunu nasıl yapacağını hâlâ bilmiyor. Kullanıcıların uygulama aradığı ilk yer de hâlâ Play Store. Google'ın PWA'ların doğrudan uygulama mağazasına gönderilmesine izin vermesi bile iyi olurdu; bunu her yıl tekrarlamak istemiyorum.
    İş tarafında da apar topar uğraşıyoruz. Yıl sonuna kadar bazı destek müşterilerimizin kullandığı eski bir uygulama var; oldukça karmaşık bir uygulama olduğu için sadece hedef API sürümünü değiştirmek bile temel testlerde birçok yeri bozdu. Süre uzatımı aldık, ama Google'ı memnun etmek dışında hiçbir işlevsel değişiklik içermeyen bir güncelleme için 1-2 hafta geliştirici zamanı ve 1-2 hafta QA gerekeceğini biliyoruz. Üstelik tüm müşteriler yeni uygulamaya geçince yıl sonunda mağazadan resmen kaldıracağımız bir uygulama olmasına rağmen.

    • Böyle durumlar için Trusted Web Activities (TWA) var. Cordova gibi framework'ler olmadan da PWA'yı Play Store'a koyabilirsiniz.
      https://rangle.io/blog/publishing-a-web-app-to-the-play-stor...
      https://developers.google.com/codelabs/pwa-in-play#0
    • Açık konuşalım: Mesele yalnızca kullanıcıların yöntemi bilmemesi değil. Google ve Apple bunu kendi uygulama mağazalarından uygulama yüklemek kadar kolay hâle getirmediler. Bu bir tercih ve bilinçli bir tercih.
    • Kullanıcıyı yanlış anlamışsınız gibi geliyor. Bu sadece cehalet meselesi değil. Uygulamaların tekrar gerçekten yerel uygulamalara, yani Cordova olmayan yöne dönmesini isterim. Baştan savma yapılmış web tabanlı şeyler değil, iyi yapılmış gerçek bir uygulama deneyimine denk gelen web uygulaması neredeyse yok.
    • Katılıyorum. Benim birkaç kişisel uygulamam da etkilendi.
      Ancak bu son tarih aylardır bildiriliyordu ve bir noktada daha açık biçimde gösterileceği belliydi. Metnin kendisini beğenmedim; ayrıca üretim sürümü uygunken test sürümünün kriteri karşılamadığından şikâyet etmek de mantıklı değildi.
      Ayrıca mesele her zaman yeni bir güncelleme göndermekti ve her yıl böyle oluyor. Uygulamayı bir süre daha yayımlanmış durumda tutmak mümkündü.
      Bu yüzden sadece 2 hafta vardı demek doğru değil.
    • İşe yarar mı bilmiyorum ama benim durumum olsaydı, birkaç uygulama güncellemesi yayımlayıp PWA sürümünün nasıl kurulacağını anlatan bir ekran ekler ve bu sorunlardan kademeli olarak çıkardım. Kullanıcıların yaşadığı zorlukları almak için bir geri bildirim formu da sunulabilir gibi.

  • Android geliştirmenin zorluklarına katılıyorum, ama yazar iki büyük hata yapmış.
    Birincisi, uygulamayı en yeni Android sürümünde test etmemiş. Bu çok büyük bir hata ve desteklediğimiz tüm Android sürümleri için 11 sanal makine tutmamızın nedeni de bu.
    İkincisi, Google Play'de uygulama dağıtırken baştan kullanıcıların %100'üne asla dağıtım yapılmamalı. Kademeli dağıtım varsayılan olmalı; biz bir sürümü yayımladıktan sonra başlangıçta kullanıcıların %10'unu geçmeyiz. Kendimize güvenince %100'e değil, %99'a dağıtırız. Böylece herhangi bir nedenle dağıtımı durdurmanız gerekirse, %100'e dağıtılmadığı sürece kolayca durdurabilirsiniz.
    Beğenin ya da beğenmeyin, bu iki yöntem deneyimli Android geliştiricilerinin iyi bildiği taktiklerdir.

    • Birçok açıdan daha iyi yapılabileceğine katılıyorum. Ama açıkladığım gibi bu, bugünlerde aktif geliştirilen bir uygulama değil, eski bir uygulama; bu yüzden bu kadar sağlam bir QA düzeni kurmak mantıklı değil. Bu uygulama uzun zaman önce başka bir şirket tarafından yazılmış ve basit birim testleri bile yok. Gerçek bu.
      Yine de bu kadar karmaşık bir düzeniniz olsa bile hatalar olur; asıl sorun ise sürümü geri alma, iptal etme ya da rollback yapma yolunun olmaması.
      Bu durumda kademeli dağıtım tüm müşterilere nasıl yardımcı oluyor? Son kullanıcı bozuk sürümü aldığında, düzgün sürümü almasının bir yolu var mı?
    • Bir ipucu: o giriş alanı ondalıklı değerleri de kabul ediyor. Biz her zaman %99.99999999 olarak ayarlıyoruz; böylece yanlışlıkla dışarıda kalan kullanıcı olmuyor. Aynı zamanda dediğiniz gibi dağıtımı iptal etmek mümkün hâle geliyor.
    • Her Android destek sürümü için sanal makine tutmak gerekiyorsa, tamam diyelim; ama o zaman gelirin %30 komisyonu tam olarak ne için alınıyor diye merak ediyorum.
    • Bu biraz mağduru suçlamak gibi hissettiriyor. Bu iki şeyin en başta sorun olmaması gerekirdi.
    • Söyledikleriniz tamamen doğru ve güncelleme ile sürüm yayımlamanın pratikte tek uygulanabilir yolu. Ama API güncellemesi derleniyorsa olduğu gibi çalışacağını bekleyememek üzücü.

  • Orijinal yazarı köşeye sıkıştıran tepkileri anlamıyorum. Elbette daha dikkatli olabilirdi ve giriş yapmayı en yeni Android’de test edebilirdi. Ama ya çökme giriş yaparken olmasaydı? Ya en yeni sürümde çalışıp başka sürümlerde çalışmasaydı? Çizgiyi nereye çekmek gerekir?
    Bir noktada şunu söylemek gerekir: “Bu, kelimenin tam anlamıyla milyonlarca uygulamanın ve milyonlarca geliştiricinin kullandığı bir platform; hatalar olabilir ve kendi dağıtımını durdurmayı ya da kademeli dağıtım gibi püf noktalarını bilmiyor olsan bile, daha önce onaylanmış eski bir sürümü hemen tekrar yayımlamak gibi yollarla kolayca düzeltilebilmesi gerekir.” Özellikle app store gibi yerlerde geri alınabilir ve kurtarılabilir kılmak temel bir tasarım ilkesidir

    • Orijinal yazarı benim; benimle birlikte düşündüğün için teşekkürler. Birçok yanıtta zaten söylediğim gibi, test tarafında daha iyisini yapabileceğime tamamen katılıyorum. Elbette bu alanda her zaman iyileştirme payı var
      Son tarihi Google belirledi ve tekrar söylüyorum, bunu ilk kez 18 Ağustos’ta duydum; öncesinde bilmiyordum. Değişiklik o sırada önemsiz görünüyordu ve uygulama eski Android sürümlerinde eskisi gibi çalıştığı için bunun bu kadar feci şekilde başarısız olacağını öngörmedim
      Deneyimli bir Android geliştiricisi değilim ama genel yazılım geliştirmede 15 yıldan fazla deneyimim var; bu yüzden bir şeyin nasıl çalışacağı, ne beklemem ve nelerden çekinmem gerektiği konusunda kendimce bir sezgim var. En son sürümü kısmen de olsa “geri çekme” olasılığını bırakmak için %99,99999999 kademeli dağıtımın en iyi uygulama olduğunu gerçekten bilmiyordum
      En son sürümü iptal ederek ya da silerek önceki sağlam sürüme dönmenin hiçbir yolu olmadığı gerçeğini aklımın ucundan bile geçirmedim. Böyle durumları ancak yaşayarak öğreniyor insan
      Tüm özellikleri tüm Android sürümlerinde test etmediğim için beni suçlayabilirsiniz; ben de öyle düşünüyorum. Ama lütfen gözünüzü açıp Play Store’un mevcut sürüm yönetme biçiminin, Play Store dışında normal bir insanın tercih edeceği bir yöntem olmadığını anlayın. Herkes bir gün böyle bir sorunla karşılaşabilir; umarım bu yazı ve bu tartışma benzer durumlara düşen geliştirici sayısını azaltır
    • “En yeni sürümde çalışıyordu ama başka sürümlerde çalışmadıysa?” zayıf bir mazeret. Web uygulaması olsa bile farklı tarayıcılarda test etmek gerekir
      Yeni bir sürüm için smoke test yapmak temel meslek etiğidir
      Rollback içeren kademeli dağıtım da yeni bir kavram değil
    • Android 13’e, yani targetSdkVersion 33’e uygulama portlama işinde Android 13 testi yapmamış olmanın mazereti yok

  • “Açık web standartlarına geri dönüp kontrolü yeniden ele alalım” sözü, web’in de şu anda soruna yol açan şirket olan Google tarafından yarı yarıya kontrol edildiğini fark edince değişebilir. iOS’ta fiilen tek tarayıcı olan Safari’ye sahip Apple da pek dost sayılmaz

    • Bu da doğru, ama en azından bu tür bir sorun rollback gibi yöntemlerle ele alınabilir. Şu anki durumda kötü bir build’in production’a çıktığını ve telefonların otomatik olarak ona güncellendiğini biliyorsun, ama hiçbir şey yapamıyorsun. En kötüsü bu
    • Web’de barındırmak, yalnızca maliyetini ödemekten daha fazla bakım gerektirebilir
      Sırf daha iyi takip yapmak için var olan herhangi bir uygulamadansa kesinlikle web sitesini tercih ederim, ama bu yazı bana bakımın yarım yamalak yapıldığı bir örnek gibi göründü
    • Kullanıcı gizliliğini ve güvenliğini önceleyen yöne katılmayı reddediyorsan Apple kesinlikle dostun değildir. Bir gerekçe belirtmek gerekirse, durum bu

  • Bu kazanılamayacak bir durum
    Microsoft geriye dönük uyumluluk için muazzam çaba harcıyor ve bu büyük ölçüde takdiri hak ediyor. Ama bunun kadar saldırı yüzeyi de ciddi biçimde büyüyor
    Benzer şekilde, haksız yere eleştirilen C++’ın en kötü yanlarının önemli bir kısmı geriye dönük uyumluluk konusundaki katı tutumundan geliyor. Mümkün olduğunca eski kodların, hatta eski C kodlarının bile derlenmeye devam etmesi ve beklendiği gibi çalışması gerekiyor; kaynak kodu kaybolmuş eski ikililerle linkleme noktasına kadar buna katlanılıyor
    Çoğu kişi bu kadar çaba göstermeyip bakım yapılabilirlik, güvenilirlik ve güvenlik gerekçeleriyle eski şeyleri geçersiz kılıyor
    Hangi ayrım noktasını seçerseniz seçin birileri zarar görüyor. Öyle değilse zaten o kodu kimse kullanmıyordur

    • Doğru. Sorunun bir yanı bu ve ben de aşırı geriye dönük uyumluluk talep etmiyorum. Bu özel durumda en büyük endişe, Android’de bir sürümü geri alma, iptal etme ya da rollback yapma yolu olmaması ve her şeyin Google’ın inceleme sürecinin arkasında tıkanması
      Sorunlu bir sürümü “geri çekip” önceki sürümü en güncel sürüm olarak göstermeye devam etmek neden mümkün değil? Bu, bu sorun bağlamında çoğunu çözerdi
    • Herkese yardımcı olacak orta yolun API’yi değiştirip derlemeyi bozmak olduğunu düşünüyorum. Geliştiricinin derleme hatasını düzeltip API’yi doğru kullanmasını sağlamak yeterli
      Ama aynı imzaya sahip mevcut bir fonksiyonun davranışı değiştirilmemeli. API sağlayıcısıysanız derlemenin anlamlı olması için elinizden geleni yapmalısınız
    • En iyi kazanan seçenek yok ama uygulama ayrı olarak da dağıtılabilir. Bu bir Android gereksinimi değil, Play Store gereksinimi
      Çoğu durumda hiç de basit değil ve Play Store sürümü kadar kullanılmayacak, ama bir çıkış yolunun olması iyi
    • Yazarın asıl şikâyeti, Google’ın kullanıcıların hangi yazılımı çalıştırabileceğine karar veren hakem rolünde olması gibi görünüyordu. API’nin kullanımdan kaldırılması meselesi ise bizim Google’ın keyfine ne kadar açık hale geldiğimizi fark ettiren tetikleyici sadece
    • Bunu Google için bir mazeret olarak kabul etmek zor
      Android’e dağıtılan uygulamaların çoğu Android bytecode’unu hedefliyor. Bunlar native derlenmiş uygulamalar değil
      C++’ın aşılması zor güvenlik sorunları yaratmasının nedeni düşük seviyeli yapısı ve bir kez native ikili oluştuğunda işin orada bitmesi
      Ama bellek güvenliği olan bir dilin bytecode’u söz konusuysa güvenlik düzeltmelerinin backport edilememesi için ne sebep var? Böyle kod çalıştırmanın kendisi zaten bytecode’u sürekli yeniden derleme niteliği taşıyor
      Bu tutumun Google açısından ne kadar saçma olduğuna bakmak için: JVM bugün hâlâ 1996’da çıkmış Java 1.0 hedefli sınıfları çalıştırıp kullanabiliyor
      Bu bir güvenlik sorunu değil, “Google platformu desteklemek istemiyor” sorunu
      Google’ın native derlenmiş kod içeren çıktılar konusunda daha katı olmasını bir ölçüde anlayabilirim. Ama “uygulama eski bir Android sürümünü hedefleyerek build edilmiş, bu yüzden artık desteklemeyeceğim” tarzı toplu bir politika akıl alır gibi değil. Güvenlikten çok eski uygulamaları mağazadan budamanın bir yolu gibi görünüyor
      Özellikle böyle bir politika, doğası gereği Android geliştiricilerine büyük bir bakım yükü bindiriyor. Bir uygulamayı en geniş kitleye desteklemek için mümkün olan en eski Android sürümünü hedeflemek gerekiyor. En yeni Android sürümünü hedeflerse fazla müşteriyi dışarıda bırakacağından korktuğu için bunu yapan pek yok
      Google güvenliği ve en yeni Android teknolojilerine geniş erişimi ciddiye alsaydı, Android runtime’ını işletim sistemi sürümünden ayırmaya çalışırdı. ART ve Dalvik runtime’larının Android ekosisteminin diğer parçaları gibi Google Play üzerinden dağıtılmaması için hiçbir neden yok. “Bunu yapmak için Android 17 gerekiyor… aa, donanım üreticisi sürücüleri güncellemiyor” gibi aptalca durumları da ortadan kaldırabilir
      Ama bu yeni cihaz satışlarına darbe vuracağı için kabul edilemez herhalde

  • Play Store’un ve içinde kapana kısılmış geliştirici “topluluğunun” bir tuzak olduğu her zaman açıktı. Zorunlu API yükseltmeleri bunun yalnızca bir yönü
    Telefonların ya da mobil uygulamaların en iyi yaptığı işler elbette var. Genellikle navigasyon gibi hareketle ilgili şeyler ya da hangi tarafın “yukarı” olduğunu anlamak gibi telefon sensörlerine dayanan işler. Ama geri kalan neredeyse her şey web sitesiyle yapılabilir
    Tek başına çapraz platform mobil uygulama bakımı yapan bir geliştiriciyseniz gerçekten zor olmalı, empati kuruyorum. Yalnız ben uzun zaman önce tescilli platformların ve gatekeeper’ların oyununa katılmak istemediğime karar verdiğim için, ancak tamamen dışarıdan biri olarak empati kuruyorum

    • Aslında o iki şey de tarayıcı uygulamalarında kolayca yapılabilir
      Şu anda mobilde kolay olmayan neredeyse tek şey GPU compute shader’ları gibi görünüyor. Ama WebGPU masaüstü tarayıcılardan gelince o da yıkılacak
      Aklıma gelen bir diğer şey de genel, sistem çapında dosya yönetimi. O muhtemelen sonsuza kadar gelmeyecek. File System API belirli dizinlere erişim iznini kullanıcının vermesini sağlıyor, ama bu iznin sayfa yenilemeden sonra da kalıcı olup olmadığını bilmiyorum
    • App Store’un başarısız olacağından emindim. Çünkü geliştiricilerin kendi uygulamalarını gerçekten dağıtabilme garantisinden vazgeçecek kadar kalabalıklaşacağını düşünmemiştim
    • Android’de yazılım gatekeeping’ini yeterince yapmıyor diye Google’a sık sık saldıran ve daha agresif denetlediği için iPhone’u daha iyi diye öven bir sitede bunu okumak komik
    • Kullanıcının kendi cihazı üzerindeki egemenliğini ideolojik olarak savunmak istemezsiniz herhalde, değil mi? Onun yerine akıllı ve pratik davranıp en az dirençli yolu izleyerek kafesin içine yürüyüvermek yeterli

  • Google’ın SRE ilkelerinden birinin “geri alma normaldir” olması düşünüldüğünde bu ironik
    https://cloud.google.com/blog/products/gcp/reliable-releases...
    “Google’da felsefemiz şudur: ‘geri alma normaldir’. Yeni bir sürümde bir hata bulunursa ya da makul şekilde bundan şüphelenilirse, yayın ekibi önce geri alır, sonra sorunu araştırır. Geri alma isteği, yayın ekibine ya da hatalı kodu yazan kişiye yönelik bir saldırı olarak yorumlanmaz. Aksine, kullanıcılar için sistemi olabildiğince güvenilir kılmaya yönelik doğru şey olarak anlaşılır. Geri alma değişiklik listesinde gözlemlenen sorun açıklandığı sürece kimse ‘bu değişikliği neden geri aldın’ diye sormaz.”

    • Geçen yıl itibarıyla Google Play politikaları ile Android güncellemelerinin birleşmesi sonucunda, bir uygulamayı Play Store üzerinden dağıtıyorsanız geri almanın tek yolu silip kullanıcı verilerini sıfırlamak
      Daha düşük bir versionCode’a downgrade yapılamıyor ve versionCode geliştirici tarafından tanımlanıyor
      Android 11, medya istisnaları veya yerel klasörleri bulut depolama gibi ele alan DocumentFile API’sini kullanma dışında, telefonun “kalıcı” depolama alanına yazmayı yasaklıyor. DocumentFile birçok kullanım senaryosunda kullanılamıyor
      Geliştirici hasFragileUserData ayarlayabiliyor; bu durumda silme sırasında kullanıcıya verileri silip silmeyeceği sorulmalı. Ancak Google/Android hatası yüzünden bu iletişim kutusu gösterilmeyebiliyor
      Uygulama silindiğinde kullanıcı verileri silmezse, Android daha düşük bir versionCode’a downgrade’i engelliyor
      MANAGE_EXTERNAL_STRORAGE istenirse normal java.io.File kullanılabiliyor
      Google Play, MANAGE_EXTERNAL_STRORAGE’a yalnızca istisnai durumlarda izin veriyor
    • “Bana geri alma var, sana geri alma yok”

  • Benim yaptığım framework tabanlı birkaç uygulamada da aynı şey oldu. Yeni API sürümü mevcut bağımlılıklarla çakıştı ve zaten var olan o eski duruma dönmek için gerçekten muazzam bir çalışma gerekti
    4 yıl önce Android’de yazılmış bir mobil uygulamaya kıyasla, 90’lar işi şeylerin güncel Windows’ta daha sorunsuz çalışmasını sağlayan Microsoft’a çok daha fazla saygı duymaya başladım

    • Kullanılan framework Google’dan çıkmadıysa bu haksız bir söz olur
      Windows 11 Store’da Adobe Flash çalışmıyor diye Microsoft’u suçlamazsın, değil mi?

  • Uygulamaların yalnızca tek bir “kendi onaylı” uygulama mağazası üzerinden dağıtılmaya zorlanmasının çok fazla dezavantajı, neredeyse hiç avantajı olmadığını düşünüyorum.
    Avantaj denebilecek şey, ironik biçimde, uygulama mağazası yöneticisinin yayımlamadan önce kötü amaçlı yazılım ve virüs kontrolü yapması. Ama Google reklamları ve Google/Facebook izleyicileriyle dolu uygulamalar her biçimiyle memnuniyetle karşılanıyor.
    Bir de kullanıcıların uygulama aramasını, kurmasını ve güncellemesini kolaylaştırması var. Tabii milyarlarca oyun uygulaması ile yalnızca reklam göndermek ya da kişisel veri toplamak için yayımlanmış birbirine çok benzeyen uygulamalar arasında aradığınızı bulabiliyorsanız.
    Dezavantajı, uygulama mağazası yöneticisinin keyfine bağlı kalmanız ve uygulama yayımlama süreci üzerindeki denetimi kaybetmeniz. Uygulamayı yayımlayıp yayımlayamayacağıma, ne zaman yayımlayabileceğime ben karar veremiyorum; App Store yöneticisi kendi işine gelip gelmediğine göre karar veriyor. Bence bu hak yalnızca kullanıcıda olmalı.
    Ticari yerel uygulamaları, örneğin ev bankacılığı uygulamasını, geliştiricinin web sitesindeki kişisel alana giriş yapıp indirmek isterim. Uygulama GPG ile imzalanmış olmalı ve paket bütünlüğü doğrulanabilmeli. Otomatik güncelleme işlevi de mümkün.
    Açık kaynak uygulamalar için F-Droid mağazası var ve kendi depolarınızı ekleyebiliyorsunuz. Biraz teknik olduğunu ve herkese uygun olmadığını kabul ediyorum. Yeni telefonlara F-Droid önceden kurulu gelse çok yardımcı olurdu ama Google’ın buna izin vereceğini sanmıyorum.
    Bir başka gerçekçi seçenek de PWA. Bana göre yerel özelliklere ihtiyaç duyan uygulama sayısı çok az; geri kalanların neredeyse tamamı PWA teknolojileriyle yapılabilir. Kullanıcıya güncelleme göndermeye ya da yükseltme istemeye de gerek yok.
    Kullanıcıların hayatını kolaylaştırma ve “daha iyi güvenlik” sağlama bahanesiyle işletilen kapalı ve ticari uygulama mağazaları, Apple ve Google’ın bağımsız geliştiricilerin emeği üzerinden milyarlarca dolar kazanmasını, Google söz konusu olduğunda da kullanıcıların kişisel verilerini toplayıp satmasını ve her türlü yoldan reklam satmasını sağlayan “harika” bir araç.

    • Bir başka avantajı atlamışım. Boston Strangler’ı[0] evin dışında tutabilmek. Kullanıcının ellerini arkasından bağlarsanız, kullanıcının sizin ürününüzü hangi koşullarda kullanacağını siz belirleyebilirsiniz. Korsan yok, reklam engelleme yok.
      80’ler ve 90’larda oyun geliştiricilerinin genel olarak “Licensed by Nintendo” modelini izlemesinin, 2000’lerin sonunda mobil uygulama geliştiricilerinin de iOS App Store’da aynı şeyi yapmasının nedeni buydu. Kullanıcılarla doğrudan işbirliği yapıp platform sahibini baypas etmek istemiyorlar. Platform sahibinin kullanıcıların ellerini bağlamasını istiyorlar ve bu süreçte kendi ellerinin de bağlanmasını göze alıyorlar.
      Örneğin banka uygulamalarına bakalım: Bankalar güvenli uzaktan kimlik doğrulama ister. Uygulamaya yönelik credential stuffing saldırıları yapan kullanıcıları engellemek, kötü amaçlı yazılımın banka uygulamasını açıp “dolandırıcıya para gönder” düğmesine basmasını önlemek, kullanıcının tap-to-pay ile ilgili kriptografik gizli değerleri çıkarmasını engellemek ve çalınan gizli değerlerin telefon uygulamasına enjekte edilmesini de önlemek isterler.
      Uygulama, kullanıcının ellerinin bağlı olup olmadığını kendi kendine doğrulayamaz. Önyükleme zincirinde ya da EL3’te bulunan, kullanıcı için değil banka için güvenilir olan bir üçüncü tarafa ihtiyaç vardır. Bu yüzden amaç yalnızca uygulamayı ve imzayı vermek değil; Google’ın kullanıcının ellerini bağlayabilmesi için Google’ın bunu yapmasını istemektir.
      Uygulama mağazalarının kullanıcı tarafındaki tüm faydalarının sonradan uydurulmuş gerekçeler olması önemli. Başından beri hedef kullanıcıları bağlı tutmaktı. Çünkü onlar için kullanıcılar küçük hırsız sivrisinekler gibi varlıklar. Yüksek sesle söylemedikleri “sessiz kısım” bu.
      Lütfen Google’ın WEI önerisi gerçeğe dönüşmesin ve PWA’lar kanıtlama işlevlerine erişemesin. Google zaten “bilinmeyen tarayıcılarda giriş yaptırmama” saçmalığını yapıyor; bu kanserin yayılmasına gerek yok.
      F-Droid harika. Google’ın Android’de çevirdiği oyunlar durdurulmalı. AB bunu yapabilirdi; ABD de yapmalı ve bunun uluslararası uygulanmasını sağlamalı.
      [0] MPAA’in ticari olmayan küçük ölçekli kopyalamaya, yani VCR ile TV programı kaydetmeye verdiği kod adı. Jack Valenti gerçekten berbat biriydi, değil mi?

  • Mobil uygulama geliştirmeye karar verdiğiniz anda ürününüzün ya da hizmetinizin denetimini üçüncü bir tarafa devretmiş olacağınız gerekçesiyle ben de yıllardır mobil uygulama geliştirmeye karşı çıktım.
    Katılmamak zor değil.
    “Destek”, HN’de ya da Twitter’da işe yarar bir ilgi görmeyi ummak düzeyindeyse, yanlış yoldayız demektir.