— Compose는 XML의 대체제가 아니다

Android 개발을 오래 해온 사람이라면 자연스럽게 이런 흐름에 익숙합니다.

Activity
 └ XML Layout
     └ View(Button, TextView, RecyclerView ...)

그리고 우리는 오랫동안 다음과 같은 방식으로 UI를 개발해 왔습니다.

textView.text = "Hello"
button.isEnabled = false
recyclerView.adapter.notifyDataSetChanged()

즉:

“화면 객체(View)를 직접 조작하는 방식”

입니다.

하지만 Jetpack Compose는 이 접근 자체를 바꾸려고 등장했습니다.

Compose는 단순히:

XML → Kotlin

변환이 아닙니다.

실제로는:

Control 중심 UI
→
State 중심 UI

로의 패러다임 이동에 가깝습니다.

기존 Android UI 시스템의 구조

전통적인 Android UI 구조는 아래와 같았습니다.

Activity
 └ XML Layout
      └ View Tree

예를 들어:

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContentView(R.layout.activity_main)
    }
}

여기서:

Activity의 역할

• 화면 생명주기 관리
• Intent 처리
• 권한 처리
• Navigation 연결
• Window 관리

즉:

Android OS와 연결되는 “화면 컨테이너”

역할을 했습니다.

View/XML의 역할

실제 UI를 그리는 역할입니다.

Button
TextView
RecyclerView
ConstraintLayout

같은 객체(View)를 생성하고 조작했습니다.

예:

button.visibility = View.GONE

즉:

“UI 객체를 직접 수정하는 방식”

입니다.

왜 이 방식이 어려워졌을까?

Android 앱이 커질수록 문제가 생기기 시작했습니다.

예를 들어:

• 화면 상태 증가
• 비동기 처리 증가
• RecyclerView 복잡도 증가
• Lifecycle 문제
• 화면 회전 대응
• Fragment 관리 복잡도
• 상태 동기화 문제

특히 현대 앱은:

실시간 데이터
+
Reactive Stream
+
비동기 이벤트

가 매우 많아졌습니다.

예:

• 채팅
• 지도
• 뉴스 피드
• 실시간 운전 정보
• 스트리밍 UI
• AI 응답 UI

이런 구조에서 “View를 직접 조작”하는 방식은 점점 유지보수가 어려워졌습니다.

Compose의 핵심 철학

Compose는 이 문제를 해결하기 위해 등장했습니다.

핵심 개념은 단 하나입니다.

UI = f(state)

즉:

현재 상태(State)가 무엇인가?

만 정의하면 UI가 자동으로 구성됩니다.

예를 들어 기존 방식은:

button.isEnabled = false

처럼 UI를 직접 수정합니다.

Compose에서는:

Button(
    enabled = id.isNotBlank()
)

처럼:

“현재 상태를 선언”

합니다.

Compose는 상태를 보고 화면을 다시 그립니다.

Compose 시대의 구조

Compose에서는 구조가 이렇게 바뀝니다.

Activity
 └ Compose Runtime
      └ Composable Functions

예:

class MainActivity : ComponentActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContent {
            Greeting("Android")
        }
    }
}

@Composable
fun Greeting(name: String) {
    Text("Hello $name")
}

Activity는 사라진 걸까?

많이 오해하는 부분입니다.

Compose는 Activity를 대체한 것이 아닙니다.

여전히 Activity는 중요합니다.

Activity의 역할

Compose 시대에도 Activity는:

• Lifecycle
• Permission
• Intent
• Navigation Root
• System UI
• Window 관리

등을 담당합니다.

즉:

Android 시스템과 연결되는 Entry Point

역할은 그대로 유지됩니다.

Compose의 역할

Compose는:

• 상태(State)를 입력받아
• UI를 선언하고
• 상태가 바뀌면 다시 그림(Recomposition)

을 담당합니다.

즉:

State → UI

변환 엔진에 가깝습니다.

Compose의 진짜 변화

많은 사람들이 처음 Compose를 보면 이렇게 생각합니다.

“XML 대신 Kotlin 쓰는 거네?”

하지만 실제 핵심은 다릅니다.

Compose는:

객체(View) 중심 UI

를

함수(Function) 중심 UI

로 바꾼 것입니다.

기존 View 시스템

기존 Android는:

Button 객체 생성
→ 속성 변경
→ invalidate()
→ redraw

방식이었습니다.

즉:

Mutable Object Tree 기반 UI

입니다.

Compose 시스템

Compose는:

현재 상태 → UI 함수 실행 → 화면 생성

방식입니다.

즉:

선언형(Declarative) UI

입니다.

Recomposition이라는 개념

Compose에서 매우 중요한 개념이 있습니다.

Recomposition

상태(State)가 바뀌면 필요한 부분만 다시 그리는 메커니즘입니다.

예:

var count by remember {
    mutableStateOf(0)
}

Text("$count")

count 값이 바뀌면 Text 부분만 다시 계산됩니다.

Compose는:

State 변화
→ 필요한 UI만 재계산

하는 구조입니다.

Compose가 중요한 이유

Compose의 진짜 의미는 단순 UI Toolkit 변경이 아닙니다.

사실상 Android UI Architecture 전체가 바뀌고 있습니다.

기존 사고

어떻게 View를 조작할까?

Compose 사고

현재 상태를 어떻게 표현할까?

이 변화 때문에 다음 개념들이 중요해졌습니다.

• State Hoisting
• Unidirectional Data Flow
• Reactive UI
• Flow/StateFlow
• Immutable State
• MVI Architecture

Compose는 단순 UI 라이브러리가 아니라:

State 중심 Architecture를 위한 UI 시스템

에 가깝습니다.

현대 Android 구조

요즘 Android 앱은 보통 이렇게 구성됩니다.

MainActivity
 └ NavHost
      └ Screen Composables
           └ UI Components

그리고 데이터 흐름은:

Repository
   ↓
ViewModel
   ↓
StateFlow
   ↓
Compose UI

형태로 연결됩니다.

Compose는 이 reactive 구조와 매우 잘 맞습니다.

Android 개발자에게 중요한 사고 전환

Compose를 배우며 가장 중요한 변화는 이것입니다.

기존 방식

textView.text = "Hello"

즉:

UI 객체를 직접 수정

Compose 방식

Text(text = message)

즉:

현재 상태를 선언

Compose 학습의 핵심은:

View를 어떻게 만들까?

보다

상태 흐름을 어떻게 설계할까?

입니다.

마무리

Compose는 단순히:

XML 대신 Kotlin

이 아닙니다.

실제로는:

Control 중심 UI
→
State 중심 UI

로의 전환입니다.

그리고 이 변화는 단순 UI 기술 변경이 아니라:

• Architecture 변화
• Data Flow 변화
• 상태 관리 방식 변화
• Android 개발 사고방식 변화

까지 포함합니다.

그래서 Compose를 제대로 이해하려면:

“UI를 어떻게 그릴까?”

보다

“현재 상태를 어떻게 표현할까?”

를 먼저 고민해야 합니다.

다음 글에서는:

“Android 개발자의 사고는 Compose에서 어떻게 바뀌는가?”

를 실제 예제를 통해 살펴보겠습니다.

ViewModel을 사용할 때 Factory를 사용하는 경우와 사용하지 않는 경우에는 큰 차이가 있다. 이 차이를 이해하면, ViewModel의 인스턴스 생성 방식과 의존성 주입(DI) 활용 방법을 더욱 효과적으로 설계할 수 있다.

1. 기본적인 ViewModel 사용 (Factory 없이)

✅ 특징

• ViewModel이 기본 생성자만 가진 경우 Factory 없이 사용 가능.
• ViewModelProvider를 사용하여 Activity 또는 Fragment에 간단히 연결 가능.
• 인수가 필요 없는 ViewModel에 적합.

✅ 예제 코드

class MainViewModel : ViewModel() {
    val message = MutableLiveData<String>()
    fun updateMessage(newMessage: String) {
        message.value = newMessage
    }
}

class MainFragment : Fragment() {
    private val viewModel: MainViewModel by viewModels()
}

✅ 장점

• 간단하고 구현이 쉬움 (by viewModels() 또는 ViewModelProvider 사용 가능).
• 생명주기를 고려하여 자동으로 관리됨.

❌ 단점

• 생성자에서 파라미터를 받을 수 없음 (Repository, UseCase 같은 객체를 직접 주입할 수 없음).
• 의존성 주입(DI)이 어렵고, ViewModel 내부에서 객체를 직접 생성해야 함 (유지보수 어려움).

2. Factory를 사용하는 ViewModel

✅ 특징

• ViewModel 생성자에서 파라미터를 받는 경우 반드시 Factory가 필요함.
• 보통 Repository, UseCase, API 서비스 등의 객체를 ViewModel에 주입할 때 사용.
• DI(Dependency Injection) 환경 (예: Hilt, Dagger)에서 활용하기 좋음.

✅ 예제 코드

① ViewModel이 생성자를 가지는 경우

class MainViewModel(private val repository: DataRepository) : ViewModel() {
    val data: LiveData<String> = repository.getData()
}

② Custom ViewModelFactory 구현

class MainViewModelFactory(private val repository: DataRepository) : ViewModelProvider.Factory {
    override fun <T : ViewModel> create(modelClass: Class<T>): T {
        if (modelClass.isAssignableFrom(MainViewModel::class.java)) {
            @Suppress("UNCHECKED_CAST")
            return MainViewModel(repository) as T
        }
        throw IllegalArgumentException("Unknown ViewModel class")
    }
}

③ Factory를 이용한 ViewModel 생성

class MainFragment : Fragment() {
    private val repository = DataRepository()
    private val viewModel: MainViewModel by viewModels {
        MainViewModelFactory(repository)
    }
}

✅ 장점

• ViewModel의 생성자를 통해 의존성을 주입할 수 있음 (Repository, UseCase 등).
• DI를 활용하여 테스트가 용이하고 유지보수가 쉬움.

❌ 단점

• Factory 클래스를 따로 구현해야 하므로 코드가 길어질 수 있음.
• Factory를 생성할 때 ViewModel을 명시적으로 매핑해야 하는 과정이 필요함.

3. Factory를 사용하지 않는 경우 vs Factory를 사용하는 경우 비교

항목Factory 사용 X (by viewModels())Factory 사용 O (Factory 필요)

4. ViewModelFactory를 활용하는 고급 예제

(1) ViewModel에 여러 개의 의존성을 주입하는 경우

class MainViewModel(
    private val repository: DataRepository,
    private val analyticsTracker: AnalyticsTracker
) : ViewModel() {
    fun logEvent(event: String) {
        analyticsTracker.trackEvent(event)
    }
}

(2) Factory에서 여러 개의 파라미터를 전달

class MainViewModelFactory(
    private val repository: DataRepository,
    private val analyticsTracker: AnalyticsTracker
) : ViewModelProvider.Factory {
    override fun <T : ViewModel> create(modelClass: Class<T>): T {
        if (modelClass.isAssignableFrom(MainViewModel::class.java)) {
            @Suppress("UNCHECKED_CAST")
            return MainViewModel(repository, analyticsTracker) as T
        }
        throw IllegalArgumentException("Unknown ViewModel class")
    }
}

(3) Fragment에서 Factory를 활용한 ViewModel 생성

class MainFragment : Fragment() {
    private val repository = DataRepository()
    private val analyticsTracker = AnalyticsTracker()

    private val viewModel: MainViewModel by viewModels {
        MainViewModelFactory(repository, analyticsTracker)
    }
}

5. Hilt를 이용한 ViewModel Factory 대체 방법

최근에는 DI 라이브러리(Hilt, Dagger)를 사용하면 Factory를 직접 구현할 필요 없음.

(1) Hilt를 활용한 ViewModel 생성

① ViewModel에 @HiltViewModel 추가

@HiltViewModel
class MainViewModel @Inject constructor(private val repository: DataRepository) : ViewModel() {
    val data: LiveData<String> = repository.getData()
}

② Repository에 @Inject 추가

class DataRepository @Inject constructor() {
    fun getData(): LiveData<String> {
        return MutableLiveData("Hello from Repository")
    }
}

③ Fragment에서 간단하게 ViewModel 생성

@AndroidEntryPoint
class MainFragment : Fragment() {
    private val viewModel: MainViewModel by viewModels()
}

• Hilt를 사용하면 Factory 클래스를 직접 만들 필요 없이, 의존성이 자동으로 주입됨.
• 이 방식이 현재 Android 개발의 표준적인 접근법.

6. 결론

• ViewModel에 생성자 파라미터가 필요 없다면 Factory 없이 by viewModels() 사용.
• ViewModel에 생성자 파라미터가 필요하면 반드시 Factory를 사용해야 함.
• DI 라이브러리(Hilt, Dagger)를 활용하면 Factory 없이도 자동으로 의존성 주입 가능.
• 테스트 가능성과 유지보수를 고려하면 Factory 또는 Hilt를 사용하는 것이 권장됨.

📌 정리:

간단한 ViewModel → by viewModels()
의존성이 있는 ViewModel → Factory 사용 or Hilt 활용

들어가며..

앞에서 이야기 했던 것[1]과 같이 기존에 개발 중이던 Android Application 과제에 참여하게 되면서 작성된 내용을 이해해야 하는 상황이 되었다. 여기서는 앞에서 언급한 UI 및 네비게이션 흐름 분석 중에서 FragmentTransaction, ViewModel, LiveData의 동작 방식 확인하기 위한 상세 내용에 대해서 살펴 본다.

Modern Anroid 구조

(1) Fragment 중심 설계 (Modern Android Architecture)

✅ 장점

1. 단일 Activity 구조 가능 (Single Activity Architecture)
   • 대부분의 UI를 하나의 Activity에서 관리하고 Fragment를 동적으로 교체.
   • Navigation Component를 활용하면 자연스러운 화면 이동 가능.
2. 유지보수 및 확장성 용이
   • 같은 Activity 내에서 Fragment만 바꾸면 되므로 화면 재사용성이 높음.
   • 대규모 앱 개발 시 구성 요소를 분리하여 관리하기 용이.
3. 반응형 UI (Adaptive UI) 지원
   • 태블릿과 스마트폰에 따라 레이아웃을 유연하게 조정 가능.
   • 예: 태블릿에서는 좌측 리스트 + 우측 상세보기, 스마트폰에서는 화면 전환.
4. Activity 간 전환 비용 감소
   • Activity 간 전환 시 onCreate() → onDestroy() 호출이 발생하여 리소스 소모가 큼.
   • Fragment 전환은 비용이 상대적으로 적고, BackStack을 관리하면 자연스럽게 복귀 가능.
5. ViewModel과 LifecycleOwner 활용 가능
   • Activity 단위에서 ViewModel을 공유하면 Fragment 간 데이터 유지 가능.
   • viewLifecycleOwner를 활용하면 Fragment의 라이프사이클을 안전하게 관리.

❌ 단점

1. Fragment의 생명주기 관리가 복잡
   • Activity보다 복잡한 생명주기를 가짐 (onAttach(), onCreateView(), onDestroyView() 등).
   • BackStack을 적절히 관리하지 않으면 메모리 누수 발생 가능.
2. FragmentTransaction 관리 필요
   • Fragment 간 전환 시 FragmentTransaction을 직접 관리해야 함.
   • commit(), commitNow(), addToBackStack() 등 사용법을 숙지해야 함.
3. Navigation Component 도입 필요
   • 기존 방식 (FragmentTransaction) 대신 Navigation Component를 사용하는 것이 권장됨.
   • Safe Args 같은 추가적인 학습이 필요할 수 있음.

Fragment vs Activity 사용 비교

Fragment, ViewModel, LiveData 분석 방법

(1) FragmentTransaction 분석

① Fragment 변경 방식 확인

• replace(), add(), remove(), show(), hide() 사용 여부 확인.
• commit(), commitNow()의 사용 방식이 적절한지 확인.
• addToBackStack() 사용 여부 및 Fragment 백스택 관리 방식 파악.

② Fragment 생명주기 확인

• onCreate(), onCreateView(), onResume(), onPause()의 호출 순서를 Logcat으로 확인.
• Fragment 간 전환 시 ViewModel이 정상적으로 재사용되는지 확인.

③ Fragment 간 데이터 전달 방식 분석

• arguments를 통해 전달하는지, ViewModel을 사용하는지 확인.
• FragmentResultListener 또는 LiveData로 데이터 전달하는지 분석.

(2) ViewModel 분석

① ViewModel 인스턴스 범위 확인

• Activity 범위인지 Fragment 범위인지 확인 (ViewModelProvider의 owner 확인).
• Fragment 재생성 시 ViewModel이 유지되는지 확인.

② ViewModel 내부 데이터 흐름 확인

• LiveData 또는 StateFlow를 사용하여 데이터를 관리하는지 분석.
• Transformations.map(), Transformations.switchMap()이 적절히 활용되는지 확인.

③ ViewModel의 Clear 시점 분석

• Fragment가 사라질 때 ViewModel이 정상적으로 유지되는지 또는 제거되는지 확인.

(3) LiveData 동작 분석

① LiveData의 구독 방식 확인

• observe()가 어디에서 호출되는지 확인 (Activity vs Fragment).
• viewLifecycleOwner를 사용하고 있는지 확인 (viewLifecycleOwner.lifecycleScope.launchWhenStarted).

② LiveData의 이벤트 처리 방식 확인

• SingleLiveEvent(일회성 이벤트) vs 일반 MutableLiveData 사용 방식 검토.
• observeForever()가 사용되었는지 확인 (메모리 누수 가능성 체크).

③ LiveData의 Thread 처리 확인

• MediatorLiveData 사용 여부 확인 (여러 LiveData 조합 처리 확인).
• viewModelScope.launch 등을 사용하여 백그라운드에서 처리되는지 확인.

마무리

Modern Android Application 구조가 Fragement 기반의 구조로 변경되면서 기존 Android Application을 이해하는 방법도 바뀌었다고 할 수 있다. 즉, Application -> Activity 기반의 구조 이해에서 Fragment, ViewModel, LiveData로 연결되는 구조를 이해를 먼저 해야 한다. 

Fragment에서는 변경 방식, 생명주기, 데이터 전달 방식을 이해한 후에, ViewModle 인스턴스 범위 확인, 내부 데이터 흐름 확인 그리고 Clear 시점 분석을 한다. LiveData의 동작 분석에서는 구독 방식, 이벤트 처리 방식, Thread 처리를 확인한다.

참고 문헌

[1] Modern Android Application 구조의 이해, https://technical-leader.tistory.com/174

들어가며..

기존에 개발 중이던 Android Application 과제에 참여하게 되면서 작성된 내용을 이해해야 하는 상황이 되었다. 일반적으로는 빌드를 해보고, 실행을 해보는 "모의 설치" [1]와 비슷한 절차를 해보았다. 개발 환경을 구축하고 소스를 받아서 빌드를 해보, 소스 코드를 살펴 보았다. 예전에 알고 있던 Android Application과 구조도 많이 달라져 정리해 본다. 특히, LLM과 분석에 대해서 이야기 해볼 때, 여러가지 힌트를 얻어서 기존 Android Application Project를 이해하는데 도움이 될 것으로 보여 정리해 본다.

분석 절차

1. 런타임 동작 분석

• 로그 분석: Logcat을 활용하여 주요 이벤트와 동작 흐름을 분석.
• 트레이스 프로파일링: Android Profiler를 사용하여 CPU, 메모리, 네트워크 사용 패턴을 확인.
• StrictMode 활성화: 백그라운드에서 발생하는 블로킹 작업이나 리소스 누수를 감지.

2. 의존성 및 모듈 구조 분석

• Gradle의 dependencies 확인 (./gradlew dependencies 실행).
• Android Studio의 Project Structure를 이용하여 모듈 간의 의존성 파악.
• Dagger/Hilt, Koin 등의 의존성 주입(Dependency Injection) 구조가 있다면 플로우 확인.

3. UI 및 네비게이션 흐름 분석

• Navigation Component를 사용하고 있다면 nav_graph.xml 분석.
• Espresso 또는 UI Automator를 이용하여 주요 UI 플로우 자동화 테스트 실행.
• FragmentTransaction, ViewModel, LiveData의 동작 방식 확인.

4. 네트워크 통신 분석

• OkHttp 로그 인터셉터 추가하여 API 호출 확인.
• Charles, Postman, Wireshark를 사용해 실제 API 요청과 응답을 캡처.
• Retrofit, Volley, Ktor 등의 네트워크 라이브러리 사용 여부 확인.

5. 데이터 저장 방식 분석

• Room, SharedPreferences, DataStore, Realm 등의 사용 여부 확인.
• adb shell 명령어를 통해 DB 상태 확인 (adb shell sqlite3 /data/data/your.package.name/databases/your_db_name.db).

6. 멀티스레딩 및 백그라운드 작업 확인

• WorkManager, JobScheduler, RxJava, Kotlin Coroutines 사용 여부 분석.
• 주요 백그라운드 태스크 실행 여부와 성능 영향 파악.

7. 앱 보안 및 권한 점검

• AndroidManifest.xml에서 불필요한 권한이 있는지 확인.
• 앱의 내부 데이터 보호 방식 (EncrytedSharedPreferences, SQLCipher 등) 점검.
• ProGuard 또는 R8 난독화 설정 확인.

8. 빌드 및 배포 프로세스 확인

• CI/CD 파이프라인 (GitHub Actions, Jenkins, Bitrise) 연동 여부 분석.
• Fastlane 또는 Gradle Task를 활용한 빌드 자동화 방식 점검.

정리

위 항목들을 실행하면서 애플리케이션의 구조적 특징과 문제점을 파악할 수 있을 것이다. 특히, 1차적으로 1, 2번은 쉽게 진행하였고 3번을 통해서 전체 프로젝트의 파일들과 역할들을 이해하게 되면서 전체적인 구조의 그림이 보이기 시작했다. 항후 진행 하면서 관련된 배경 지식등을 학습하게 된 내용도 추가 정리해 보자. 

참고 문헌

[1] 객체 지향 리엔지니어링 패턴: 3장 첫 번째 접근, https://technical-leader.tistory.com/139

Waydroid는 Linux 기반의 기기에 Android를 Container로 동작케 한다. WSL을 사용하면 윈도우에서도 Waydroid로 안드로이드 앱을 실행하는 것이 가능하다고 하지만, 아직 권하고 있지 않은 것 같다. 그렇다면, Windows를 유지하면서도 Ubuntu를 설치하고 Waydroid를 설정하는 방법으로 진행해 보자. 리눅스만 설치 되며 쉬운데, 사실 리눅스 설치가 어렵다는 생각이 들었다. 여기서는 포인트와 참고할만한 싸이트를 정리해 두자. 

1. Ubuntu 설정

Ubuntu는 현재(2022년 4월) Focal과 Hirsute를 지원한다고 한다. 우선은 설치를 해야 하고, 나는 외장 저장소(혹은 Micro SD를 메모리 형태로 가능)에 설치하는 방법을 정리해 둔다.

아래는 추천하지 않는 방법

1. ISO를 받아 USB로 부탕하여 시도하는 버전: lxc 등 설치가 되지 않고, binder에도 문제가 있어 권하지 않음.
2. Virtual Machine: 렌더링 성능이 나오지 않아 매우 느림 비추천.
3. WSL은 시도해 보지 않았지만, 아직 이슈가 많은 듯 (waydroid.io 참고하여 시도해볼지 확인할 것)

외장 메모리를 이용하여 Ubuntu 설치하기 위해, ISO로 만든 부팅 USB를 이용하여 부팅을 한다.

Terminal에서 gparted를 이용해서 외장 저장소(메모리 상관없음)를 사용하여 storage와 swap을 잡는다. [1]을 참조하면 된다.

관련된 몇가지 이슈가 있었는데 다음 링크를 참조하면 좋겠다.

1. 검은 화면으로 부팅이 안되는 경우: [2]
2. UEFI관련 이슈: 다시 설치할 때 부팅이 안되거나 아니면, Ubuntu 삭제시 참고 필요 내용 [3]

설치는 되었는데, Ubuntu 부팅을 하지 못하는 경우는 설치 장소를 못 찾는 경우이므로 USB로 외부 저장소를 잡아 볼 수있다. Wifi 안되는 경우도 있었는데, 이 부분은 커널 빌드가 필요하다고 하나, 시도 하지 않았다.

2. Waydroid 설정

Waydroid 설치[4]를 위한 관련 package (curl, lxc, ptyhon3, ca-certificates)를 설치한다.

Ubuntu 버전 (hirsute)를 찾아 아래에서 (bullseye)를 바꾸어 실행한다.

설치, init 그리고 container를 실행한다.

3. App store

F-droid와Aurora가 가능하다고 한다. apk를 받아서 설치한다[5].

4. 총평

Waydroid는 아직 불안하지만, 여러 앱이 동작한다는 부분에서는 충분히 멋지다. 특히, AOSP를 Open Source화 한 LeanageOS의 버전이 올라갈 수록 흥미로운 일일 것으로 보인다.

참고내용

[1] [4-2] 외장하드 SSD에 Ubuntu 16.04.1 LTS 설치하기, https://developer-thislee.tistory.com/12

[2] 우분투 USB 설치 블랙스크린 해결, https://arca.live/b/programmers/29170509

[3] 윈도우 EFI 파티션 마운트 및 수정하기, https://blog.djjproject.com/389

[4] Ubuntu/Debian Based Install Instructions, https://docs.waydro.id/usage/install-on-desktops#ubuntu-debian-based-install-instructions

[5] Install and Run Android Applications, https://docs.waydro.id/usage/install-and-run-android-applications