title: KeyboarddAvoidingView not working with keyboard on bottom
body: <p>I have a component that renders the following:</p>
  
  <pre><code>return (
    &lt;KeyboardAvoidingView behavior="position"&gt;
      &lt;View style={styles.container}&gt;
        &lt;View style={styles.messagesContainer}&gt;
        &lt;/View&gt;
        &lt;SafeAreaView&gt;
          &lt;View style={styles.inputView}&gt;
            &lt;TextInput style={styles.input} /&gt;
            &lt;Button title="submit" /&gt;
          &lt;/View&gt;
        &lt;/SafeAreaView&gt;
      &lt;/View&gt;
    &lt;/KeyboardAvoidingView&gt;
  )
  </code></pre>
  
  <p>With stylesheet:</p>
  
  <pre><code>const styles = StyleSheet.create({
    container:{
      height: "100%"
    },
    messagesContainer: {
      backgroundColor: "red",
      flex: 1
    },
    inputView: {
      flexDirection: "row",
      alignItems: "center",
      padding: 5,
      height: 24
    },
    input: {
      height: 20,
      backgroundColor: "white",
      flex: 1
    }
  });
  </code></pre>
  
  <p>This view is rendered as a screen in a react-navigation <code>StackNavigation</code>.</p>
  
  <p>I'd like the view to move up to make space for the keyboard, but it doesn't seem to move up far enough.</p>
  
  <p><a href="https://i.stack.imgur.com/ez1tM.gif" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/ez1tM.gif" alt="enter image description here"></a></p>
  
  <p>I know it's moving it up, because if I add some padding to the bottom of my container:</p>
  
  <p><a href="https://i.stack.imgur.com/qP6x7.gif" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/qP6x7.gif" alt=""></a></p>
  
  <p>I've also wondered whether the SafeArea component is messing up the calculations of how far up the view should be moved, but it doesn't seem so.</p>
  
  <p><a href="https://i.stack.imgur.com/d8bPN.gif" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/d8bPN.gif" alt=""></a></p>
  
  <p>I could tweak that bottom padding until the text input shows up right above the keyboard, but that seems like a flaky solution that'd require different values for different devices, orientations, keyboard layouts, etc.</p>
  
  <p>Is there a more robust solution?</p>