Untrusted Touch Events in Android — статья о новой фун­кции Android 12, нап­равлен­ной на борь­бу с овер­леями, которые перек­рыва­ют весь экран или его часть. Проб­лема овер­леев (окон, которые при­ложе­ния могут показы­вать поверх сво­его или любых дру­гих окон) в том, что они поз­воля­ют перек­рыть окно дру­гого при­ложе­ния и переда­вать ему все нажатия, показы­вая на экра­не совер­шенно дру­гую информа­цию. В ито­ге зло­умыш­ленник может соз­дать овер­лей, который будет при­зывать нажать безобид­ную кноп­ку, а в ито­ге нажатие будет переда­но находя­щему­ся позади него окну, которое может акти­виро­вать опас­ную фун­кцию. В раз­ных вер­сиях Android Google реали­зова­ла все новые методы защиты от овер­леев, вклю­чая невоз­можность кон­такти­ровать с сис­темны­ми диало­гами при наличии овер­леев, отзыв раз­решения на показ овер­леев при пер­вой воз­можнос­ти и так далее. В Android 12 появит­ся еще один вид защиты: невоз­можность исполь­зовать овер­леи, которые про­пус­кают нажатия. Дру­гими сло­вами, если при­ложе­ние показы­вает неп­розрач­ный овер­лей, который переда­ет нажатия находя­щему­ся за ним окну (тип окна: TYPE_APPLICATION_OVERLAY с фла­гом FLAG_NOT_TOUCHABLE), то такое окно будет заб­локиро­вано. В спис­ке исклю­чений: пол­ностью проз­рачные овер­леи; не­види­мые овер­леи (GONE и INVISIBLE); до­верен­ные овер­леи (окна сер­висов Accessibility, кла­виатур и ассистен­тов); овер­леи, демонс­три­руемые поверх окна собс­твен­ного при­ложе­ния. Разработчику Чем отличаются compileSdkVersion и targetSdkVersion CompileSdkVersion and targetSdkVersion — what is the difference? — статья об отли­чиях двух свой­ств Gradle, которые час­то при­водят к воп­росам и недопо­нима­нию. Дей­стви­тель­но, как раз­работ­чики мы обыч­но обновля­ем зна­чения compileSdkVersion и targetSdkVersion одновре­мен­но. Для нас такое обновле­ние озна­чает, что при­ложе­ние теперь может исполь­зовать новые API, появив­шиеся в новой вер­сии Android, и на при­ложе­ния теперь нак­ладыва­ются новые огра­ниче­ния, которые в этой вер­сии Android появи­лись. Но зачем тог­да сущес­тву­ет два свой­ства, если даже IDE под­ска­зыва­ет, что при обновле­нии зна­чения одно­го сле­дует обно­вить и зна­чение дру­гого? Нач­нем с compileSdkVersion. Задача это­го свой­ства в том, что­бы ука­зать, какая вер­сия SDK будет исполь­зовать­ся при ком­пиляции при­ложе­ния. Если силь­но упростить, то она нуж­на для того, что­бы при­ложе­ние смог­ло най­ти новые API и выз­вать их. За­дача свой­ства targetSdkVersion дру­гая. С его помощью раз­работ­чик как бы говорит «я про­тес­тировал свое при­ложе­ние на этой вер­сии Android, и оно готово к осо­бен­ностям работы имен­но этой вер­сии Android». Это важ­ное свой­ство потому, что с раз­вити­ем Android меня­ется не толь­ко API, но и по­веде­ние ОС в отно­шении при­ложе­ний. Android может вес­ти себя по‑раз­ному в зависи­мос­ти от того, для какой вер­сии соб­рано при­ложе­ние. Нап­ример, в Android 12 изме­нил­ся спо­соб отоб­ражения уве­дом­лений. Если в пре­дыду­щих вер­сиях при­ложе­ния мог­ли исполь­зовать всю область уве­дом­ления, то теперь им дос­тупен толь­ко огра­ничен­ный пря­моуголь­ник с отсту­пами по кра­ям. Для при­ложе­ний, соб­ранных с targetSdkVersion 30 или ниже (то есть для пре­дыду­щих вер­сий Android), сис­тема будет вклю­чать режим сов­мести­мос­ти, поз­воляя съедать всю область уве­дом­ления. Но для при­ложе­ний с targetSdkVersion 31 будет дос­тупна толь­ко часть области уве­дом­ления. Вмес­те с новой вер­сией ОС Google выпус­кает документ, в котором под­робно рас­писыва­ет, какие аспекты поведе­ния ОС изме­нят­ся в зависи­мос­ти или вне зависи­мос­ти от зна­чения targetSdkVersion. По‑хороше­му прог­раммист сна­чала дол­жен озна­комить­ся с этим спис­ком, испра­вить при­ложе­ние так, что­бы оно учи­тыва­ло изме­нения, затем изме­нить оба свой­ства на зна­чение новой вер­сии ОС. При этом ник­то не зап­реща­ет изме­нять compileSdkVersion и targetSdkVersion раз­дель­но, но прак­тичес­кого смыс­ла в этом мало, так как Google пос­тоян­но повыша­ет минималь­ную вер­сию targetSdkVersion для при­нима­емых в Google Play при­ложе­ний. Используем Ktor вместо OkHttp Kotlin Ktor Network Fetching on Android — статья об исполь­зовании биб­лиоте­ки сетевых зап­росов Ktor для соз­дания муль­тип­латфор­менно­го при­ложе­ния вмес­то биб­лиоте­ки OkHttp. Ktor — это биб­лиоте­ка для раз­работ­ки кли­ент­ских и сер­верных сетевых при­ложе­ний, изна­чаль­но спро­екти­рован­ная для работы в сре­де Kotlin вне зависи­мос­ти от того, на какой плат­форме работа­ет при­ложе­ние: JVM, Android, iOS, бра­узер или дес­ктоп. Для начала Ktor сле­дует под­клю­чить к про­екту: implementation