CommonsWare

With all due respect to the developer who wrote this post, standalone apps are relatively easy - you start jumping into the rabbit hole when you start getting into server API integration and doing processing off the main thread (AsyncTask, IntentService, Service, unit tests lions tigers oh my), layouts that don't suck, and custom animations... Making an Android app look sexy/good is an art in itself that I am still trying to learn.

At a certain point of app complexity, writing an Android app becomes less about writing an Android app and more about writing a well-structured, async/decoupled and performant app in Java.

Why is iPhone development relatively easy? Well, for one thing, the territory is well trodden. And it is based on the beautiful foundational framework of Cocoa, which has its roots in NeXTSTEP. Cocoa masters have been able to switch to iOS and tell people/show people how to code properly. Cocoa has been around for a while; the Android SDK is a WIP (but it has come a long, long way since Cupcake). Also, Java lacks compiler-level support for/doesn't have blocks and categories (two of the things that make Objective-C a joy). And, love it or hate it, you will start to miss CoreData when you don't have anything near equivalent on Android.

Some of my favorite resources for learning Android:

The best book for the money (frequently updated, author has huge SO reputation)

http://commonsware.com/Android/

Reto Meier's blog

http://blog.radioactiveyak.com/

Styling…

What books do you recommend?

I've depended entirely on the web for learning Android development, but I've heard good things about the Android books from http://commonsware.com/. He has some helpful (free) tutorials available as well.

What is the best part about working with Android?

For me: flexibility and transparency. I like to get my hands dirty and gain a deeper understanding of the system, and it's quite helpful having (1) access to the source code for almost the entire system and (2) root access on the device. Those things likely won't matter when you're writing your first Android app, but it will matter when you're doing something uncommon or complex.

Are there are any CoreData like persistence frameworks?

I haven't needed any for my own apps, but the framework has integrated data storage engines. I imagine that someone has built a CoreData-like layer that uses them. This link might be helpful: http://stackoverflow.com/questions/371538/any-good-orm-tools-for-android-development

Is three weeks, give or take a few days, too aggressive a deadline for doing a port from iPhone to Android?

Can you give us any more details? Your time commitment will vary significantly depending on the complexity of the app. If it's a 3D game, then three weeks might not cut it. If it's a reasonably straight-forward app that doesn't have a ton of features, then three weeks will be ample time given your prior experience.

A few other thoughts: don't be afraid of Android UI…

syncthing is an incredible piece of software.

It should be noted that:

* "Security" changes in recent versions of Android seem designed to kill use cases like syncthing. See links below.

* There is no iOS version, as near as I can tell because iOS is already where Android is headed.

The crux of the problem is syncthing is a single golang binary, but the only way to manage filesystem permissions on iOS (and now Android) is through tightly controlled OS dialogs, and there is no way to do this from golang. There aren't even NDK APIs for it. The closest thing Android is providing to an escape hatch is "all files access" [5], for which your app has to go through an approval process in order to be put on the play store. If you watch [2], GOOG makes it very clear that they want to minimize the number of apps that obtain this permission. It's unclear to me whether apps installed through FDroid or side-loaded will be able to use that permission at all, or if the APKs must be signed.

I'm all for improved security, but never at the cost of controlling what I am ABLE to do with my computer.

It's sad that our operating systems are turning into gatekeepers between developers/users and the hardware they "own".

[0]: https://github.com/syncthing/syncthing-android/issues/29

[1]: https://www.xda-developers.com/android-q-storage-access-framework-scoped-storage/

[2]: https://www.youtube.com/watch?v=UnJ3amzJM94&

[3]: https://news.ycombinator.com/item?id=19506544

[4]:…

> Google Play already does binary translations from ARM into x86.

It is not libhoudini [1]? AFAIK, libhoudini is not something that Google Play embeds on binary for distribution, it is a library that ships on Android x86 devices (and another AFAIK, it is proprietary from Intel so they only ships on Intel devices).

So while Google could have a similar approach if they want to ship another kernel for Android, the work is not as trivial as you seem to think.

> Also the whole point of ISO C, ISO C++, OpenGL, Vulkan, OpenSL is to be OS independent.

Yeah, it doesn't mean you don't need to recompile your software. You can't take an game written for Windows in OpenGL and run in Linux without recompile. This is my point.

> Game studios are not a charity, they develop games for profitable markets, not for large userbases that don't pay for games.

Well, Android seems to be pretty profitable? It is not the most profitable platform sure, however it sure makes enough money because almost everyone ends up creating games for both iOS and Android.

You seem to imply that making games to Android is not profitable, however it sure seems to be. Or Epic Games, EA, ActionVision, and many other big names in game studio are a charity.

[1]: https://commonsware.com/blog/2013/11/21/libhoudini-what-it-means-for-developers.html

we don’t modify and distribute your application code without your knowledge and approval º

Notably, this person used “don’t” and “will not”… as opposed to “can’t” and “cannot” º

So the next stage in the plan for the tech giants is to now take control over all our software applications and really lock them down too?

With locked iDevices and smartphones that don't allow you to install the system software you want, that can be crippled and made unusable by the manufacturers, and have nearly unrepairable hardware (with lobbying opposing right-to-repair legislations), the tech giants have ensured that we have already lost control over our hardware devices. Today we only "own" them in name.

The article highlights a real worry - It is not at all far fetched to believe that by wrapping apps with their own proprietary codes, the tech giants can control and steal our app data (a very likely goal of all the tech giants) and even modify the apps to cripple them or convert it to a malware (at the behest of over-reaching governments).

This just adds to my worry, and ire, at App Stores, and provides a new perspective of them I had never considered before.

º https://commonsware.com/blog/2020/09/23/uncomfortable-questions-app-signing.html .

> The absolute nightmare is about giving Google the root signing key of your application

I wish more people talked about this. At Amazon, I helped with the early threat modeling around adoption of "App Signing by Google Play", which requires sending your app's root signing key to Google (and is now required, with no publicly-available opt-out for new apps.) It would have added some nice things for Android devs: app bundles, smaller downloads, instant apps, etc.

That said, we imagined the following scenario, and were unable to find a reasonable mitigation at the time:

It seems plausible the US government could send a NSL (or similar) to Google and force them to distribute modified APKs for apps like Signal (ex: to exfiltrate keys). This would be nearly impossible to detect, especially if the modified APK were distributed to only an individual user, or a small group. A few people raised concerns [1], but I don't recall Google ever giving a reasonable response.

[1] https://commonsware.com/blog/2020/09/23/uncomfortable-questions-app-signing.html

Edit: clarify no opt out applies to new apps