Firebase dynamic link 지원 종료
- Deeplinkes → 앱내 특정 화면으로 이동하는 링크 (활용 사례: 소셜 로그인..등등)
- 지원 종료하는 이유 → 수익성이 낮고 Universal links 등 새로운 표준 기술 마케팅 분석에 특화된 다양한 대체 플랫폼 등장
<대안 방법>
-
App Scheme
- 앱을 설치하지 않은 경우 무시됨
- scheme이 겹치는 경우 → 앱 선택지 제시,
-
강의에서는 applinks라는 라이브러리 사용 in flutter
-
Universal (iOS) / AppLinks (AOS)
- 앱을 설치하지 않을 경우 웹페이지 이동 기존에 웹페이지를 가지고 있는 경우에 사용할 수 있음
- 네이티브 단의 세팅이 필요함
- 요즘 주로 사용하는 방법
- 네이티브 단에 Web Site Association 파일 / asset.json 파일 생성
- 정상 적용된다면 → 모바일 os의 브라우저에서 앱 설치 또는 열기 링크를 지원함
- 장점
- AOS, ios에서 공식적으로 제공하는 기능이므로 서드파티에 대한 의존성 추가하지 않아도 됨
- 단점
- 앱에 상응하는 웹 사이트없는 경우 구현이 어려움
- 마케팅 지표 설정 등의 수동으로 해줘야함
- ios에서 Deferred Deep Links 구현이 사실상 불가능
- 이 기술 사용했을 경우 자주 마주하는 오류
- 네이티브 단의 인증 파일을 .well-known 경로 안에 포함 시켰는가?
- sha 256 키가 플레이스토어와 일치하는가
- 기타 솔루션 → Branch, Appsflyer, AirBridge
- 사용자 추적 솔루션 → Firebase Analytics , Microsoft Clarity(7월 플러터 공식 지원), Curolink
-
결론: 잘쓰던 프레임워크, 라이브러리가 지원 종료되는 일은 흔하다. 하지만 해당기술이 없어지는 것은 아니며 일반적인 대체 방법이 존재 Firebase Dynamic Links 종료에 따른 대안은 비즈니스적 요소 고려
기여사례로 알아보는 오픈소스 입문
- 기여하기 좋은 프로젝트 → 살아있는 프로젝트의 특징
- issue가 많은 프로젝트
- issue의 라벨링이 잘 되어있는 프로젝트 → 버그류의 태그가 달려있는 이슈가 고치기 쉬움
- closed 된 pr중 외부인의 pr이 많은 프로젝트 → 외부 기여자를 안받는 프로젝트도 많기 때문에
- 오픈 소스의 기여 프로세스
-
기여할 프로젝트 찾기 → 이슈 찾기 또는 생성 → 코드 분석 → 해결하기 → 회귀 테스트 작성(내가 작성한 코드의 신뢰도를 입증하기 위해 이전에 문제가 발생했는데 해결법 적용결과 해결되었다 ) → 빌드 및 전체 테스트 통과 체크 → pr 작성 → 리뷰 → merged
-
issue에 해결책이 있는 경우 → 답지 보고 해결할 수 있음
-
영향을 끼치는 범위 최소화 하기 → 변경사항을 좀더 최소화하는 방향으로 기여하자
-
커밋 히스토리에서 힌트 얻기
구현이 막막한 경우 비슷한 파일의 commit history를 뜯어보면 쉽게 힌트를 얻을 수 있다.
-
도움을 주고 그들의 철학 배우기 → 이슈창에서 토의하는 걸 추천
-
리뷰에서 철학 배우기
-
git restore
-
다른 사람들과 문제를 해결하고 그들의 철학을 배울수 있음
what’s new in android
- trend in android → compose, multi - device, gemini , kmp
- Android 최신 트렌드
- Autosize Text → 사이즈에 따라 텍스트 사이즈 자동 적용
- Animate bounds → 위치와 컨테이너의 크기 자동 애니메이션화 → 애니메이션을 통해 유려한 UX
- visibility tracking → 컴포저블에 대한 위치 트랙킹 기능 구현
- visibility changed → 컴포저블 가시성이 변경될때 변경
- onFirstVisible → 처음으로 완전히 보일때 시행
- compose 성능 개선이 지속적으로 이루어짐 현재 Jank rate 0.1%
Jetpack
- Naviagation3
- 기존 Navigation은 compose와 적합하지 않음
- 백스택 직접 관리
Restore Credentials
새기기를 설정할 때 복잡한 설정 없이 App 계정을 복구할 수 있음 → 사용자 참여도 증가, 개발 비용 증가
Android Advanced Protection Mode
- 보안 - 침입 로깅
- 네트워크
- 스팸 전화로부터 보호 기능
- 안전하지 않은 웹사이트로의 접근 보호 기능
Identity check
- 신원확인을 요청하는데 사용된다.
- 장치가 신뢰할 수 있는 장소 외부에 있을때 민간한 접근에 대한 판별을 위해 3등급 생체 인증이 필요한 기능
Health connect
- 건강데이터 앱과의 공유
- 단일 api 세트 사용해 사용자와의 건강 데이터 공유 가능하여 편리
Medical Records apis
Adaptive app with android
watch os
- 본래 대부분 독립적인 apk 형태
- watch face push 0→ WFF라는 선언적 XML 형식의 파일로 정의됨
Live update
시간에 민감한 작업에 대해 나타낼 때 사용가능
widget - jetpack glance
- widget을 통해 app 외부에서도 편리하게 개발 가능
Widgets Metrics api
- android 12 부터 도입
- 앱 위젯이 다양한 기기와 화면크기에서 더욱 유연하고 일관되게 표시되도록 돕는 개발자 도구
- impression, interaction 관련 기능 추가해 출시 예정
Edge to edge
- 업데이트 할때 콘텐츠가 시스템 표시줄에 가려지지 않게 대응 필요
predictive back
- 3개의 시스템 하위 바에 elevation 적용
google low light boost
- Auto exposure mode 도입했지만 기능이 없는 기기에서는 사용 불가능
- ML 기능 활용해서 카메라 밝기 실시간 조절
preload manager
gemini live
Androidstudio 새기능
AI feature lab에서 신기능 체험적 기능 사용 가능
- Attach images → 스크린샷으로 앱의 레이아웃에 대한 context 얻을 수 있음
- context Management → gemini와의 채팅 대화에서 프로젝트 파일을 context로 첨부 , 코드베이스 분석 가능
Narwhal feature
- compose preview에서 정의 가능한 항목들을 노출 / preview annotation을 클릭해서 사용
- 16kb 크기 지원
- android 15 이전까지 4kb 메모리 페이지 크기만 지원
- 15부터 16kb의 페이지 크기 지원 추가
- 2025.11.1 부터 target sdk 안드로이드 15+ 모든 신규 앱 및 기존 앱 업데이트 시 플레이스토어 필수 정책
- Agent mode
- gemini를 활용한 새로운 자율형 ai 기능
- 아직까지 preview 버전
- rules in gemini
- 선호하는 코딩 스타일
- 출력 형식 정의
- gemini로 전송되는 모든 프롬프트에 자동 적용 가능 → Setting menu에서 설정 가능
- ui 변경을 gemini로 하기 → preview에서 바로 자연어 적용해서 ui 수정 가능
- Canery 2버전의 안드로이드 스튜디오
- 빌드 파일 표시 → 모듈 내부의 빌드 파일 표시
- partner device labs → 삼성, 샤오미 등등을 개발중에서 애뮬레이터로 사용할 수 있음
- play policy insights → inspects policy mode
- google play 정책에 대한 정보와 가이드 추가
- 출시 프로세스를 방해하고 나중에 수정시 많은 시간 과 리소스 소요 문제 방지가능
- 정책 개요, 권장사항에 대한 공식 문서 링크까지 안내 가능
- layout inspector child recomposition
- journeys → ui 테스트 진행 도와줌
- 자연어를 사용하여 엔드투엔드 테스트 쉽게 작성하고 자동화/관리할 수 있도록 도와줌
- crash analytics로 에러 체킹도 베타버전에서 가능함
Adaptive Android development
- Adaptive App
- 정의: 다양한 화면 크기에 반응하여 최적화된 사용자 경험을 제공하는 앱
- 예시: multi window
- 필요이유: 다양한 화면크기의 디바이스가 있기 때문에 (차량용 앱, )
- google play store에서 더 많은 호환성을 보장해줄수록 추천이 상위로 될수있음
- 기존의 android view → responsive design(반응형 앱 / 사용가능한 공간에 맞춰 디자인 요소 배치 조정)
- adaptive → 적응형 앱 / 사용가능한 공간에 맞춰 레이아웃 구성
- compose에서 적응형 레이아웃을 구현하는 가장 쉬운 방법은 BoxInConstraints
- Material3에서도 적응형 앱 라이브러리를 제공하고 있음
what’s new
Navigation3가 등장한 배경도 여기에 있음
- navigation display만 다루겠다 백스택은 개발자가 다뤄야함
Connected display
- 어떤 외부 display를 띄울 것인지 설정 가능
구현해야 하는 이유 → 여러 기기를 가지는 사용자들을 위한 최적화된 경험 제공, 하나의 빌드로 모든 기기에서 실행