Android Signature Pad: a Java View for Smooth, Velocity-Scaled Signatures

The gap Android Signature Pad fills for in-app signing

Capturing a signature inside an Android app is not the same problem as capturing a drawing. A finger trace drawn with a fixed stroke width looks like a polyline, and a signature that looks like a polyline is harder to accept as a signature. Android Signature Pad is a custom View that renders the trace as a variable-width Bezier curve, so the line thickens and thins with the speed of the stroke. The README credits the technique to Square's Smoother Signatures post, and the feature list names three things that follow from it: Bezier interpolation, variable point size based on velocity, and customizable pen color and size.

The intended audience is narrow and clear. This is a library for Android developers who are already writing a Java or Kotlin app and want a signing surface they can drop into a layout, read events from, and export. It is not an app, not a service, and not a document workflow. If you need a signature on a form, a delivery receipt, or a consent screen inside your own APK, this is the layer that draws and returns the strokes. Everything else, storage, transmission, audit trail, is yours to build.

Bezier interpolation and velocity weighting inside the View

The mechanism is a custom View that owns a canvas and a stroke model. Touch events feed points into that model, and the model converts them into Bezier segments rather than straight lines between sample points. Width is not constant: the pen size is derived from the velocity of the movement, so a fast flick produces a thinner line and a slow, deliberate stroke produces a thicker one. The README exposes velocityFilterWeight as a configurable attribute with a default of 0.9, described as the weight used to modify new velocity based on the previous velocity. That single number is the smoothing dial between a jittery response to every sample and a lagging one that ignores sudden changes in speed.

Four attributes control the drawing: penMinWidth (default 3dp), penMaxWidth (default 7dp), penColor (default Color.BLACK), and velocityFilterWeight. A fifth, clearOnDoubleClick, defaults to false and turns a double tap into a clear action. Three listener callbacks report state: onStartSigning when the pad is touched, onSigned when the signature is complete, and onClear when the pad is cleared. Output comes in three forms: getSignatureBitmap() returns a bitmap with a white background, getTransparentSignatureBitmap() returns one with a transparent background, and getSignatureSvg() returns a Scalable Vector Graphics document. Those three methods are the whole data flow out of the library.

Installing signature-pad from Maven Central and drawing a first signature

The README states that the latest version is on Maven Central and gives the coordinates for both Gradle and Maven. For a Gradle project, make sure the repository is declared and then add the dependency. The version shown in the README is 1.4.0.

repositories {
    mavenCentral()
}

implementation 'com.github.gcacace:signature-pad:1.4.0'

For a Maven build, the same artifact is declared with type aar.

<dependency>
  <groupId>com.github.gcacace</groupId>
  <artifactId>signature-pad</artifactId>
  <version>1.4.0</version>
  <type>aar</type>
</dependency>

With the dependency in place, add the view to a layout. The README's example sets the pen color through the app namespace and uses match_parent for both dimensions.

<com.github.gcacace.signaturepad.views.SignaturePad
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:id="@+id/signature_pad"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    app:penColor="@android:color/black"
    />

Then wire the listener. The README's Java sample finds the view by id and sets an OnSignedListener with the three overrides.

mSignaturePad = (SignaturePad) findViewById(R.id.signature_pad);
mSignaturePad.setOnSignedListener(new SignaturePad.OnSignedListener() {
    @Override
    public void onStartSigning() { }

    @Override
    public void onSigned() { }

    @Override
    public void onClear() { }
});

What you should see after this: a blank pad that starts reporting onStartSigning as soon as it is touched, fires onSigned when the signature is considered complete, and fires onClear when the pad is reset. To read the result, call getSignatureBitmap(), getTransparentSignatureBitmap() or getSignatureSvg(). The README points to the SignaturePad-Example app in the repository for a more detailed code example, which is the place to look when the four attributes above are not enough.

Rotation, process death, and the SVG coordinate-space caveat

The README is unusually direct about configuration changes. The signature survives screen rotation and process backgrounding because it is saved in the view's instance state and restored automatically, and getSignatureSvg() is restored after a rotation too. That is more than many custom Views offer, and it removes the usual chore of hoisting stroke data into a ViewModel just to survive a rotate.

The caveat is the part worth reading twice. A signature drawn before a rotation is restored in its original coordinate space and scaled to fit the new orientation. Strokes added after the rotation are captured in the new orientation's coordinate space. The on-screen bitmap stays correct, but within a single SVG document the pre-rotation strokes and the post-rotation strokes live in different coordinate spaces. If your pipeline renders that SVG somewhere else, at a different size or in a different viewer, the two halves of the signature can disagree. The README does not document a normalization step for this, and it does not document rollback of the instance state either. If your users rotate mid-signature and you export SVG, plan to test that case explicitly rather than assume it is handled.

Where Android Signature Pad is the wrong tool

Three cases stand out. First, if you need a standalone signing application that a person installs and uses to sign PDFs, this repository is not that. It is a library, the README describes it as a library, and the only runnable artifact mentioned is the SignaturePad-Example app, which exists to demonstrate usage. Second, if your app is not Android, the README points to two community wrappers rather than a native cross-platform core: a Cordova plugin by netinhoteixeira and a NativeScript plugin by bradmartin, both linked from the README and both maintained outside this repository. Third, if you need server-side rendering or a signature capture that is independent of the touch hardware, this is the wrong layer. The output quality depends on the velocity of the input events, and the README gives no calibration guidance for stylus versus finger, no pressure support, and no documented way to feed a synthetic stroke path in.

There is also a quieter limitation in the API surface. The three export methods return a bitmap or an SVG document, and the README does not document stroke-level access, timestamps, or per-point pressure. If your compliance process needs to prove how the signature was produced rather than just show it, you will be storing an image and reconstructing the rest yourself.

How it compares with writing your own View on Canvas

The obvious alternative is to subclass View yourself and draw on the Canvas with Path and lineTo. That approach is fully under your control and adds no dependency, and for a straight-line signature it is perhaps fifty lines. The difference is in the interpolation. Android Signature Pad implements Bezier smoothing with velocity-based width, which is the part that makes a touch trace look like ink. Reproducing that means porting the same technique the README attributes to Square's post, and then tuning velocityFilterWeight against your own hardware. If you want a straight-line signature, drawing it yourself avoids the dependency. If you want the variable-width curve, you are choosing between this library and a from-scratch implementation of the same algorithm. The other alternative is a WebView-based signing widget, which moves the drawing into JavaScript and gives you cross-platform reach at the cost of a bridge for the resulting image. Android Signature Pad keeps the work in the native view hierarchy, which is why the Data Binding setters exist for onStartSigning, onSigned and onClear.

Maintenance, licence, and what an upgrade costs

The repository is not archived, and the last push was on 2026-07-24, the same day release 1.4.0 landed. That release is described in the release list as crash fixes and modernization, so the recent history is maintenance rather than feature growth. The top-level tree includes CHANGELOG.md and PUBLISHING.md, which means version history and the release process are documented in the repository rather than only in the README. CI runs through a GitHub Actions workflow, and code coverage is reported through Codecov, both linked from the README badges.

On licence, the project is Apache-2.0, and the README carries the full header with a copyright range of 2014-2025 for Gianluca Cacace. Apache-2.0 permits commercial use and modification and includes a patent grant, but it also requires that you keep the licence and notice files and state significant changes. That matters here in one concrete way: if you fork the View and change the drawing code, the notice obligation follows the fork. This is a description of the licence text, not legal advice; check it against your own distribution model.

The upgrade cost is low by design. The public surface is a View class, five XML attributes, three listener callbacks, and three export methods, and the dependency is a single AAR coordinate. Because the version is pinned in the dependency line, an upgrade is a one-line change plus a re-read of CHANGELOG.md for the release you are moving to.

Editorial conclusion

Adopt Android Signature Pad if you are building a native Android app and need a signing surface that exports a bitmap or SVG, and if you can accept that stroke width depends on touch velocity and that SVG coordinates can mix after a rotation. Do not adopt it if you need a standalone signing app, a cross-platform widget without the Cordova or NativeScript wrappers, or a server-side renderer. Before you commit, check the SignaturePad-Example app against your own layout, and verify on a real device how penMinWidth, penMaxWidth and velocityFilterWeight look with your stylus or finger.

Frequently asked questions

Official sources

1. gcacace/android-signaturepad on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases