7 ms·

Dianne Hackborn responds again about android graphics

87 points by brian_cloutier 15y ago

mikhael 15y ago
Probably the key paragraph, in relation to the recent discussion: > In fact it was just not feasible to implement hardware accelerated drawing inside windows until recently. Because Android is designed around having multiple windows on the screen, to have the drawing inside each window be hardware accelerated means requiring that the GPU and driver support multiple active GL contexts in different processes running at the same time. The hardware at that time just didn’t support this, even ignoring the additional memory needed for it that was not available. Even today we are in the early stages of this -- most mobile GPUs still have fairly expensive GL context switching.
- chwahoo 15y ago
  So an attempt at a brief summary of (the non-thread-priorities portion of) her post: The Android model of providing rendering isolation between apps/windows has limited hw acceleration of window contents rendering, which is a cause of some of Android's lagginess. That iOS forgoes this isolation and achieves better responsiveness is a reflection of a different security philosophy. If this is an accurate summary, it's an interesting example of how platform design is wicked problem with complex interactions between concerns that you might expect to be orthogonal.
  - campnic 15y ago
    That sounds accurate to me. I'm not sure if its simply that iOS forgoes isolation or they've implemented isolation in a mechanism that allows for the context to be shared without security consequence.
    - ryanpetrich 15y ago
      On iOS, all standard rendering is done in a single context by the Core Animation window server which lives in SpringBoard. Only when an app adds an OpenGL ES layer to the view hierarchy does a separate context need to be created. When that happens, the render graph is split into subgraphs that are rendered to surfaces and displayed as overlays (with SpringBoard rendering all the standard layers and the app rendering the OpenGL layer)
- iam 15y ago
  That might have been true before, but my understanding is that the newer mobile GPUs (coming out now, 2012, etc) have pretty much free context switching. Or so the vendors like to claim. Even if it's not true, shouldn't Google pushing for the GPU drivers to be fixed? This is a pretty obvious huge flaw [that has been pretty much solved on Desktop].
smackfu 15y ago
HN on previous post: http://news.ycombinator.com/item?id=3310301 http://news.ycombinator.com/item?id=3310301
nubela 15y ago
There is one thing that can be observed here, imho. That iOS was made to be sleek right from the start, from there they sacrificed pragmatic system design, which efficiently crimped a lot of flexibility; flexibility such as 3rd party input, etc, of which has gotta be now implemented from system up. As an Android user, given my (now) better understanding of the Android architecture design, I am happy and safely say that Android was made for the future, and is only gonna get better from here on.
- chwahoo 15y ago
  However, if iOS is able to evolve additional flexibility as it is needed without too much pain, then perhaps they made the right design choices at the start?
  - campnic 15y ago
    I agree, its far to early to make any decisions about which platform "made the right decisions". We're in the first inning still for mobile.
  - fpgeek 15y ago
    I think both Google and Apple made the right design choices at the start. They just made different ones is because they had different business goals. Google wanted Android to be ubiquitous and free to quickly evolve into whatever it needed to be to be in order to capture territory in the mobile device world. That means supporting a wide range of devices, technologies and, most importantly, partners (both hardware, software, carriers, etc.). So Android was designed for flexibility and has extension points everywhere (input frameworks, sharing, alternative browsers, launchers and so on). Google gave up performance along many dimensions in order to maximize Android's adaptability. Apple is very different. They have a vision and want to build that vision as precisely as they can because that is what has driven their success. That means Apple doesn't want hardware partners. And even at the software level, thsat means they are very careful about who and what they allow into their user experience. You can see this in how they built new features for iOS 5: Apple added a split keyboard for the iPad rather than adding support for alternative keyboards. They bought Siri rather than exposing relevant extension points. Apple baked Twitter into iOS 5 as a one-off, rather than riffing off of Android's sharing (as they did with notifications). And so on. These are all business decisions, not technical ones (as Cydia often proves). Instead, iOS's technical architecture flows from Apple's goals in the same way Android's flows from Google's.
erichocean 15y ago
The part about the graphics contexts and process limitation is key, and an area where iOS is far ahead of Android, since iOS does not have that limitation. (Neither does Mac OS X, and it took Apple years and years to get to that point -- each year at WWDC you'd see more and more of the UI hardware accelerated.)
D_Drake 15y ago
Users: Wow, android is neat, but why is the interface performance so crappy? Google: silence Users: Hmm, I bet it's X, because of ____. Google: No, no, X in android is great, it's awesome, and even if it weren't awesome it totally wouldn't be the cause of anything anyone might think is bad. Users: Ok, hmm, then I bet the clunkyness and chippiness are due to Y, because of _____ and _____. Google: No, no, Y is actually great in android; android has had Y since the beginning. Users: Ok, so why is the android interface universally clunky? Google: silence "I am not writing this to make excuses for whatever things people don’t like about Android" Dianne, don't you dare insult our intelligence by pretending the worst thing about the android experience is a case of personal preference by a small group of loonies. http://i.imgur.com/e8S63.jpg http://i.imgur.com/e8S63.jpg
zobzu 15y ago
Devil's tongue: "This is very different from iOS’s original design constraints, which remember didn’t allow any third party applications at all." This argument resume the whole article's intent. I'm not using iOS. I dislike Apple's way of enforcing it's products. But I know BS when I see it. iOS's security and sandboxing, while technically different, is practically similar to android. Each app is sandboxed. Oh and guess what, the AppStore let you install third party apps, and since before Android became Google's Android. And for the actual thing that matters, Android uses multiple GL contexts by design, iOS doesn't, so Android is slower.
- Xuzz 15y ago
  iOS has multiple processes on the system using hardware acceleration at the same time, and always has. A few examples are the system-rendered status bar at the top of the screen, or the "Notification Center" that you pull down from the top, or even the little volume adjustment popups. All of those are hardware accelerated and rendered out-of-process in the system UI manager ("SpringBoard"), not inside the app. Both of those have smooth scrolling and animations, at the same time, overlayed on top of each other. I don't think there's anything here in iOS that shows the lack of "multiple GL contexts"; and I definitely don't think that is a significant contributor to making anything slower.
- Wilya 15y ago
  Well, technically, she is right. About iOS1. That didn't have any app store, and had all applications running as root. Whether this old stuff is relevant is another matter, of course.
nkurz 15y ago
I just did an interesting side-by-side test of scrolling within a browser displaying Google on an new iPhone 4 and an older Android phone (HTC Incredible. I didn't actually see much difference as to how "smooth" or "choppy" the scrolling was, but there were distinct differences to fast motions. The iPhone seemed better at keeping up with a fast moving finger. If you put your finger on a line at the top of the screen, and scrolled quickly until your finger was at the bottom, the same line would still be under your finger. On the Incredible, the line you started on would only end up 2/3 of the way down the screen. More surprisingly, this seemed to happen to a lesser extent even on very slow scrolls. Put you finger down on a line, drag it to the bottom, and the amount scrolled is always significantly less than the distance your finger moves. Rather than being a rendering problem, this seems more like an event loop that throwing away some of the events!
- crnchyflks 15y ago
  Yep. This is a key aspect of Android scrolling crappiness, and a real schoolboy error when it comes to scrolling UIs. Once you leave the 'tap threshold' scrolling starts, but they haven't kept track of where the 'tap down' event happened, and so the experience is unsatisfactory - the illusion of your finger directly dragging the rendered surface is broken. The other thing that iOS does to improve scrolling (in the browser) is to 'cheat' by not doing anything while scrolling - so that with a large complex webpage, you end up scrolling over a vast expanse of checkerboard pattern - the scrolling is lovely and smooth though but you dont know what you're scrolling over. In Android, by contrast, you see rendered webpage while scrolling, even though this impacts on the smoothness of the scrolling experience.
- rubinelli 15y ago
  Touch gestures generate a ton of events, specially in early versions. The most common fix is sleeping for a few ms in the UI thread. http://www.badlogicgames.com/wiki/index.php/Touch_Event_Flooding http://www.badlogicgames.com/wiki/index.php/Touch_Event_Floo...
  - joezydeco 15y ago
    I have to kind of wonder if Apple is buffering touch events on their controller and then sending them onward to the UI as postprocessed events and gestures. Maybe I'm the only one left with a boggy 3G running iOS4, but when the system lags down I can usually keep typing and the keystrokes will catch up. Does the same thing happen on Android? If gesture processing is being done on the controller side, that would take a lot of perceived bog out of the UI.
mirkules 15y ago
This post basically amounts to: "There is no problem with graphics on android, it was designed to work this way because of the open nature of android, and other excuses" Well, the design is broken then. Clearly, it is possible to achieve a smooth UI as demonstrated by iOS and have a solid and stable system. This post is actually worse than saying "we can't fix it" -- it's denying a problem exists in the first place, because "hey, we do it just like iOS." Except it doesn't work like iOS. I recently went back to iPhone because I got so frustrated with Android's jerky UI on my 1-year-old phone (Galaxy S). I went back to a iPhone 3GS that runs iOS 5 faster than the Android ran Froyo (which, btw, I had to jump through 30 different hoops just to upgrade from 2.1). The takeaway is this: Android lost a customer because of slow, laggy UI, and I'm sure I'm not the only one.
- inoop 15y ago
  Java is memory safe, and classloaders have been used since forever to sandbox applications (remember applets?). The whole 'designed to be open' argument is nonsense. Let's face it, Android was hacked together by a small team on a deadline. It doesn't seem like a lot of thought went into the design and architecture of the system. The code is buggy, there are no tests, and half the tree doesn't even have comments. Bug reports are ignored, and there are about 22k open issues that are not even being triaged. Case in point: http://code.google.com/p/android/issues/detail?id=19078 http://code.google.com/p/android/issues/detail?id=19078 (not fixed in ICS) Android is a rush-job, and the team's obvious lack of experience in handling large software projects is biting them in the ass. Rather than making excuses for their botched together software maybe they should just get their shit together.
  - comex 15y ago
    > Java is memory safe, and classloaders have been used since forever to sandbox applications (remember applets?). Well, except that Android allows apps to run arbitrary native code using the NDK.
    - inoop 15y ago
      > Well, except that Android allows apps to run arbitrary native code using the NDK. I was under the assumption that they can support native code because of the way they designed Android, not the other way around. I highly doubt that supporting native code was the design rationale here. I think they just designed Dalvik to use Linux threads and assume it to run inside its own process. That certainly makes things much simpler for the VM. The fact that you can safely load native code follows naturally. Still, supporting native code does not have to dictate how you ensure memory protection, or whether each app has to run inside its own process. You can always run a native library (i.e. a video codec) inside a separate process and use memory-safe communication with the process that runs the Java app. You can also go the NACL route. There's absolutely no reason why supporting native code would result in a choppy UI on Android.
nuje 15y ago
The Android sandboxing feature is frequently invoked as providing dramatic security advantages, but there's really no reason to believe it. Local privilege vulnerabilities [edit: enabling escape from the sandbox] in Linux kernel are dime a dozen, and Android phones are notoriously outdated wrt security patches. There simply hasn't been a lot of OS level vulnerability exploitation in Android malware so far. Probably the biggest reason is OS fragmentation + malware apps can just request any privileges they need on the market and the users will haplessly click accept, and the biggest threat to the malicious apps is Google removing them from the Market when they're found out.
Udo 15y ago
It's easy to understand the point that window management in Android is complex and this complexity hampers graphics performance. On iOS, one process has the entire screen at a time. There are no widgets, no plugin viewports, no 3rd-party UI - but all this stuff is happening on Android. The question becomes whether this is actually a good paradigm to have for a mobile platform and whether this compartmentalization mechanism is really needed. For example, take this statement: "This [window management technique] is also why Android can safely support third party input methods." Clearly, the perception at Google is that this model makes Android safe, and in a way that's understandable because the platform is way more open than iOS and thus needs more inherent resistance. But look at the concept of "safe support" for third party input methods. But does compartmentalization of UI operations in this case actually make, say, 3rd-party keyboards safe to use?
- daniel_solano 15y ago
  It all depends on what you mean by "safe". It is certainly possible to create input methods that behave as spyware, that's why Android puts a big fat warning telling you so whenever you switch to a third-party input method. I think what is meant by safe in this context is that an that is not an input method cannot pretend to be one. Likewise, the interface between the input method and applications means that an application cannot normally wire itself into the input method and monitor everything the user types.
  - Udo 15y ago
    Yes, exactly, it's very open to debate what safety in this case actually means. I think what is meant by safe in this context is that an that is not an input method cannot pretend to be one. But is that really a concern? If you're putting together a spyware app disguised as a keyboard, why not just include a keyboard and "fool" this protection by actually providing the advertised functionality? I also believe that the Android people in this specific case define "safe" as "safe from crashes" in the way that a 3rd-party external component cannot easily crash the foreground app because of the windowing and thread-based compartmentalization.

Probably the key paragraph, in relation to the recent discussion: > In fact it was just not feasible to implement hardware accelerated drawing inside windows until recently. Because Android is designed around having multiple windows on the screen, to have the drawing inside each window be hardware accelerated means requiring that the GPU and driver support multiple active GL contexts in different processes running at the same time. The hardware at that time just didn’t support this, even ignoring the additional memory needed for it that was not available. Even today we are in the early stages of this -- most mobile GPUs still have fairly expensive GL context switching.

chwahoo 15y ago
So an attempt at a brief summary of (the non-thread-priorities portion of) her post: The Android model of providing rendering isolation between apps/windows has limited hw acceleration of window contents rendering, which is a cause of some of Android's lagginess. That iOS forgoes this isolation and achieves better responsiveness is a reflection of a different security philosophy. If this is an accurate summary, it's an interesting example of how platform design is wicked problem with complex interactions between concerns that you might expect to be orthogonal.
- campnic 15y ago
  That sounds accurate to me. I'm not sure if its simply that iOS forgoes isolation or they've implemented isolation in a mechanism that allows for the context to be shared without security consequence.
  - ryanpetrich 15y ago
    On iOS, all standard rendering is done in a single context by the Core Animation window server which lives in SpringBoard. Only when an app adds an OpenGL ES layer to the view hierarchy does a separate context need to be created. When that happens, the render graph is split into subgraphs that are rendered to surfaces and displayed as overlays (with SpringBoard rendering all the standard layers and the app rendering the OpenGL layer)
iam 15y ago
That might have been true before, but my understanding is that the newer mobile GPUs (coming out now, 2012, etc) have pretty much free context switching. Or so the vendors like to claim. Even if it's not true, shouldn't Google pushing for the GPU drivers to be fixed? This is a pretty obvious huge flaw [that has been pretty much solved on Desktop].

smackfu 15y ago

HN on previous post: http://news.ycombinator.com/item?id=3310301 http://news.ycombinator.com/item?id=3310301

nubela 15y ago

There is one thing that can be observed here, imho. That iOS was made to be sleek right from the start, from there they sacrificed pragmatic system design, which efficiently crimped a lot of flexibility; flexibility such as 3rd party input, etc, of which has gotta be now implemented from system up. As an Android user, given my (now) better understanding of the Android architecture design, I am happy and safely say that Android was made for the future, and is only gonna get better from here on.

chwahoo 15y ago
However, if iOS is able to evolve additional flexibility as it is needed without too much pain, then perhaps they made the right design choices at the start?
- campnic 15y ago
  I agree, its far to early to make any decisions about which platform "made the right decisions". We're in the first inning still for mobile.
- fpgeek 15y ago
  I think both Google and Apple made the right design choices at the start. They just made different ones is because they had different business goals. Google wanted Android to be ubiquitous and free to quickly evolve into whatever it needed to be to be in order to capture territory in the mobile device world. That means supporting a wide range of devices, technologies and, most importantly, partners (both hardware, software, carriers, etc.). So Android was designed for flexibility and has extension points everywhere (input frameworks, sharing, alternative browsers, launchers and so on). Google gave up performance along many dimensions in order to maximize Android's adaptability. Apple is very different. They have a vision and want to build that vision as precisely as they can because that is what has driven their success. That means Apple doesn't want hardware partners. And even at the software level, thsat means they are very careful about who and what they allow into their user experience. You can see this in how they built new features for iOS 5: Apple added a split keyboard for the iPad rather than adding support for alternative keyboards. They bought Siri rather than exposing relevant extension points. Apple baked Twitter into iOS 5 as a one-off, rather than riffing off of Android's sharing (as they did with notifications). And so on. These are all business decisions, not technical ones (as Cydia often proves). Instead, iOS's technical architecture flows from Apple's goals in the same way Android's flows from Google's.

erichocean 15y ago

The part about the graphics contexts and process limitation is key, and an area where iOS is far ahead of Android, since iOS does not have that limitation. (Neither does Mac OS X, and it took Apple years and years to get to that point -- each year at WWDC you'd see more and more of the UI hardware accelerated.)

D_Drake 15y ago

Users: Wow, android is neat, but why is the interface performance so crappy? Google: silence Users: Hmm, I bet it's X, because of ____. Google: No, no, X in android is great, it's awesome, and even if it weren't awesome it totally wouldn't be the cause of anything anyone might think is bad. Users: Ok, hmm, then I bet the clunkyness and chippiness are due to Y, because of _____ and _____. Google: No, no, Y is actually great in android; android has had Y since the beginning. Users: Ok, so why is the android interface universally clunky? Google: silence "I am not writing this to make excuses for whatever things people don’t like about Android" Dianne, don't you dare insult our intelligence by pretending the worst thing about the android experience is a case of personal preference by a small group of loonies. http://i.imgur.com/e8S63.jpg http://i.imgur.com/e8S63.jpg

zobzu 15y ago

Devil's tongue: "This is very different from iOS’s original design constraints, which remember didn’t allow any third party applications at all." This argument resume the whole article's intent. I'm not using iOS. I dislike Apple's way of enforcing it's products. But I know BS when I see it. iOS's security and sandboxing, while technically different, is practically similar to android. Each app is sandboxed. Oh and guess what, the AppStore let you install third party apps, and since before Android became Google's Android. And for the actual thing that matters, Android uses multiple GL contexts by design, iOS doesn't, so Android is slower.

Xuzz 15y ago
iOS has multiple processes on the system using hardware acceleration at the same time, and always has. A few examples are the system-rendered status bar at the top of the screen, or the "Notification Center" that you pull down from the top, or even the little volume adjustment popups. All of those are hardware accelerated and rendered out-of-process in the system UI manager ("SpringBoard"), not inside the app. Both of those have smooth scrolling and animations, at the same time, overlayed on top of each other. I don't think there's anything here in iOS that shows the lack of "multiple GL contexts"; and I definitely don't think that is a significant contributor to making anything slower.
Wilya 15y ago
Well, technically, she is right. About iOS1. That didn't have any app store, and had all applications running as root. Whether this old stuff is relevant is another matter, of course.

nkurz 15y ago

I just did an interesting side-by-side test of scrolling within a browser displaying Google on an new iPhone 4 and an older Android phone (HTC Incredible. I didn't actually see much difference as to how "smooth" or "choppy" the scrolling was, but there were distinct differences to fast motions. The iPhone seemed better at keeping up with a fast moving finger. If you put your finger on a line at the top of the screen, and scrolled quickly until your finger was at the bottom, the same line would still be under your finger. On the Incredible, the line you started on would only end up 2/3 of the way down the screen. More surprisingly, this seemed to happen to a lesser extent even on very slow scrolls. Put you finger down on a line, drag it to the bottom, and the amount scrolled is always significantly less than the distance your finger moves. Rather than being a rendering problem, this seems more like an event loop that throwing away some of the events!

crnchyflks 15y ago
Yep. This is a key aspect of Android scrolling crappiness, and a real schoolboy error when it comes to scrolling UIs. Once you leave the 'tap threshold' scrolling starts, but they haven't kept track of where the 'tap down' event happened, and so the experience is unsatisfactory - the illusion of your finger directly dragging the rendered surface is broken. The other thing that iOS does to improve scrolling (in the browser) is to 'cheat' by not doing anything while scrolling - so that with a large complex webpage, you end up scrolling over a vast expanse of checkerboard pattern - the scrolling is lovely and smooth though but you dont know what you're scrolling over. In Android, by contrast, you see rendered webpage while scrolling, even though this impacts on the smoothness of the scrolling experience.
rubinelli 15y ago
Touch gestures generate a ton of events, specially in early versions. The most common fix is sleeping for a few ms in the UI thread. http://www.badlogicgames.com/wiki/index.php/Touch_Event_Flooding http://www.badlogicgames.com/wiki/index.php/Touch_Event_Floo...
- joezydeco 15y ago
  I have to kind of wonder if Apple is buffering touch events on their controller and then sending them onward to the UI as postprocessed events and gestures. Maybe I'm the only one left with a boggy 3G running iOS4, but when the system lags down I can usually keep typing and the keystrokes will catch up. Does the same thing happen on Android? If gesture processing is being done on the controller side, that would take a lot of perceived bog out of the UI.

mirkules 15y ago

This post basically amounts to: "There is no problem with graphics on android, it was designed to work this way because of the open nature of android, and other excuses" Well, the design is broken then. Clearly, it is possible to achieve a smooth UI as demonstrated by iOS and have a solid and stable system. This post is actually worse than saying "we can't fix it" -- it's denying a problem exists in the first place, because "hey, we do it just like iOS." Except it doesn't work like iOS. I recently went back to iPhone because I got so frustrated with Android's jerky UI on my 1-year-old phone (Galaxy S). I went back to a iPhone 3GS that runs iOS 5 faster than the Android ran Froyo (which, btw, I had to jump through 30 different hoops just to upgrade from 2.1). The takeaway is this: Android lost a customer because of slow, laggy UI, and I'm sure I'm not the only one.

inoop 15y ago
Java is memory safe, and classloaders have been used since forever to sandbox applications (remember applets?). The whole 'designed to be open' argument is nonsense. Let's face it, Android was hacked together by a small team on a deadline. It doesn't seem like a lot of thought went into the design and architecture of the system. The code is buggy, there are no tests, and half the tree doesn't even have comments. Bug reports are ignored, and there are about 22k open issues that are not even being triaged. Case in point: http://code.google.com/p/android/issues/detail?id=19078 http://code.google.com/p/android/issues/detail?id=19078 (not fixed in ICS) Android is a rush-job, and the team's obvious lack of experience in handling large software projects is biting them in the ass. Rather than making excuses for their botched together software maybe they should just get their shit together.
- comex 15y ago
  > Java is memory safe, and classloaders have been used since forever to sandbox applications (remember applets?). Well, except that Android allows apps to run arbitrary native code using the NDK.
  - inoop 15y ago
    > Well, except that Android allows apps to run arbitrary native code using the NDK. I was under the assumption that they can support native code because of the way they designed Android, not the other way around. I highly doubt that supporting native code was the design rationale here. I think they just designed Dalvik to use Linux threads and assume it to run inside its own process. That certainly makes things much simpler for the VM. The fact that you can safely load native code follows naturally. Still, supporting native code does not have to dictate how you ensure memory protection, or whether each app has to run inside its own process. You can always run a native library (i.e. a video codec) inside a separate process and use memory-safe communication with the process that runs the Java app. You can also go the NACL route. There's absolutely no reason why supporting native code would result in a choppy UI on Android.

nuje 15y ago

The Android sandboxing feature is frequently invoked as providing dramatic security advantages, but there's really no reason to believe it. Local privilege vulnerabilities [edit: enabling escape from the sandbox] in Linux kernel are dime a dozen, and Android phones are notoriously outdated wrt security patches. There simply hasn't been a lot of OS level vulnerability exploitation in Android malware so far. Probably the biggest reason is OS fragmentation + malware apps can just request any privileges they need on the market and the users will haplessly click accept, and the biggest threat to the malicious apps is Google removing them from the Market when they're found out.

Udo 15y ago

It's easy to understand the point that window management in Android is complex and this complexity hampers graphics performance. On iOS, one process has the entire screen at a time. There are no widgets, no plugin viewports, no 3rd-party UI - but all this stuff is happening on Android. The question becomes whether this is actually a good paradigm to have for a mobile platform and whether this compartmentalization mechanism is really needed. For example, take this statement: "This [window management technique] is also why Android can safely support third party input methods." Clearly, the perception at Google is that this model makes Android safe, and in a way that's understandable because the platform is way more open than iOS and thus needs more inherent resistance. But look at the concept of "safe support" for third party input methods. But does compartmentalization of UI operations in this case actually make, say, 3rd-party keyboards safe to use?

daniel_solano 15y ago
It all depends on what you mean by "safe". It is certainly possible to create input methods that behave as spyware, that's why Android puts a big fat warning telling you so whenever you switch to a third-party input method. I think what is meant by safe in this context is that an that is not an input method cannot pretend to be one. Likewise, the interface between the input method and applications means that an application cannot normally wire itself into the input method and monitor everything the user types.
- Udo 15y ago
  Yes, exactly, it's very open to debate what safety in this case actually means. I think what is meant by safe in this context is that an that is not an input method cannot pretend to be one. But is that really a concern? If you're putting together a spyware app disguised as a keyboard, why not just include a keyboard and "fool" this protection by actually providing the advertised functionality? I also believe that the Android people in this specific case define "safe" as "safe from crashes" in the way that a 3rd-party external component cannot easily crash the foreground app because of the windowing and thread-based compartmentalization.