super nit, but i think this can be simplified a bit to avoid needing to check for FillType.Up:

    // takes us straight up or down to the fill edge
    this.renderPath.rLineTo(0, fillEdge);
    // takes us straight over to the left edge
    this.renderPath.lineTo(0, fillEdge);
    // closes back to the path's start
    this.renderPath.close();

you end up having to check the fill-edge for null, and only do those operations if non-null. but i think it reads a bit cleaner.

Looking back over this, it actually seemed to be an issue with the getFillEdge() method, specifically:

case FillType.UP:
    return (float) getPaddingTop();

which wasn't taking into account the view height. Moving -getHeight() into this method and removing the ternary seemed to result in the same desired behavior. Though I'm not familiar with what else is using getFillEdge but local testing showed promising results.

Hm, I don't think we want the fill edge to be -getHeight() for the FillType.UP case. Conceptually, the fill edge should be the y value in drawing coordinates that we want to travel to to close the path. In the case of UP, it should be 0 since the top edge of a view in Android is coordinate 0. Then we have to take the padding into account, so we add paddingTop to that.

With that in mind, I think my initial code suggestion was wrong. We actually want something like:

            // line up or down to the fill edge
            sparkPath.lineTo(lastX, fillEdge);
            // line straight left to far edge of the view
            sparkPath.lineTo(getPaddingStart(), fillEdge);
            // closes line back on the first point
            sparkPath.close();

Which is from SparkView.populatePath(). Unfortunately, we don't have lastX handy. Also the lastX may be different from one animation to another. So, I think we may want to move the path closing/filling to the animators themselves.