From left to right: Andy Rubin, Brian Swetland, Dan Bornstein, San Mehat, Mike Cleron, Grace Kloba, Dave Bort, Steve Horowitz.
Q. Should we jump in to Android? What’s the guarantee that’s what I will see on a phone? Will service providers turn off things?
A. Keep in mind it hasn’t shipped yet, This is the most interesting time. Once it’s open source, it could be locked down… they could create a derivative work.
We’re going to provide a piece of technology that tests the APIs. No time frame yet. The script will exercise the system. It’s a compatibility test suite, to make sure nothing got disabled or broken by accident, and also ensure that apps will work across OEMs.
Q. What if my app uses location api, and service provider shuts that off, can they?
A. They can do that… it’s not a perfect world. Rather than having us dictate what carriers and OEMs support, we let developers develop killer apps that will require it.
We want to ensure all the application development that goes on for Android… we want to give OEMs an incentive to keep things open. It’s a positive, self fulfilling vision.
Q. If I’m a game developer and I’m building piece of content and I want to sell it, how do I do that and realize revenue.
A. Content distribution — we’ve thought of that. It’d be great if there were a place where people could go to safely download and pay for content.
Q. What about copy protection?
A. We wouldn’t have done our job if we didn’t consider distribution.
Q. (Question from Verizon). We use SMS interception for system signalling. Is there a mechanism for an app to respond and stop the signaling chain? Is there security around that so that one vendor can’t hijack a message and respond to it?
A. There’s a mechanism where an application can register to receive a message with a certain signature and prevent others from getting it.
We have a system of permissions apps are able to declare, enforce, and require to perform certain operations. Things like dial the phone, get to contacts, etc.. But these aren’t things that are baked in the core of the system. An arbitrary app could declare custom permissions.
As far as restricting another app, the model we’ve been going by… the phone is not controlled by the application vendor, it’s controlled by the user. Whether or not the permissions are granted is up to the user that owns the phone. If you created a protocol that intercepts an SMS and another party wrote an app that intercepts the same SMS and the user wants to use that, the user could be free to stick that in.
Q. Can the user set a priority?
A. Don’t know, post your question to the developer’s community board.
Q. (Question from Media Power Group). In a previous release, XMPP was turned into GTalk. Will a future version have XMPP?
A. Goal is to have XMPP support after 1.0.
Q. Java is more than a language. Google implemented its own VM. Could we use the Sun JVM? Explain the reasoning behind having your own.
A. We can have a more efficient interpreter and less memory pressure (by having Dalvik). You have to consider the holistic system performance. We had no choice but to run multiple VMs and processes. Share read-only memory across processes was important. Dalvik does that.
Also we needed something with an Apache license. At the time, nothing was available.
Q. Does Android support the Bluetooth serial port profile?
A. Yes.
Q. Can an application be started on powerup?
A. Yes.
Q. Is Bionic (Google’s version of libc) dynamic linked?
A. Yes, all libs are dynamically linked.
Q. Does Android have USB support? External keyboard, etc.?
A. The hardware should support it but it’s not enabled in the software. Maybe in a point release.
Q. (My question). What’s in the next version of the SDK?
A. No major suprises. We’re cleaning up APIs. Making sure things are named consistently, parameters all need to be there, etc. so there’s some churn. Ensuring what goes out is something we can support until the end of time. For example protected members might go package private so we have the option of changing later.
On the system side, we’re moving towards a tighter security policy. In M5 lots of things run as root, but in the next version almost nothing runs as root. We use the minimum privileges necessary.
What we demoed at the keynote had more apps and a different user interface but the changes are minimal.
Q. Will there be a central registry for intents?
A. That shoulds like a perfect opportunity for a 3rd party developer.
Intents use package naming conventions to prevent collisions, like com.google.something.
Q. Have any advice on general portability strategies; Android, Brew, etc.?
A. Emphasize the commonality between platforms, common profile support, separation between main logic and front end interface. Eventually somebody will add J2ME APIs into the Android platform. But at the user interface level you will want to tie into platform-specific things (for the best user experience).
Access to the web is standard across all platforms.
Q. Can I deploy Linux apps on real handsets? With a modified Qemu?
A. Qemu depends on OEM or carrier. It’s possible that upgrades may have to be signed by carrier.
As far as native code goes, we don’t currently have a bunch of the standard Unix X type stuff in there. Command line stuff compiles and runs as is. Expect that once this is open sourced, people will bolt on an X server and traditional Unix/Linux into the framework. While Java is the primary development language for Android 1.0, the system has been designed to support multiple platforms including native. Also expect the Android framework to run on top of other mobile Linux efforts.
Example: Web browser WebKit is C++ based, and there’s Java chrome on top of that. For debugging I use gdb server to debug native code. JNI layer talks between C++ and Java.
Q. (From wapreview.com). Is the magnifier widget shown in the opening session specific to the browser or can I use it in my apps?
A. That one is specific to browser. It’s implemented in the native part of browser.
Q. Gears will eventually be supported on Android. Can we expect that in 1.0?
A. It’s under investigation. Can’t guarantee on 1.0 but we’d like to have it there.
Q. Do you plan to support an extension mechanism like plug-ins? For example secure web site user certificate storage is not supported, and there is no mechanism to add it.
A. We don’t have the full plug-in support. Partial MPPI support… we’re still working on it. Probably not finished by 1.0.
Note we do have the HTTPS support now.
Q. (From Tivo). Is there info on the UI toolkit, animation effects, composition, effects, and what is it based on?
A. We have a couple different approaches to drawing. We have full support for OpenGL ES, and use hardware support if it’s there. For more conventional UI, apps use the View system documented in the SDK. This sits on top of a graphics layer, Canvas SGL.
Q. Does Android compete with JavaFX Mobile?
A. The world doesn’t need another operating system. The world needs an open embedded operating system, open source. (Andy:) I haven’t seen anything that encompasses as much as Android.
Q. We do social apps. We have Javascript expertise but not Java. Is there an API running on localhost to fetch geo locations?
A. There’s a browser and a web view. If you want to write local . If you use the embedded web view you can have Java binding. Javascript calls Java in embedding app. You get your own icon, your own storage, your own world in which to operate.
Q. (From an Android software company). Will there be any Android developer events in India?
A. That makes sense but I’m not sure if any are planned right now.
Q. If a small device manufufacturer wants to run Android, can they just download it and go?
A. Once it’s open source, anyone can download and port Android without joining OHA. Android will be open source before the end of the year.
Q. (From 7 networks mobile messaging software). Can you comment on power management features? How can developers extend battery life?
A. At the kernel level, it goes into low power states even when running. Android supports wake locks. Does it at the platform level so apps don’t have to request that from the kernel. We’re trying to be smart about it. For example, a network event wakes up system, but may not even wake up the screen.
There are two classes of timers - real time timers that can trigger even when device is asleep (like alarms), and free-running timers that only run when device is awake. We’re also working on some visibility to the user, so they can tell what apps are contributing to the device being awake. We’re hoping to set some good examples with core apps, and also provide a way for the end user to see what’s keeping their device awake and be able to uninstall badly behaved apps. Similar to finding out what’s using storage space or CPU time.
Q. We’re working on seamless mobility between cell and wifi calls. Can apps trigger WiFi scanning? Search for SSIDs?
A. WiFi support, we’ve been adding. There’s the connection manager that can see SSIDs, associate, and it supports a number of authentication schemes.
Q. Can a 3rd party application initiate a WiFi scan?
A. Yes, if it has permission.
Q. I want to use native phone dialer to make voip calls, can I do that?
A. We already have hooks for that. System sends an intent, which can be intercepted.
Q. Can I intercept incoming calls too?
A. Not sure, there are security issues.
Q. A VoIP app wants to route audio to earpiece. Normally apps don’t use earpiece. Possible?
A. Post to forum or bug request. The system can do audio routing but I don’t know if it’s been exposed to top level APIs.
Q. Can apps get extra GPS data beyond latitude/longitude?
A. Don’t know if you can get access to the NEMA channel. With M5 we didn’t have full integration but the new version will have more. There’s no reason not to expose it.
Q. What is Android’s business model?
A. Somebody could rip out the Google stuff and put in Yahoo stuff. That’s ok. Our job is to continue to create killer apps that people will want to use. Google search, GMail, maps, etc.. If we ever fail to delight users our core business will go away. That’s why we felt comfortable using the Apache license.
While we’re showing demos with Google applications, but there is no requirement to use them.
Q. (From a mobile linux startup). I’m concerned about giving user complete control over permissions. Won’t users just accept permission dialogs without thinking?
A. Providing a useful security UI is something nobody has done well. We recognize that as a crucial component since we delegated the decisions to the user. We’re working to come up with something better. The #1 goal is to come up with something that provides real security for the user. One way is to educate users, to call things out.
Also we can provide info upstream about what are good and trusted applications that a community has validated as being ok.
There will be a circle of trust, communicating what other users are doing. One star vs. five star ratings.
Q. On application signing, I can’t find any tools?
A. These will be provided. Before last SDK went out it wasn’t implemented yet. Tools for signing will be built into the developer plug-in. Note: Applications will be self signed, no chain back to root certificate.
Q. How synchronous are we going to be able to get with Android?
A. We have an http stack, and you can build whatever you want on top of that. We’re not providing a general sync service.
We have sockets. At some level, 1.0 doesn’t have a general synchronization API, but there is nothing to prevent you from building an app that uses a server to talk to other instances of itself or other apps. Given limitations of network of course. For example GPRS is effectively NAT’d.
Latency is on the order of 200-400ms for a GPRS network; UTMS is getting Latency is on the order of 200-400ms for a GPRS network; UTMS is getting less than 100ms.
Q. Will Android support data from router/WiFi?
A. Yes. It’s not fully enabled in 1.0 but you can even use bluetooth as an interface (ethernet over bluetooth). Ethernet over USB too, on Linux it works great, but some driver work is needed for Windows and OSX.
Q. Can you make telephone calls over bluetooth or WiFi?
A. For VoIP, all you need is an application to do that, it’s just sockets. (Somebody please write that up) (laughs).
Q. If app is self signed, can I use GPS on a real carrier like Sprint?
A. By default, there is no central certifcation authority, so you don’t have to go thru Verisign. Permissions are not based on certificates, they’re based on what the user has chosen to give to that application.
The only thing certs are used for… if two apps are signed by the same key, then they presumably came from the same place. We use that to allow apps to work more closely, for example live in the same process. Apk’s from the same key can share a process and userid. Also we test it to allow you to upgrade an app because it must be from same source. We don’t have to ask the permission questions again (unless the set requested has changed).
Q. Can the carrier stop this?
A. It’s open source, so anybody can do what they want with it. We’re trying to make this open not just source but user control. We’re leading by example, showing it’s ok to do this stuff. Let’s show all the dangers others are trying to avoid don’t really exist.
Signing is to protect the end user. I can’t ship a v2.0 of your app and hijack your users.
“Trust the user” is one of the 10 things Google takes to be true. Give the user enough info to make good informed decisions.
Q. Any details on next round of the Android developer’s challenge?
A. For part 2… we don’t have a lot of details. It will be the other half of the $10 million, and will be after devices are on the market.
Probably early next year. (heads nod)
Q. (Andrew from MIT). We need x.519 personal and root certificates. This relates to updates once software goes out; finger pointing not to be able to push out updates to end user.
A. We don’t want to dictate to OEMs how they upgrade. Parts of the industry makes money in different ways. The technology can receive over the air and over USB updates.
Android has the ability to do very targeted updates to a running system, but also it has the ability to replace the entire world. We don’t require it but we have OTA on the entire system or it can change 1 byte in 1 file. OTA updates will be signed by a real private key unless the OEM wants to make it possible to do it unsigned.
There are 4 different types of updates: patching, complete system partition, baseband radio, and applications OTA.
Q. (Alexi from Java Fusion). Which tools will developers have to handle memory leaks, gc, profiling, etc..
A. We have a lot of hooks for debugging on the device. If you’ve seen the emulator, you can run your favorite IDE with that. It’s connected over a socket transport, and can be turned into using USB transport. The tools worked on real hardware first, and then on the emulator. We make it just as easy if not easier to debug the device itself. We encourage development on a real device.
One developer mentioned traceview, a graphic profiling tool.
We run a VM in each process. You target the debugger at a particular Java process, but you can get an overview at what other processors are doing.
Another developer mentioned he uses GDB every day for native code debugging.
One tool not in the SDK yet will give you a live dump of the views, and let you inspect the view hierarchy and the state of all the views.
Q. (From Boston university). Will Android have UMA support?
A. The platform can’t depend on it but OEMs and carriers are working on it. UMA is based on SIP, handles the handoff from cell to WiFi.
Q. Regarding OTA updates, what tools are available for the application developer to ensure the user has the right version of the platform?
A. Compatability is very important. It’s not done right now but it’s a crucial component. We have tools in place to track changes, version differences.
Q. Can application developers deploy and patch their programs?
A. Distribution is one of the most important needs to support 3rd party developers. Can’t say more strongly how important it is but we have nothing to announce right now.
Q. Can you have incoming commands from server?
A. You can have active connection without a power drain, waiting on data. Android devices are designed to be always-on devices, always have an IP address.
Q. Will GTalk and XMPP be supported in 1.0?
A. Post 1.0.
Q. How do we get Android on our platform?
A. Easiest thing would be to wait until we open source it. We’re not encouraging violation of the early view SDK.
Q. Apple says iPhone will sell 10mil by the end of year (2008). What are the projections on Android?
A. We can’t predict the future. We’re an open source software project, we’re not a phone. A lot of OEMs can build a lot of phones on that. We felt the industry needed a cross-OEM standard operating system.
A long term goal is to put Android on set top boxes, car navigation system, sensors, etc..
There are 1.2 billion internet connected PCs, and 3.2 billion phones.
Open source eliminates the barrier to entry. It reduces the cost of phones by 20%.
.. from here
No comments:
Post a Comment