On the flip side, consider PalmOS. It was SotA at its debut in 1996. In the early aughts, Palm made Treo smartphones when almost no one knew what a smartphone was. It had a multiyear lead, yet it got easily marginalized by iOS and Android. Its technical debt was from maintaining backward compatibility with 90's apps, and cost it dearly. To be fair, company management sucked too.
The moral is: caked-in issues suck, but if you're going all in with a design, the most important thing is to time it with the explosion of the market. Palm was too early, others like Maemo and Windows Phone were too late.
[0] https://android.googlesource.com/platform/frameworks/base/+/...
[1] https://cs.android.com/android/platform/superproject/main/+/...
Happy to answer any questions or help you out if you decide to keep going down this road, shoot me an email at [email protected]. Ultimately an Android phone is still just a Linux computer but jumping through the hoops is definitely hard.
They proceeded to tell me what to download on my laptop. I repeated my question, emphasizing "ON Android". They gave me blank looks. I said, "I want to install a toolchain ON an Android device, and run it there. How do I do that?"
They had no idea.
I asked, "What if you want to compile something that requires compiling something, then using that something further down the line, like Perl?"
Again, no idea.
A platform without a native toolchain is a very awkward place to be. I stopped trying to wrap my head around it and stopped playing with Android.
Termux was F-droid only, but 4 years later is back on the Play Store: https://github.com/termux-play-store#current-status-for-user...
Termux has both glibc and musl libc. Android has bionic libc.
One time I got JupyterLab to run on Android in termux with `proot` and pip. And then the mobile UI needed work in a WebView app or just a browser tab t. Maybe things would port back from Colab to JupyterLab.
conda-forge and Linux arm64 packages don't work on arm64 Android devices, so the only option is to install the *-dev dependencies and wait for compilation to finish on the Android device.
Waydroid is one way to work with Android APKs in a guest container on a Linux host.
That Android Studio doesn't work on Android or ChromiumOS without containers (that students can't have either).
OpenCV also has a warning and a guide for people trying to use it for Android dev https://opencv.org/android/. Did you look through this?
Also why do you want to use a USB camera when every phone has a couple cameras built in? I think you're going down a road of frustration if you think mobile OSes aren't built with completely different use cases in mind than desktop environments.
Theres a lot of information the Android dev site about getting up and running with the camera. You can pass a lot of the photo stuff off to other camera apps on your phone, but if you really need to do stuff in the app theres an official Android library for making your life easier. Theres also a lot of official Android libraries and well known libraries for images and videos that might be easier to work with than OpenCV. You don't actually say what you are trying to ultimately do.
Gradle is the part of Android dev everyone hates.
Sadly the golden age of the app store is long gone. I used to make thousands monthly around 2015 with silly apps, but all went down the drain by 2018. Making apps isn't worth anymore.
I wrote an app and had it running in both iOS and Android in no time (with minimal iOS dev and zero Android xp prior to that).
My app included the Jitsi video extension (with very customized Jitsi controls and self-hosted backend), so not just a simple CRUD app.
(To be fair, my background is mostly Node and React, but those skills made it a breeze.)
"You do not need to root your device. And - if you prefer - you do not need a separate development machine (PC or laptop): All can be done in a terminal on the device, and even in a Lisp REPL while the App is running."
What took you 10 minutes would take me a long time to learn. I rather enjoyed making some basic Android apps. I didn't work with much hardware stuff and heard that part is tough due to all the variations.
10 Install an app that is able to use UVC cameras
20 If works goto 50
30 Else Use a different phone and goto 10
50 Find an open-source app that is able to use UVC cameras
60 If it doesn't work goto 50 (find another app)
70 Try compiling the open-source app
80 If it works goto 150
90 ???
150 Reduce open-source app to minimum code necessary
160 Add own code
170 Make sure the phone doesn't overheat and/or develop a bloated battery when you leave it running for weeks and weeksSo you either reimpmentent the whole thing in a native way (using Java/Kotlin or C++ for lower level integration) or you’re SOL. You can embed Python libraries, but you’re better off learning to use wherever native analogues and frameworks the platform already support.
I personally stay the heck away from Android Studio (I got a very early start in Android development, so most of my projects are just Gradle/pom.xml or a Makefile atop a “normal” Java tree).
That said, you have _a lot more flexibilty_ in incorporating multiple languages and non-native frameworks than, say, in iOS.
If you ever have to work with native code (or things like OpenCV) start praying from day one and never stop.
You need bigger and bigger laptops to even run that disgrace of an IDE Android Studio. This always gets me!
So dev tools/env? Oh, god! Fuck Google!
Trying to do userland USB in an Android app to talk to a UVC webcam connected through USB OTG is not something even a niche of apps care for, and the native camera framework definitely doesn't care about because if it was trying to workaround the UVC spec Android phone cameras would have never left the original Gameboy camera age.
So with no native support for your use case, you are now having to wrangle the pretty shitty libusb and the even more terrible libuvc in working within the confines of an Android app. And to the credit of Android, this is possible! People have made it work! People with in depth knowledge of how the parts fit together, that is, and so GPT won't be of any help.
Android development is not simple. Take time to learn the architecture and underlying concepts. It took me a couple of weeks and some false starts to make sense of things (although back then I was a college student; a professional can probably get started faster).
You are not crazy and the pain you feel is the pain of commercial IT. Not strictly need to commerce of course, but that's the modern common practice. The cure is FLOSS, mandatory, from the start.
I think we're going to see the tendency accelerate to develop and validate ideas on iOS first and only later outsource a crappy Android port.
Using an external webcam with an Android device seems a fairly exotic scenario doesn't it? Whatever, I would intuitively expect (disclaimer: almost no experience in mobile development) the Android OS to detect a USB-attached camera as another built-in camera and expose it via common APIs rather than let you access it via some sort of low-level libs reading the USB.
But I feel you, if you don't have enough experience dealing with different Android, Gradle, AS errors then you're really having a bad day. But shouldn't be a deal breaker, just give it some time and more familiarity.
I want to jump back to Android dev contracting, my two questions for the up-to-date Android devs: - Do you have any resource to catch up with what I missed in the past 4-5 years of Android development? - How is the Android job market these days, compared to the iOS one?
-
You won't have to touch any horrible Kotlin nor Swift but still be able to publish the app on the stores if you want to.
Why is Android Development so difficult/complex? (compared to Web and Desktop)
Python packaging is notoriously bad, and while you can get a Linux/Windows compatible script without too much work, getting to a single executable that just runs is much harder. Cloning a repo, setting up a virtualenv, installing an openssl dependendcy or whatever, is just not something that exists in the mobile world. We have to put more effort into the packaging, and that means a higher bar for things like this. There are answers to this in Python that claim to produce single, relocatable, Python binaries, and I've never seen one without a huge list of caveats. Even yesterday I was patching an open source library that didn't work inside one of these because it had the gaul to use... checks notes, os.path.
> Well, looks like modern mobile phones are not a great hacker's playground, huh?
This sums it up. They are not. The security environment on these devices pretty much ends this before you even get to writing any code, and that's generally a good thing. Phones are appliances for most people. There's a reason why "apps" took off in a way that boxed desktop software never did, and there's a reason why boxed desktop software on Windows did far better than package managers on Linux. Almost everyone wants more a more polished experience. Shipping a Python script running OpenCV to a phone is not going to produce a polished experience.
Which toolkit did you use?
but I never had trouble loading in C/C++ libraries with the NDK beyond the debugging issues
Known fact, take it or leave it :)
To be fair UI development can not be simple in itself.
Because of the exponentially growing state machine => simple Rails style general purpose frameworks are impossible, it will always be a challenging problem.
> Well, looks like modern mobile phones are not a great hacker's playground, huh?
I'm using a GNU/Linux phone and I'm super happy with how playgroundish it can get if I want.
A wireless webcam is the simplest thing that might work. Hosting a video stream on other hardware might be the second simplest thing.
Good luck.
GPT does poorly with beginners - it's definitely something humans have advantage with AI and I expect the gap to get bigger.
I do not touch legacy projects anymore because they're always horribly broken, half the libraries no longer exist. Many of them are easier to rewrite than fix. You get weird bugs where A needs to be 1.71.0 but B needs A at 1.69.0 or 2+. Upgrading A to 2.0.1 will fix A and B but break CDEFG. Upgrading everything to max breaks switch-case, turns some of your brackets to lambdas, requires you to change your UI from XML to Kotlin, etc, etc.
If you want something to hack stuff with, I made this: https://github.com/smuzani/android-minimalist-template
Originally it was designed for AI with smaller context windows. But it works as a simplified version of our production codebase. The principle behind this is that you should have good peripheral vision and that the shape of the code resembles what it's trying to build.