Google made mobile a major focus of almost every part of Google I/O 2013, and for good reason. It’s a platform that has been through a considerable evolution in a short amount of time. During the Fireside Chat with the Android Team, developers got to ask about what they can expect the future to hold for them. Though the question and answer session was full of tons of developer speak and coding language, it also had plenty of information for the average Android user. After all, they are the ones that will be experiencing the creations that come on these upcoming developments. It also had plenty of vague answers and “no comments,” making it hit or miss for real information.
The panel – consisting of Android Developer Relations lead Reto Meier, Interaction Design lead Rachel Garb, Engineering Director David Burke, Android SDK and Tools team lead Xavier Ducrohet, Android open source & compatibility tech lead Dan Morill, senior Android engineer Dianne Hackborn, Google Play Store lead Ficus Kirkpatrick, Android 2D rendering pipeline and user interface toolkit tech lead Romain Guy, Android framework engineer Adam Powell, Google Play services team lead Jeff Hamilton, and android systems team tech lead Rebecca Zavin – did their best to answer all the questions thrown their way by an anxious room of developers with more questions than a 40 minute session could hold. The biggest takeaway from any of the answers they provided was that Android is still in its infancy. At one point a panelist said “Android is a baby; there’s so much more we can do.”
As an example of how far Android has come and perhaps how much more can be done with it, the team pointed out that this is the first year computation can be done on the GPU. We’ve also seen new peripherals showing up, which essentially answered the question “Has the hardware development plateaued?” with a “no” without actually saying it. A point of emphasis for an area that could have considerable improvements to come on the hardware front was with cameras, but there seemed to be no fear that the hardware that Android runs on is out of innovation.
The panel also made it a point to explain that they attempt to make Android very agile. They attempt to come up with themes to rally around when working on new releases, so they attempt to have some uniformity when an update comes out. Proving the intention to work together, the panel explained that to create an environment where those working on the platform are on the same page, the Android team often works together in the same room. They draw inspiration from all over – “cars” and “sci fi shows” being two of the examples – and bounce those influences and ideas off one another to create a cohesive product.
Despite that, the team admitted that fragmentation – referred to by the questioner as “the ‘F’ word” – was still a problem with the operating system. After acknowledging that there is still a significant amount of Android devices running Gingerbread, it was explained that part of the reason is the emerging markets where more cost-effective phones are popular. Many of those phones have lower specs and run earlier versions of the OS because it’s less of a strain on the device. To counteract that, the team has been working to make Android more efficient so it can run smoothly even on entry level phones. Interestingly, the Galaxy S4 Google Edition was mentioned in the answer, perhaps marking that this may not be the last time we see Google offer its own version of existing devices.
Perhaps some of the most interesting moments of the chat came when the Android team was asked to reflect on the early days of the operating system. Members on the panel who have been involved in the platform’s existence since the beginning were rather open about how they would have done things differently if given a chance to go back, but it’s because of what they know now that you just don’t when starting from scratch on something. They noted that the first chipset the team worked on was the hardest to develop, and every time they work on a new architecture, new challenges reveal themselves. When asked “Given the speed at which the team develops the Android framework, looking back what would you change?” A panelist answered “How much time do we have?”and seemed to only be half joking. He went on to say the biggest thing that could have done different was to have more control over applications.”
Though there was tons of information about the immediate future of the operating system, the long term questions seemed to have more vague answers. Questions about moving Android SDK to Java 1.7 was met with an indefinite “we’re not making any decisions yet,” while an attendee wonders if there would ever be Java 7 or Java 8 compliance in Android?, the team refrained from comment, with one member stating “No one on this panel should have an opinion, and if they do they certainly shouldn’t say it.” Even a question about making Android a viable option for healthcare, an industry dominated by iOS apps, was given no clear answer. The idea of an iOS emulator was proposed by the questioner, which was dismissed quickly as it would provide “sub-optimal performance.”
One of the biggest areas of interest for members of the audience was application permissions. This is an area that directly affects just about every Android user, as some apps have opted to make certain features unaccessible unless users are willing to provide access to a particular set of personal data. As an example, an attendee pointed to a recent update to the popular reader app Pocket. The update asks for access to a user’s contacts, something that would seem unessential for the app to perform its task. None of the panelists gave any sort of answer to questions of application permission, insisting they cannot comment on taking any sort of action at this point. One panelist did note, though, that they had noticed the specific case with the Pocket update and have refused to download that update. Perhaps that is indication that a plan may be in the works.
