I've been doing Android development for ~6 years now. For the last 2 years I've been doing it full time at Google (not on the Android team).

Your first impression is correct. There is a LOT to know and I am still learning new bits every day. And yes you do find most of it out by digging around in the docs or on StackOverflow.

That said, it's an amazing platform to explore because no door is fully closed. Android will let you do practically anything if the user wants you to. That leads to a really gratifying hacking experience where if you just keep digging you can achieve really fun and crazy things that you'd never be able to do on any other platform while working with mostly high-level APIs. It has its own strange logic that I have grown to love.

Some things are much more sane and well thought out than iOS. Styling and layouts, for example, are so much better than Interface Builder, which is pretty much just a toy for demos.

Other things like the way events are handled and some of the native widgets are clunky. Some of us are fed up enough with all the incidental complexity Apple puts in your way every day as a developer (provisioning, in particular), that we prefer to put up with Android's warts.

That said the native app market is feeling pretty saturated these days and I'm not sure that boning up on building responsive/progressive web apps isn't a better long term bet.

I'm a grumpy geek who went down this path a few years ago and here's my $.02... It is a fairly complex, and in some cases downright convoluted, API for the functionality it offers and the tools are pretty crude. The good news is that it is logical and you can get used to it, the bad news is it is a constantly moving target (i.e. API bit rot can progress at an amazing rate on Android if you try to keep current with the SDK revisions. I've lost count of the number of policy changes and reversals on subsequent releases) Unless you have a professional need or burning curiosity, I probably wouldn't bother with it.

The graphics stack in Android is badly designed. It is that way for historical reasons. Android used to do CPU-based blitting -- similar to other mobile platforms at the time: Symbian OS and Windows Pocket PC. Then the first iPhone launched & it became clear that GPU rendering was the way to go for mobile UI drawing.

Rather than rebuild the graphics stack from the ground around GPU rendering, GPU support was tacked on to the existing graphics stack. Resulting in this franken-architecture: http://source.android.com/devices/graphics/architecture.html

That guide has such gems as:

"Once upon a time this was done with software blitting to a hardware framebuffer (e.g. /dev/graphics/fb0), but those days are long gone."

"While this section uses SurfaceFlinger terminology, WindowManager uses the term window instead of layer…and uses layer to mean something else. (It can be argued that SurfaceFlinger should really be called LayerFlinger.)"

"Some things that work with Surfaces want a SurfaceHolder, notably SurfaceView. The original idea was that Surface represented the raw compositor-managed buffer, while SurfaceHolder was managed by the app and kept track of higher-level information like the dimensions and format. The Java-language definition mirrors the underlying native implementation. It's arguably no longer useful to split it this way, but it has long been part of the public API."

etc.

after 6 years writing Android code I still struggle, specially with anything UI related. I do as well web and Qt which I find vastly superior in terms of user interface creation. If you stick to "material templates" you are ok, but as soon as you want to do things a bit differently is a pain in the ass... Theming is just horrible, and having xml files and images scattered everywhere using flat herachies is a bit annoying.

And the audio subsystem is still really bad, lots of lag which prevents android having any serious sound / music app... if you dig the forums you will find lots of really upset people complaining and willing to help improve the sound subsystem and the Android team just keep ignoring... Just to give you an example, my raspberry pi gives me 3ms of sound latency while my current flagship Android phone with Android 6.0 gives me 100ms, totally unaceptable for music related apps :(

In terms of Android Studio I use it, but I find the interface really bloated which interferes with my desktop zen. I tweaked but still dont like it, somehow i miss my tuned Eclipse of some years ago. Biggest thing since the transition to Android Studio is Gradle which I find it really good.

I just wish Android was a truly open ecosystem where we developers have more voice than asking for help in stackoverflow and using a limited set of tools. Web development might be chaotic, sometimes feeling overcomplicated but Im truly amazed and thankful by the quality, quantity and variety of tools that the comunity produces. It just feel fresh and you can do it the way you want, from a simple html and css in a single file with a notepad to the most advanced framework with linters everywhere.

I've been developing both android and ios apps for the last six years. Both the platform are quite complex and yes, you need to learn and get experienced a lot even if you could do "basic" apps without much troubles. And remember that if you think android is a difficult environment, you will have really harder times on the io platform!

It'd be helpful to have more context about your development experience. I've done some iOS development in the past, and as spapas82 mentioned once you understand the core Android concepts it's easy to pick up. The docs are good, and there's a lot of tutorials and small articles to get you going.

If you've never done native mobile app development (e.g. you only have background in web dev), then regardless which platform you start off with, the initial learning curve will be a bit steep. Most APIs are "lower level" than the web counterparts and there's more ceremony to piece things together since you're working in such a constrained environment (memory, CPU, battery, network speeds, inconsistent internet access, disk space).

All that said, I think Android is a _taaaad_ easier to start off with vs iOS if you're a web dev. There's the GC, the Activity model is similar to web pages and their View XML abstraction is not that far off from HTML/CSS.

I may have felt like this when I started playing with android (4-5 years ago), but not anymore. It definitely gets better. Notice that I am not a full-time android developer however I have developed a bunch of part-time projects for Android.

The API is not really complex if you know a few basics (services/ activities/ broadcastasts/ lifecycle/ intents/ handlers/ ui/ ui thread/data storage) and then just know where to look for the answers(the android docs and tutorials are good and there's an answer to everything in SO).

Also you need to have a solid understanding of Java or you'll definitely have problems. So my proposal is to grok the (few) needed basics and the just go all-in and try to implement a full application so that you'll get the needed friction with the android environment.

2.2 introduces constraint layout support in the ide so you get drag and drop ui design like Xcode. Still have to wire things manually but libraries like butterknife are making that less painful.

Theres a reason android developer avg salary is higher then iOS ;)

I don't think the API is that complex (although yeah, there's a lot in it). What really puts me off is the rate of churn of API 'best practices'. It's alleviated somewhat (in an ugly way IMO) by the XxxCompat classes but it still feels like you're running the Red Queen's race just to keep an app running on a decent range of devices.

You're going to call me crazy. But using Xamarin to develop Android apps in C# via Visual Studio is seriously a better experience than using the Android Studio. At least, that's been my experience with simple personal projects -- perhaps if you are Facebook or Instagram that's not the case.

The API is almost the same, sure. But things like class attributes, null-coalescing, lack of Gradle, automatically generated getters and setters which can be overloaded... I had more fun writing a personal app for fun in Xamarin than I ever did in Android Studio, which only ever frustrated me, even though I love the IDE it is based upon.

Every time someone complains about the complexity their only solution seems to be to add more tooling and IDE wizards instead of simplifying things. It's like watching them repeat all the mistakes of Visual Studio in the 00's.

> And does anyone know if it gets better with time or is it a constant struggle?

I'm not super experienced, but I did invest quite a bit of time a few years ago and never got to the point where it was getting any better.

... and than you need to do the same thing for iOS, which is a totally different eco-system. I've been using the known multi-platform tools for a few years now, like Cordova and Haxe+OpenFL. Haven't typed a line of Java since...

I am starting my first mobile using React Native now. I couldn't get into native Android programming because it seems that you need to learn a lot of scaffolding just to get to what you want.

Running a real ARM emulator is still slow but for most things running an intel emulator with haxm will be fine. An actual device will be faster but the emulator will be suitable for simple test

The Intel emulators these days are very fast, especially the ones you can create in Android Studio 2.0+. They are still resource hungry (RAM mostly) but they are now faster than developing on a physical device.

In Studio 2.0 it got much better. Just make sure you're using a recent gradle version in your project config (it'll prompt you if you open up an old project).

Haven't had to use Genymotion since 2.0. Instant run is getting better w every release, I surprised the iOS dev last time I showed it to him.

Yes, use an Atom based image versus an Arm one, and it should be much faster.

Yes, the experience is much better. Sadly the NDK APIs are still the same.

Also be ware that at least during the beta period, the CMake build files had better support than Android.mk ones.

Still bit buggy in that changes to CMakeLists.txt or Android.mk do not refresh the targets and dependencies JSON.

I spend about 80% of my day in Android Studio and It's definitely resource hungry. On my brand new MBP 13" with 16GB RAM and an i7 processor it can still make the whole thing stutter when compiling a medium to large project.

At work my desktop can handle it, but that thing has pretty unrealistic specs.

I work on a very large project, I need to give 4 go to Android Studio and 6 go to gradle. When I do this, I get a very fluid experience.

That's an extreme case though, most projects can be worked on with reasonable machines. An SSD really helps though

Yes, a good SSD will improve your performance compared to a spinning disk.

It runs perfectly well on a current MacBook (12"). Which is the least performant Mac(Book) AFAIK.

It wants about 2.5GB of RAM for itself, so you might be running out of RAM.

Not in a year, but it wasn't different enough to me - less verbose, but the same when I long for a Lisp or ML or Haskell for Android! Scala was a thought. And I am now looking at F# again with the recent OS works by MS and the Xamarin situation.

As I wrote downstream, I just need to commit to Java (or Kotlin!) I think!

I know, since my first attempt was in Java to create a simple app. I know the NDK can be used to create OpenGLES guis, and access the sensors, but for a traditional app it's a lot of work.

Syntax is a subjective thing; I just don't like Java. I was hoping Google was going to come up with something (other than Go), for Android.

I have tried a lot of the work arounds, and simply put, Java is the way to do Android right, so I guess I need to get over it!

If no one used it, they wouldn't be adding better support for it.

The NDK is pervasively used by many many applications; that's why it's getting more support.

For some reason this seems unpopular with the android team, who seem to keep trying to avoid the issue when ever its raised at I/O...but hey, clearly at least someone is paying attention to what the statistics are showing.

Sure, it's some extra hoops to jump though; but shared business logic that you can use on any code base on any platform; that's a really really compelling reason to use the NDK, or one of the stacks based on it (eg. Xamarin, react native).

It's not just for some edge case. The biggest players in the field are doing this.

I think it's misrepresentative to try to characterize this as 'just for games'...

See my replies above, but yes, I am a fan of F#, and I wish it were that easy, but I think simply learning Java (or Kotlin as pointed out above) might be the best way in the end. Google has made it very clear they are not working on an alternative from Java dev in Android.