Google lets you code for Googlephones on Googlephones
Android's mobile scripting kit
Cloud storage: Lower cost and increase uptime
Google has introduced an Android scripting environment that lets you code stuff for the Googlephone on the Googlephone.
It's called, well, the Android Scripting Environment. ASE, for short. It sits on the Android handset itself, giving coders the power to write and run scripts in Python, Lua, and BeanShell - without help from a PC. Google thinks that coding full-fledged Android apps on a PC is like heaven on earth, but it's still interested in giving developers the power to code on the run.
"Android's development environment makes life pretty easy, but you're tied to a computer to do your work," reads a blog post from Googler Damon Kohler. "ASE lets you develop on the device itself using high-level scripting languages to try out your idea now, in the situation where you need it, quickly."
The new scripting environment gives you access to many - but not all - of the APIs available to full-fledged Android apps. Scripts can make phone calls, send text messages, scan bar codes, poll location and sensor data, use text-to-speech, and more. As an example, Kohler shows off a script designed to prevent an Android phone from running when it's placed face-down.
Android scripting on Android
You can run scripts interactively in a terminal, launch them as long-running background services, or run them via Locale, a third-party Android app and developer platform that changes the Googlephone's behavior depending on where it's, yes, located.
With BeanShell, you can access Android's Java API directly. With Lua and Python, you tap the API via JSON RPC calls to a proxy. At some point, Google will also offer scripting with Ruby and Javascript as well.
The environment has not been published to the Android Market, Google's answer to the iPhone App Store, but the company says it will be soon. In the meantime, you can download an alpha here. The open-source project page also includes sample scripts and documentation. ®
COMMENTS
workarounds....
I agree that a properly designed system would render the workaround unneeded in this case, but even more curious is that the whole app would require to run constantly, and if that's the case, it would mean that the sensors would need to constantly output a signal for it to recieve. If that's the case, then what's the wake up for? If the app launches, then i see it, but if it is running continously, then i dont. and if you are going to turn the app on, why not just use it to silence the phone?
Maybe it's why i am not a coder.
Scripting phone fuctionality
Part of me thinks wow, that is actually an amazing feature to be able write scripts to define how the ringer/other functionality works. And the other part thinks, hmm that means surely that it might give another attack vector for doing malicious things.
Good grief people
a) Presumably the while true just adds the thing into the event loop, which can be killed by the system in standard ways.
b) Perhaps they'll introduce a blocking version of the sensor startup command as well, but if for now there's only one, you've got to prefer nonblocking to blocking, as you can simulate the latter with a sleep command, but you can't simulate the former.
IT infrastructure monitoring strategies
What you need to know about cloud backup
Enabling efficient data center monitoring
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
