Python for Android | Hacker News Reader

Python for Android

python-for-android.readthedocs.org

109 pointsfabriceleal74 comments

A bigger question on my mind has been why would a shop as smart as Google not have started out with a sane language like python in the first place instead of foisting this java idiocy on another generation of devs.

I've always wondered this as well. I mean, Google loves Python as evidenced by App Engine, how many of their internal/external tools use Python and other projects I'm forgetting. Basically I would have at least expected it as a built-in option to use (kind of like how Windows Phone 8 has a higher-level and lower-level way of accessing the phone).

App Engine has, if anything, better support for Java than Python.

I might be remembering incorrectly, but wasn't the launch option for App Engine their home-grown version of web.py?

They started with Python and their own webapp framework; Java support came years later.

Can you give some examples of how that is the case? I don't know of any App Engine Services available on Java not available on Python (or vice-versa). They seem to be equally supported.

It's Go & PHP that are in "Experimental" mode. (per https://developers.google.com/appengine/)

We will never know.

I guess because Python is not statically typed. Most of the efforts they have been supporting (golang, dartlang...) are evidence of they prefer to have Static type-checking around.

I think personally that it might have to do with sandboxing python, so third-party apps could be run safely, stopped, restarted, etc.

Java has a granular, stable and simple byte code, Python does not. Java is amenable to static analysis, mainline Python isn't. Dynamic typing means more runtime, burns more battery.

Java also allowed them to leverage a mature and highly optimized frontend. Back in 2008, Psyco/PyPy was there... but fairly wet. Until recently(?) the primary JIT back-end for PyPy was, in fact, still the JVM.

> Until recently(?) the primary JIT back-end for PyPy was, in fact, still the JVM.

This sounds false. The PyPy Features page does mention that PyPy will run on the JVM, but that it is incomplete there, and in particular they don't have their JIT ported to it yet. Do you have any source on that?

PyPy has had experimental backends for JVM, CLI and LLVM, but AFAIK, none of them have ever been the primary backend.

It also had a JavaScript target in the beginning. Pretty cool. But I understand why they had to drop those to concentrate on their primary RPython backend. Since building a fast, self-hosting compiler was one of the main goals of the project (another major goal being to create a JIT compiler framework for any language to adopt, which PyPy is great at but no one knows it).

I generally agree with everything you're saying. But as a counterpoint, Dynamic typing doesn't necessarily have to translate to more battery consumption. Objective-C is pretty close to Python when it comes to dynamic typing (also similar in ref-counting for memory management).

Absolutely correct. Lua, for example, does fine on mobile phones. Python pushes the limit wrt to memory and battery consumption, but if you code conservatively and make judicious use of Cython or native code libraries, you can do OK. Incidentally, Python performance seems just fine for GUI programming on modern mobile phones (based on personal experience). But because of the way you have to package Python/Lua/Ruby programs, it takes a long time to open them. But once they are open, they all do fine (and Lua does fine any way you want to measure it).

As someone developing on Android, I so wish that Google had opted for native code on Android, and a native toolchain SDK, which would have allowed people to use almost whatever language they wanted: C, C++, Python, Lua, Ruby, etc. If that had been the case, I suspect most people would opt to use C or C++ for the backend, and code the frontend GUI in Python, Lua, or Ruby.

And yes, you can use the NDK now, but everything visual has to pass through Java.

I so wish that Google had opted for native code on Android, and a native toolchain SDK

100X this. Android's platform APIs are now trapped in Javaland. That is just totally inexcusable.

I sort of imagine the decision to use Java was a conservative one. "No one gets fired for choosing Java". But they forgot the memo that Java is for applications, not systems programming.

Microsoft seemed to be going down the same road some years ago with .Net, only to back out and realize the same thing. Now it's back on C++.

>"Until recently(?) the primary JIT back-end for PyPy was, in fact, still the JVM."

That's not true -- PyPy had an experimental JVM backend early-in, but the first and flagship backend has always been the RPython one.

Maybe he is thinking of Jython?

You're correct, I was muddling up the projects (I really don't use or have an interest in Python)

I thought RPython was only translated to C and compiled ahead-of-time.

You're right about that. To make a more correct analogy, I should have said that the main target has always been C, which RPython "transpiles" into. So the original and primary target has always been portable C, but there have also been experimental JVM, CLR, and JavaScript targets.

I think this decision was made by Android Inc. before Google purchased them.

By providing a true API-compatible JVM implementation, they did the opposite of "foisting" -- they provided a way for you to run any JVM-compatible language you want. That, after all, is why we can run Clojure, Scala, and what-have-you as first-class languages on Android with access to all the same APIs as Java.

It is true, of course, that they chose Java as the default language for Android development. I imagine this is because dynamic languages were not always practical on early smartphone hardware, and because there was already a large ecosystem around Java from which they could draw.

Google should use Go for Android... Cleaner than Java, faster than Java (on Dalvik).

I can imagine how slow Python on ARM Android is.... and people complain about Java code being slow on Android... I would put money on JS/V8 being faster than Python on Android too.

The following comparison is JVM vs Python, so its really pretty far off the scenario we are discussing, but consider it shows almost up to two orders of magnitude difference..

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

Non-portable. While android primarily runs on ARM boxes, the same APKs, barring any native code libraries, will run on x86 devices running android, MIPS devices, etc.

Compile on install? Compile to something else then compile to binary? PNaCl?

I would go with "compile on install"

Make Dalvik/JVM a compile target for Go? There is at least one project working on this.

Go is portable... you just need to compile on the target. Go is write once, compile and run everywhere. Compiling would be part of the app install process; Compiling Go is much lighter than compiling C anyway.

NDK also lets you compile one binary for all device architectures now as well.

I think Google should require every app that uses the NDK to provide ARM, x86 and MIPS binaries.

Google should've never cared about making Android work on x86. The ARM environment is an order of magnitude more competitive than the x86 one. So it's not like they need it for the "competition". If they'd like to have Android on PC's eventually, well they don't have to worry about that either, since ARM is disrupting Intel anyway, and will be the architecture of the future, being pushed by both Android and iOS, the most popular platforms right now (and even Windows is promoting it, although in a smaller way).

There are MIPS android devices too, I have one and it works well except when people write junks of their app in C and didn't upload the MIPS binary. Maybe with the recent POWER announcement we will see POWER devices.

Its not clear if the python code was compiled on their benchmarks. That might close the gap.

On the tests where Java was much faster, the Python solutions took minutes. Compilation would not be a big deal compared to that.

It would be great if Go could be used as a reasonable alternative to Java on Android. Or Clojure. Or Python. Or Lua.

You can already use all of these on Android, but any kind of visual programming is a pain in the ass since you have to do Java interop, and start-up is slow because of the apk unpackaging requirements.

Guido was working at Google and he (I understand) try to "fix" the problem. He was told to back off and when asked about it during one of the PyCons the reply was "it was political" not technical.

Moreover it wasn't just that he answered but also how he answered. One could tell he was upset by it, you could hear it in his voice.

Can you pull up any sources for that?

They're relating their own experience. They are a their own source.

I saw the talk. Guido's answer and tone is characterized correctly.

http://www.youtube.com/watch?v=EBRMq2Ioxsc

Question on mobile/Android starts at 42:30: http://www.youtube.com/watch?feature=player_detailpage&v=EBR...

See below someone someone posted the video

Even more interesting is what the Android guys had to say about getting newer versions of Java. The tone is very suspect and it almost sounds like they are considering another language. Perhaps that's just me reading into it.

Source: http://www.youtube.com/watch?feature=player_detailpage&v=A5O...

http://www.youtube.com/watch?feature=player_detailpage&v=A5O...

Check wikipedia: Android was bought by Google, not created. Also, a critical element of its success was adoption by partners: in this context, preferring Java (very much the "enterprise language") over Python (hackish open-source language with minuscule enterprise presence) was a no-brainer -- hence the "it's political" answer Guido himself got from the upper echelons.

As a python-aficionado, I stopped kidding myself a few years ago: Python will never be mainstream in the way Java or C# are, the number of people working with it will always be small, unless something dramatic happens at the commercial level. It's like Linux on the desktop: the masses are simply elsewhere.

Im saddened by this. But on the other hand, our good friend Oracle is trying to change it by trying to motivate developers to search for a non-Java language.

Trust me, Python is doing very well at Enterprise scale. Here's a taster of what it's about in the below links, which are public information, but the Quartz platform is huge. I wish I was at liberty to discuss it in more depth. If you're keen on Python and willing to work hard, it's worth considering Bank of America Merrill Lynch.

https://us.pycon.org/2013/schedule/presentation/155/

http://careers.bankofamerica.com/JobDetails.aspx?SearchPage=...

Take this with a grain of salt. I found working on Quartz to be much more miserable than any other platform I've ever worked with. Of course, that had to do with a lot of factors that weren't related to the language.

I think they answered that question, and you can probably find it with a Google search - but the reason was this: Python was too slow, especially for the time, which I think is already an uncontested fact.

But for the future? Yeah, I can only hope Google is working on switching Android to Go in a few years. It doesn't even have to be an abrupt change - which definitely won't be - they're not insane. But they can add the language in the NDK or something, and then just promote it to developers as the main language they should be using when making new Android apps.

How the hell does drivel like this get upvoted?

Just having gone through about 18 steps to install Python 2.7 on my server because we have code that only runs in 2.7, while most of the operating system only works with 2.6 and breaks with 2.7, and seeing all the backwards compatibility cluster fuck that is Python3k, I think anybody would be crazy to base an operating system like Android on Python.

You can't have backwards compatibility and your progressive "keep language simple and clean by dropping features" at the same time.

Whis OS is this?

CentOS6. Partly just expressing frustration on my part, but definitely sours my view on basing things on Python for something where stability is a priority. On the otherhand, virtualenv is a god send ....

virtualenv is your friend

Compare this with the late PyS60, where you installed a little SIS on your phone, 2MB or so, and could then run simple Python scripts. Forwarding all incoming SMSs to another phone number was a six-liner or so.

I've never used it to build big apps, only toyed around with examples, but then again, it wasn't made for the big applications, rather for small ad-hoc scripts.

Kind of Eclipse plugins vs Emacs scripts.

I don't use Android devices, so I wouldn't know, but is this the first instance of mobile Python on Android OS?

Jailbroken iPhones have had this capability for years...not to say iOS is better, just that I'd expected this would happen...sooner?

That said, the Python distro on iOS is only 2.6-ish, not even 2.7, and there's no 3.x release there. It's not very useful but I guess I did use it a lot for learning back then.

Jython won't simply run on Davlik unmodified. Davlik is a brand new VM target for language designers, and Google hasn't put much effort into making it easy for other languages to run on it.

Isn't there a tool that translates Java bytecode into Davlik byte-code (dx I think). Even if not, we have functioning decompilers to go from Java byte-code into Java source-code, and a well maintained toolchain to go from Java-source code to Dalvik byte-code.

In fact, you don't even need a Java decompiler to do this. All you need is a backwords Java compiler. That is, one that treats bytecode as a source languages and compiles down to Java. This is a much easier process because (ignoring things like Enums) you don't need to try and figure out what the original code is, and instead can just do a naive decompile with optimization passes.

There's been some Jython ports to Android in the past, but all are abandoned as far as I know. There were some problems with performance as well and the dynamic nature of Python.

I know there's a maintained JRuby project[1] for Android though.

[1] http://ruboto.org/

And there's also Myrah, a Ruby-like language that can produce Dalvik bytecode. I've been meaning to try it out for several years, it looks pretty promising. It's basically typed Ruby.

Haven't heard of Mirah, but looks like it's still updated and maintained so that's a plus. http://www.mirah.org/

> is this the first instance of mobile Python on Android OS?

Honestly, I have no idea. But I'm aware that there are multiple efforts to bring "sane" languages (such as C#, by Xamarin) to Android, others than Java.

> Jailbroken iPhones have had this capability for years

I had no idea about this one, but I don't follow iOS development either.

> I'd expected this would happen...sooner?

I agree with you, but I believe this sort of thing should be backed by Apple (iOS) or Google (Android) themselves.

[EDIT]: formatting

Well, I hope it's being done securely. I don't know much about the particulars of Android's iOS, but having a low-level language with access to the whole OS (which is what a real user would want for mobile programming, really) could be dangerous for native security.

On the other hand, if Google or Apple backed a high-level scripting language like Python, that could also lead to security concerns, but I would feel safer with that than something like C on my mobile device.

Android already has C. The only difference is that the public C API is relatively minimal, so to do anything useful you need to go through Java.

In what scenario do you trust random C code more than random Python code?

Unintentional security mistakes are much, much easier to make in C than most other languages.

EDIT: Sorry if this came off as a little harsh, but I guess I'm curious as to what you think the security advantages of C over python are, when everything I've heard says the opposite.

Reread my comment...I said I felt safer with Python over C.

I'm well aware that, e.g. a buffer overflow is something you'd want to worry about in writing C code. I guess I worded my comment strangely? I said I would "rather have that" than C, to which I was referring to a high level language like Python.

My apologies, somehow my eyes skipped over "that than" in the last sentence.

S'alright :)

Python has been on Android for a long time. The first instances I know of is SL4A: https://code.google.com/p/android-scripting/

Kivy for Android has been around awhile as well.

Kivy developers are the primary movers behind Python for Android. Typically we are using Cython so that a great deal of the application is actually running in C without the Python runtime eating up overhead. This leaves a budget of about a million function calls per second, or roughly 10,000 per frame, as most of the overhead in the UI thread is eaten up in expensive function stack frame in the event system, passing around events that call callbacks that call callbacks that call callbacks...

It remains to be seen if we can adopt a concurrent model for some aspects of the main application thread(s). Going concurrent almost surely means more Cython and more speed. I'm interested if anyone has any ideas about using CPython to reduce the cost of certain nearly-always-performed functions to grease the event system. Not that it's slow, but fast is always better =)

http://kivy.org/#home

Nope, you've been able to run python scripts on your python phone for years. What this seems to do is make it easy to package together an app written in python into an independent package that you can install just like any other android app

> Jailbroken iPhones have had this capability for years

As have non-jailbroken ones. I have Python for iOS and Pythonista (my preferred favorite) from the App Store. Python for iOS even comes in a 3.2 flavor.

http://qpython.com/ has been around for a while.

This is really cool!

I'm interested in creating daemons that, for example, forwards SMSes to my email and records made voice calls. Is API good enough to do that?

Yes. Daemons are the one implementation where Python's longish start-up time on Android won't make any difference (we're talking a few seconds here, versus under a second for native Android apps, just to be clear). If anything you need is missing from the API, you can use Pyjynius to do easy Java interop.

Another options for this kind of app is SL4A. They have a very complete Android API, but it's a bit harder to hack and not as well documented.

If you want to package an APK, I think this project (Kivy's Python for Android) is probably a slightly better option. You can package APKs with SL4A, but it's a bit trickier. Python for Android even provides a virtual box image of Ubuntu (or Debian, I don't remember) for building APKs, with all the dependencies included, ready to go.

So I'm good to go. A pretty big challenge for me, but I will handle it at some weekend for sure! :)

Reply on news.ycombinator.com