I started dabbling in Android App Development in 2009, and did it full-time since 2011. I started using Kotlin a few years ago. Get familiar with using Androi

I started dabbling in Android App Development in 2009, and did it full-time since 2011. I started using Kotlin a few years ago. Get familiar with using Android Studio as your IDE. Read the Kotlin and Android documentation. Look at the (newer) Android example apps Google puts up on Github. Watch the (especially more recent) Android Developer videos on Youtube, especially the I/O ones (although some other deep dive ones are good too). Look at the codelabs. If you're already programming, one thing to be aware of is how ephemeral Android lifecycle classes (Activity, Fragment and associated Views) are. At any time the phone can be shut off and they can go away and be killed, and any state will disappear. So be aware of storing state in ViewModels and this sort of thing. Also, under the hood android has a Looper and a main thread with a message queue, and handlers. On an API level your Manifest will probably have a start Activity that is the main launcher, and which can launch other activities - but you don't launch them, you send an intent to launch them and then the system launches it. You don't have to understand all of this right off the bat but you do have to understand some of it, including how there is a main (UI) thread, and then you can launch network or disk access or computation calls on other threads. A statement is easier to fix than a function, a function easier to fix than a class, a class easier to fix than a module, a module easier to fix than the whole app. Getting the architecture right is important, as it is more difficult to clean up later. For a big app people often put network (REST API) access into its own module, put analytics into its own module etc. Plus functions are broken down. If HN had a big app, account might have its own module, submission threads and comments might have its own module, search might have its own module etc. Whatever makes sense. For a small app which won't grow, modularizing like that may be premature. Also within a module in its internal architecture, MVVM is the main architecture used. Something like clean takes more effort to put in and keep - what does a company do if senior people come in and do not like clean and aren't using use cases or business rules without dependencies etc.? If engineering is not already filled with good senior people committed to clean, who are not taking shortcuts to get features out etc. I would think twice about trying to use clean, for social reasons more than technical reasons. Android is notoriously difficult to test. Where do you put your tests? There is the testing pyramid of UI/e2e at the top, features/integration in the middle and unit tests at the bottom - the bottom of the period being the most tests. Except you can't really directly unit test Android lifecycle classes like Activity or Fragment with JUnit. So what do you do? You use the Google suggested unidirectional data flow from ViewModels into the lean lifecycle classes, sending in a UI model to the lifecycle classes to create the UI from. You unit test in the ViewModel the various scenarios and edge cases going out to the UI/lifecycle classes. You can unit test in other places but this is a way of indirectly unit testing UI. There are also UI tests like Espresso higher up on the test pyramid.