Android Developers Office Hours: Project Butter

Uploaded by androiddevelopers on 14.08.2012

>>Trevor Johns: Hello everyone. My name is Trevor Johns and this is Android Developer
Office Hours for the week of August 1st, 2012. This week's topic is smoothing out performance
in Android UIs with our special guest Romain Guy. Also with us today is Alex Lucas and
Roman Norik via video from New York. So, for those of you joining us for the first time
we hold this channel every Wednesday at 2pm Pacific and our goal is to answer your questions
about Android app development. If you're watching live, feel free to hop onto our Google Plus
hangout where you can ask us questions either via video or if you don't have a webcam, audio
and text questions are perfectly acceptable, too. We also have a moderator page that we
use to vote on questions beforehand. So we're gonna go ahead and start by reading off the
top of that list and as we go along live, you guys are certainly welcome to vote on
the question you think we should answer next. So, let's go ahead and get started. First
question from the moderator queue, this is from Drew H. in Wheaton, Illinois and he asks,
"Our app is having issues with Hebrew text and vowel points rendering to the left of
the center rather than directly below. Is this a bug with Skia? And is there something
we can do in our app to fix this?"
>>Romain Guy: So, I have an answer for that. It is kind of a bug in Skia
[Techno music playing] >>Romain Guy: kind of a bug in the open [indistinct]
pipeline and kind of a bug in the framework. The issue that's interesting to you is that
we don't really support, as of Jellybean, vertical positioning of glyphs are with the
complex, uh, complex character sets. This is something we've been working on and have
already fixed this issue internally so a future version of Android will have a much better
spot for that and should actually work in the next release of Android.
>>Trevor Johns: Okay, excellent. Thank you. Let's go ahead and move onto the next question.
So this one comes from Achile from Ashburn, Virginia and he asks, "Why are objects in
auto in boxing not recommended?" That's two questions, not the same. Why are objects not
recommended and why is auto in boxing not recommended? I'm not sure that's entirely
accurate so, Alex, I know we were talking about it before.
>>Alex Lucas: Yeah.
>>Trevor Johns: Do you wanna give a little bit more feedback for or a bit more of an
answer on this?
>>Alex Lucas: Sure. Okay, so, uh, to address them both individually, why objects are not
recommended, it's not so much that we're saying don't use objects it's the Java program. It's
an object-oriented program.
>>Trevor Johns: The Android framework itself is full of lots of objects.
>>Alex Lucas: Right.
>>Trevor Johns: Objects are not, in themselves, the bad thing.
>>Alex Lucas: Right. What we're really going for is don't use object gratuitously where
you can, where you could do just as well with a primitive type. For instance, you can pretty
easily replace enums with simple integers. That's just a static constant integer.
>>Trevor Johns: Right. So for those of you that don't know, if you do use an enum in
object, or in Java, that does get translated into a full fledged Java object which is a
lot of overhead for, if all you want is something you can [inaudible].
>>Alex Lucas: Right. And then if you have a large collection of objects that have, that
each have an enum property attached to them or something that is another large collection
of objects. If using enums instead of just normal integers. So we're really just saying
don't use them, don't use them gratuitously or excessively. For auto boxing, it's more
or less the same thing because if you have a large collection here iterating over and
auto boxing is going to create integer objects like, [indistinct] so, where just a normal
integer would work fine you're gonna be creating objects on the fly in the loop and it's gonna
be pretty wasteful and slow things down a little bit and use up way more memory than
>>Trevor Johns: Right. So, one, one or two auto boxings here and there are probably fine.
>>Alex Lucas: Right.
>>Trevor Johns: But you probably don't wanna do it inside the loop. Every time that loop
goes through iteration, you have another object to create. Oh yeah.
>>Romain Guy: The one thing to remember is that you should only avoid using objects and
auto boxing in [indistinct]. So, in [indistinct], draw, measure or if you have your own custom
algorithms to move, you know, fast. But in listener, when you click on the button, it's
okay to create an object cause that's not gonna happen very often. So it's up to you
that you would understand your application and you know, like, what pieces of code aren't
called very often and this is where you have to be careful. And, also, we offer you many
APIs to avoid creating objects or to help you to reuse objects. So, for instance, if
we are talking about auto boxing, they often come from using integers inside of hash mat
when instead you can use the sparser way, classes we have that lets you avoid the auto
boxing and give you the same features and benefits of the hash mat.
>>Trevor Johns: Alright. So, I think that's pretty well covered, so, let's go ahead and
move onto the next question. This one's coming from Martin S. in the Northwest UK. He asks,
"What are the best tools for tracing performance issues? I have a slight pause when starting
activity and I can't seem to track down the issue." Um, Romain, you wanna?
>>Romain Guy: Yeah. So we have two tools that, well, three tools you can use in SDK that
you can use to track performance issues. The first one is called Trace View. Trace View
lets you profile the direct code inside your application and you can see how much time
you spend in every method in your application. You can also use Systrace, this was introduced
in Jellybean. The best I can recommend if you want to know more about Systrace you should
look at the Google IO video that we posted a couple weeks ago where we presented the
tool a little bit. And you can also use the DDNS application tracker if the performance
issue comes from the garbage collector then DDNS will help you figure out where you're
creating objects and why and then you can fix that. In your particular case because
it happens when you start the activity, there are two things you can do, you can either
go into developer settings and set your application as the debuggable application and then there's
a checkbox you can turn on that tells the system to wait for the debugger before detaching.
So you can basically let your application wait until you're ready to start debugging
and as soon as you're ready to start debugging you can start tracing so you can capture the
startup of your application. You can also use Trace View from code in Android.OS.debug.
We have two methods, start method tracing and stop method tracing. So you can program
it to capture a trace that then you can open in Trace View. So if you just start from a
shell, Trace View and then pass it to the trace file, you can open it and this is a
really good way to capture only a very specific spot of a life cycle of your application and
this is actually something we do a lot internally, we use these methods to capture the start
up of our apps and see where we're spending time.
>>Trevor Johns: Okay, thank you. So, um, unless you have anything else to add on that, Alex,
I think we can go onto the next question then. So, this question is from Feetie and I believe
this was actually just voted up. So, "What parts of an application does the Jellybean
application encryption protect? The developer change log mentions application assets and
this is a bit unclear. Is it possible to disable this encryption for an application?" So, I
don't think we actually have any experts on the encryption process here, so I'm not sure
we can go into detail as to what's protected precisely. If somebody does know, feel free
to jump in, But, I mean, the overall goal is to make it so that once an APK has been
sent to a device, it's not possible for you to go and casually copy that off a device.
The idea being if you get an APK from Android, excuse me, for Google Play, you know, we don't
want you to go and copy that, um, onto some site where it doesn't belong. So, exactly
what is encrypted is less important than the fact that the APK can't be removed from the
device if you're getting it through Google Play. Now, I'm actually not sure, but Reto,
you might know this one, do we usually, we use encryption even for free apps, correct?
>>Reto Meier: Yes, I think that's right.
>>Trevor Johns: Yea, that's what I thought. So, for anything you're getting through Google
Play, um, it is going to be encrypted. That said, if you really do wanna go and distribute
your app, um, in a way that is unencrypted, you're always welcome to use the application
developer to go ahead and publish the APK to a website. APKs that are produced through
the Android developer tools are not encrypted. The encryption is a side effect of loading
them on through an application store such as Google Play. So, users will still be able
to side load your application if you choose to publish it and then encryption isn't an
issue. Alright, um, so I think that covers that one so let's move on to the next question.
So, my tablet was locked right there, [Laughs]
>>Trevor Johns: So this one's coming from Michael, "What's the best way to [indistinct]
large images? I received an 800 by 600 jpeg with 8-15 frames per second. Currently I create
a bit map with bit map factory in draw and the [indistinct] method with canvas dot draw
dot bit map. I added [indistinct] and panning but it doesn't feel smooth. Is there a better
way to go about doing this?
>>Romain Guy: Um, so, there's no simple answer to this question and as often as [indistinct]
the real answer is it depends. So, the question is a little too vague to give you a real answer.
So, for instance, are you applying color filters to the bit map? Are you using alpha? Are you
scaling the bit map? Are you decoding the bit map in the Android method? In which case,
that would be a big no, no. On what kind of device are you running? Are you using acceleration?
So without having the answers to those questions, I can't actually help you. The best I can
tell you is to use Trace View [indistinct] use Trace View to see where you're spending
your time cause maybe you're not spending your time in draw bit map, maybe it's somewhere
else. And, yeah, without knowing more about the app it's really difficult. But you should
be able to draw such a, such a bit map, like this is not a big bit map and, actually, the
size of the bit map doesn't matter as long as you're not scaling down to a very tiny
size. So, there must be something else going on in your application.
>>Trevor Johns: Alright, so our next question comes from a mysteriously named person named
>>Alex Lucas: Actually.
>>Male #1: Actually, is that a live question from the hangout and we'll put them on air?
>>Trevor Johns: Oh, excellent. Yes, let's go ahead and we'll get to X's question in
just a moment. So, uh, hey Roman.
>>Roman Norik: Yeah, so my question on, of course I'm trying to stay up to date on the
APK and SDK tools when the new versions come out. For example, I saw there was a 20.0.1
release and it's not listed in the news, the tools, the developer site. What's the best
way to keep up to date with what has been released?
>>Trevor Johns: Okay, so as far as the major releases, we definitely announce those both
on the Android developer's site, as well as the Android developer blog. Now,
it's always possibly that you can overlook, say, a minor release. For example, 20.1 or
20.1.1, so, you know, depending on the extent of the release. And we usually don't announce
those because there's really nothing, really note worthy about them. It's probably some
minor bug that was found that, for whatever reason, is considered important enough to
merit a fix.
>>Roman Norik: Okay.
>>Trevor Johns: So usually the best way is to just periodically run the SDK manager and
then it'll flag those updates automatically. But, of course, besides the stuff that's released
as part of Android open source and from Google, there's a lot of other companies that can
release add ons as well. There's someone there from Intel, from Samsung, from HTC, so there's
a lot of sources to keep track of. Definitely you wanna keep track of the stuff from Android
>>Roman Norik: I was going SDK manager but it wasn't showing up on there and I finally
turned it off, I like closed it out and rebooted, turned back on and I found it and I've since
then disabled caching, see if that's gonna do anything. Not cache what's out there.
>>Trevor Johns: Yeah, but is there a refresh option in the file menu?
>>Roman Norik: Yeah, there is.
>>Trevor Johns: It's possible that, yeah, there was just some cache data locally that
was causing a problem. It will eventually pick up those changes, though, so.
>>Roman Norik: Okay.
>>Trevor Johns: If you just launch it periodically that's probably the best way to watch out
for those releases from smaller releases, both from Google and everyone else.
>>Romain Guy: Do we announce the new releases on the Twitter account and the Google Plus
accounts that we have for Android developers?
>>Trevor Johns: Uh, not usually. So, unless we noticed a really big bug then we might
mention something. But if it's just a routine, just a routine patch to, you know, to one
of the existing major releases, we don't advertise it.
>>Roman Norik: So the previews for 20 were coming out, yeah, the preview for one, two
and three and that was nice and then 20.0.1 I was like, okay you changed the [indistinct]
file. [Laughs]
>>Trevor Johns: Yeah, that said, you know, I definitely hear what you're saying there
that maybe we should advertise these a bit more. So I'll pass that along to the rest
of the team
>>Roman Norik: Okay.
>>Trevor Johns: maybe we could just, you know, post something to Google Plus, probably doesn't
warrant a full blog post if it's just one change but Google Plus is probably a pretty
good medium for that. So I'll, actually Reto's right here, he manages our Google Plus account
so he probably, you know, consider the feature request filed.
>>Romain Guy: Thanks a lot, Reto. [Laughter]
>>Trevor Johns: Alright, so, let's go ahead and now go onto X's question.
>>Alex Lucas: Actually before you start I should point out that Michael, whose question
Romain sort of answered generally, if he's listening to the hangout or if he's on, Michael,
feel free to just pop in the hangout and gives us more specific information and we might
be able to give you a more specific answer.
>>Trevor Johns: Yes and that applies to everyone here, um, if we're answering your question
we'd certainly love to see you online and, again, even if your question is on the moderator
queue, you're still welcome to hop on and ask us a question live.
>>Alex Lucas: Right.
>>Trevor Johns: Alright, so, next question here. This one is targeted directly to Romain,
so X asks, "With ACS, Diane mentioned you did some selective enabling and disabling
of hardware acceleration for the Nexus S. How, if at all, did the butter optimization
story change with Nexus S? Are there any additional performance tips for lowering devices on running
Android 4.1 or above?"
>>Romain Guy: So, Project Butter and Jelly Bean didn't change much for Nexus S. The main
reason why we disabled the hardware acceleration in some, not even some apps, it was parts
of the system. For instance, I believe that it was disabled in the status bar and the
keyboard, we did that mostly to save ram. The Nexus S doesn't have that much ram compared
to other devices and on that particular device, every time we bring up the driver in an app;
it takes about 6 to 8 megs of ram. So, when you multiply that by the number of processes
we have it starts getting very costly. We did a lot of, you know, changes in the system
where we tried to be very aggressive about releasing the memory, make sure the memory
is used by the GPU but, you know, in places like the keyboard where we don't need to redraw
at 60 FPS, we just redraw when you type a key. It wasn't worth it to enable hardware
acceleration. And, actually, I think the keyboard might be using software on Nexus 7 or the
next Nexus. So, yeah, that's pretty much all there, all there is to it. So, preferences
for lowering devices, I would say, like, watch memory usage. Usually the power of those devices
scales down with the size of the screen, so you don't have to worry too much about graphics
performance cause your [indistinct]. So, it's really about how much memory you're using.
And, again, without, I can't really answer that question without more specific details.
>>Trevor Johns: Alright, so and, again, if you are watching live, feel free to watch
on and give us some more details. So, moving on, next questions from [indistinct] in Palo
Alto. And, the question is, "What is the best way to have low latency touch in games using
GL surface field? Should I register choreographer.postframecallback and then consume all motion events I've received
in the activity thread at that point?" I'm guessing this is gonna be another question
for Romain.
>>Romain Guy: Yes, so that's actually where you should probably do it. It's actually the
UI itself works. So we synchronize the drawing this sync and at the beginning of the frame
we consume, we process all the events that we actually did since the last time we drew.
So this is very similar with what we do in the UI. What might happen, though, in your
particular case is you might get one frame, one extra frame of latency because you will
have to request for render on the GL surfaces thread and if you want that render to be synchronized
with this sync, you have to postpone it to the next frame. And this is one of the reasons
why, for instance, we haven't tried to do multiple, to move the rendering off to a separate
thread in the UI docs because we can add an extra frame of latency. So, you can give it
a try, see if it helps and if it's not disabled then let us know. We can try to think of other
ways of doing it and you can add an APS in the user forum so you guys can do that kind
of things. And if it's not possible at all then, by all means, do that and that's what
choreographer is for.
Trevor Johns: Okay, excellent
>>Male #1: Hey, Trevor, I've got a question from the hangout
>>Trevor Johns: Sure.
>>Male #1: from someone who left but I'm gonna ask it for you guys anyways.
>>Trevor Johns: Sure, go ahead.
>>Male #1: the question is, "I've seen some apps use a sideways action bar, is this recommended?
It feels like it may offer some extra or better functionality."
>>Trevor Johns: Okay, so, a sideway s action bar, I'd imagine, is literally an action bar
that's oriented vertically along the sides of the screen.
>>Romain Guy: I think it's what we [indistinct]
>>Trevor Johns: Right, that's what I was thinking as well, too. So I think the answer there
is that it's not a recommended pattern at this time. We do go in and periodically revise
our UI guidelines so at some point in the future we may or may not decide that that's
a good idea. But, right now, the official recommendation for action bars is either one
action bar at the top or the split action bar where you have an action bar on the top
and the bottom. So then, of course, you can do things like throw tabs and everything else
in there too. This is very similar to a question we've got in past weeks; too, about some apps
like Google Play I believe does this, YouTube does this, Google Plus, where when you tap
the up button it'll cause an additional fragment to slide out from the side of the screen with
navigation links. And our answer there was the same, we're evaluating it. If you are
ambitious and wanna go and try new UI paradigms, it's always something you can consider placing
in your app but right now it's not an official recommendation and you're actually gonna have
to add quite a bit of code to make that work, too, because there's no libraries to go and
render that for you.
>>Alex Lucas: So, not discouraged but not recommended.
>>Trevor Johns: Right and with our UI things, our things involving UI, our guidelines are
just that. They're intended to help guide you towards what the correct solution is and
by no means there are hard rules. In the end it really is, the question really is what
makes your application provide the best user experience which is something you have to
look at the big picture. Does it blend in with the system? Does it make sense? Is it
intuitive? Does it look nice? All of these things are things that you need to consider
as a UI designer, so. Actually, we have Roman on the other end. Roman, do you wanna go and
provide any more feedback about this?
>>Roman Norik: First, can you guys hear me?
>>Trevor Johns: Yes, we can.
>>Roman Norik: So, the person that asked this question is actually back on, Achile is here,
Achile do you wanna kind of elaborate on your question live?
>>Achile: Uh, yeah, I just think that I used the contextual action bar, top and the bottom,
like on the bottom, but it seems like that it would get in the way. I'm writing a notes
app, so it's seems like that would get in the way of the, like, the actual writing with
the palm rest and stuff. It's gotten in the way when I've used it. So I just figured if
I could put a sideways action bar it might actually help.
>>Roman Norik: So I think, uh, in some apps, especially in apps that they require interesting
interactions that aren't just, you know, single touches or basic gestures, things that sometimes
require the full screen like drawing. If it's something complex like that then you shouldn't
be limited by our patterns, you know, if you wanna have actions along the side, you know,
it may make sense. One of the things to watch out for, though, is to, is to get a, kind
of establish a balance between what looks like system stuff and what looks like custom
app stuff. If you make, and this is potentially kind of unintuitive, but if you make something
that tries to resemble the system graphics too much, um, it may be, it may feel a little
out of place. Whereas, if you have something that's kind of, potentially, styled in your
own way and it's a sideway action bar, it may make more sense. So I think that it can
work and in a lot of cases the interaction is correct there, it's probably better than
having things on the top and bottom but it's definitely something that requires some special
thought just to figure out, you know, what's the right balance between, you know, establishing
pattern or established patterns and what's really intuitive and useful for the user.
>>Achile: Yeah, I'll probably keep it with the system, normal system UI if I end up doing
it just to avoid, like, confusion with the user.
>>Roman Norik: Sure and another thing to think about is, you know, you can always show and
hide things. So one of the things that happens in video playback, for example, is that all
the controls, the system bar, the action bar, the status bar, all that stuff can go away
with a single tap. And, actually, there was some new APIs in Jelly Bean which made this
very easy and made it, uh, made the layout very consistent and stable, actually I think
that's the name of the API, stable across changes to visibility of things like that.
So you may want to consider doing that as well.
>>Achile: So lights out mode, like I think that's what it's called, that's only available
in Jelly Bean?
>>Roman Norik: No, so lights out mode is actually available with Honeycomb and later, or later.
But Jelly Bean introduced some new things for devices like the Galaxy Nexus and the
Nexus 7 that have navigation bar, a navigation bar at the bottom and top. They introduced
the new APIs to make your layout work even better with that. So it's also the set system
UI visibility API but there's some new flags in there that make it even better. So, I'd
look into that.
>> Achile: Okay, thanks.
>>Alex Lucas: One thing I would also note is like, as Romain mentioned, if you have
a vertical action bar it's gonna be a, adding this might become an issue because if you're
left handed and it's on the left hand side of the screen, like, your palm is naturally
gonna fall on it a lot. So I would say, like, if it's going to, actually handedness in general
becomes an issue with vertical action bars in touch screen interfaces. So I'd say at
least have the option of moving it to the other side of the screen.
>>Romain Guy: Or to the top [indistinct]
>>Alex Lucas: Yeah, or stick with the top cause your hand won't quite, you don't rest
your hand on the top of the screen.
>>Trevor Johns: You also have to keep in mind, too, you do have the, uh, the system bar at
the bottom which has the home button. So, if your UI is likely to touch an action bar
at the bottom of the screen, it's just as likely to touch the system bar as well, too.
So, and unfortunately you don't really have the option of moving that. So, that's something
you have to be aware of as well. Alright, so, do we have any other live questions or
should we go back to the moderator? Alright, so back to the moderator it is. So, the next
question comes from mons-, actually the next question is, my battery's dead.
>>Alex Lucas: Romain with set it up.
>>Trevor Johns: So, I have the next question. The next question is they were, the person
was looking at intents service and noticed that the intents service code was creating
a handler and setting the, uh, the priority for the thread normal instead of background
priority. So the question was what's the recommended approach for background services? And I think
as a side question is, is that a bug? So, at least on my end I was taking a look through
the source code earlier and I didn't actually notice any calls to go and set the priority
within intents service dot Java. So I'm a little curious where in our code you saw that
behavior. But as far as with the recommended practices, Romain do you wanna go and provide
some detail there?
>>Romain Guy: I think the recommend is that you, by default, is using the default menu
is exactly what you want. And we give higher priority to, for instance, if there's a UI
in the foreground the user into interacting with [indistinct] prior to that. So you don't
necessarily need priority background to get a lower priority than what's happening in
the foreground. I don't, I'm not very familiar with intents services so I'm not sure what
the priorities should be, if it should be background or default or anything else but
I would say that given that Diane wrote that code, whatever is the default part is probably
what she meant it to be. But, of course, we should ask her in case and see if maybe there
is a bug there. I wouldn't worry about it too much.
>>Trevor Johns: Alright, awesome. Um, so, sadly I can't find a charger anywhere here
so, yeah, let's do this. I'm gonna read off your laptop. So, yeah, so, yeah, so the next
question is, "With the voice search app on the Nexus S, it seems like the UI animation
interface can't keep up with the audio input and response, so jenk. So do you have any
insight into the most likely cause or tips on how we can avoid the same pitfalls?" And
this is from an anonymous user.
>>Romain Guy: Uh, okay, so I will be annoying with my answer again. So, once again without
knowing more about exactly what's going on inside the app it's very hard to, to give
tips. And I don't quite understand when this jenk is happening but my guess is that it
is something like if you are, do we have real time answers like, in voice search? As you
speak do we give you real time?
>>Trevor Johns: Yes, on newer versions. If you're running Android 4., I wanna say either
4.0 or 4.1, I think it was 4.0, uh, so that's Ice Cream Sandwich, we added real time voice
>>Romain Guy: Well, I mean, there can be several levels of jenkiness here. It could be the
UI because the missions are too complicated or it's too much work for the system or maybe
it's just the time it takes for the audio to be sent to our server, processed and sent
back. So I'm not quite sure what part of the UI is in part here. If the person who has
the question can join the hangout and give us more details about what's going on and
what they're experiencing then maybe we can try to answer the question. But, as always,
I would say use Trace View. You can use Trace View on any app and you can see what's going
on and do that in your applications. If it is a real problem you should talk to the people
working on the voice search application.
>>Trevor Johns: Okay, great. So I now have questions again on my phone. My house has
been without power for the last couple days. I managed to blow a fuse and, yeah, my tablet
has not charged in a couple days. The fact that it's lasted this long is actually impressive.
Um, but anyway, moving back to the questions. Um, so this one comes from Vitali in Albany
New York and the question is, "What's the benefits of using an intents service over
a thread pull executor for network requests? Are there any downsides to using thread pull
executor? We found that the intents service was taking up about 10 milliseconds to start
and handle an intent, is that correct?" I'm not hearing anything from Romain so I'm not
sure he has an answer for this one.
>>Romain Guy: Well, I'm trying to remember, isn't intent service running into a separate
>>Trevor Johns: Yeah, so intent service actually does create a service which may or may not
create a separate process but it does create a separate task. So, depending on what the
settings for your app are
>>Romain Guy: Cause if there is truly a 10 millisecond delay it might just be like the
interprocess communication. But I believe that the whole point of an intent service
is to get the lifecycle management of system so you don't get [indistinct].
>>Trevor Johns: Right, I mean, even within the same process activities and services normally
should use inter process communication to communicate anyways because there's no guarantee
that that service hasn't been configured to go and start in a different process. So it's
still probably going through field binder and all of that fun stuff.
>>Romain Guy: I mean the difference here between using a thread pull and an intent service
is whether or not you want this request to happen when the app is in the background.
Cause with a service you're app might live longer in the background and not get killed
so you can still execute things on your intent service. Whereas if you're using a thread
pull executor and you're not moving that into your own service then it's more likely to
be killed. So if you want to wake up your app, you know, every few minutes or every
half an hour to make a network request, you'd be better off using the intent service or
your own service. You can write your own service with a thread pull executor inside. It's just
the intent service is a convenient way of doing it. But, thread pull executor is just
a loadable API way to do it. It's a great way to threading. There's nothing wrong with
it as long as you know how to use it. And I know from experience that it's hard.
>>Trevor Johns: Alright, so the next question is coming from Jason and Jason asks, "Will
anybody update web view to support HTML5 video?"
>>Romain Guy: Yes, we have in Honeycomb. So as of Honeycomb, if your application is hardware
accelerated, you get full HTML5 video support. So make sure your app is either using the
target SDK14 or you're using the user hardware accelerated equals true attribute in your
manifest and then you will get HTML video support.
>>Trevor Johns: Excellent. Now, see, I thought it actually hadn't been implemented yet so
that's great news.
>>Alex Lucas: Our hardware team is so fast they'll take a future request, go back in
time and implement it.
>>Trevor Johns: That's true. Maybe you could fix the Tardis. Yeah, it's right there behind
me for those of you who can't see. Our Tardis is broken so normally questions like this
we actually can't answer because we can't talk about the roadmap for Android, right?
Until things get released, at least. But when things are already implemented that's awesome.
So, I'm glad we could help you with that. So let's move on to the next question here.
>>Male #1: Hey Trevor, I actually got a question from the hangout.
>>Trevor Johns: Ah, excellent. More hangout questions go ahead.
>>Male #1: So the question is actually regarding Hebrew. It's supposed to have been fixed as
of the current version of Android but it's gonna be awhile before OAMs actually start
introducing the latest version. So it could take up to, quote unquote, two years before
it's out there in the wild. Are there any fixes for this issue that we, that developers
can implement right now?
>>Romain Guy: Not easily. You would have to, it would be difficult, you would have to take
your library like half [indistinct] like what we use to save complex scripts and then you
would have to do your own text frame to be able to position the glyphs properly. So,
Skia on the canvas API we have method called draw [inaudible] text that helps a little
bit but it's a been broken for languages like Hebrew. So it would be, actually, pretty difficult
to do on your own. And I would not recommend doing it yourself because it's a lot of work
and it's easy to get it wrong. So I wish, you know, I had a better answer for you and
I wish I could tell you that it's been supported since 1O but unfortunately our in server,
it's gonna be in a future version of Android.
>>Trevor Johns: Okay, great. So, next question is coming from Simon M. in, no Simon M. Nancy
in France. Either that or the city of Nancy, France, I'm pretty sure it's Simon M. Nancy.
>>Romain Guy: There is a Nancy, France.
>>Trevor Johns: There is a Nancy, France? Okay, so I guess Nancy is a strange last name.
Alright, so, Simon, he asks, "Is there a way to attach a kind of selector like a stateless
drawable to a text view in order to update the text shadow attributes with touches, clicks,
photos, etcetera?"
>>Romain Guy: No, you cannot. You can only change the text color and drawables is in
the text view drawables should have drawables but you cannot change the shadow. So what
you can, though, is you can overwrite text view and then there's a method, I believe,
called drawable state changed, it's a protective method you can override that will be invoked
every time the state of the view changes and that state needs to be propagated to the drawables
so, for instance, if the view goes from [indistinct] things like that and from there you can go
change yourself to a set of attributes. I have to admit that this is not something that
we thought would be useful and I'll think about it and see if we should add that to
the framework but, you know, it seems to be, it will probably be low on our list of priorities
if we do write it.
>>Trevor Johns: Okay, great. So, um, next question here. This is from Harish from Berk,
wherever that is, and he asks, "When I run my app in Jelly Bean using the eclipse simulator
I get a warning saying choreographer skipped 2001 frames, the application may be doing
too much work on its main thread. How can I overcome this? How does it.