BackgroundLibrary: Android Shape and Selector Drawables Generated from XML Tags

What BackgroundLibrary replaces in an Android project

Every Android app accumulates drawable XML. A rounded button needs a shape file with corners, solid and stroke. The pressed state needs a selector that points at two more shape files. Multiply that by five button styles and the res/drawable directory becomes a wall of files whose names no longer match what they draw. BackgroundLibrary targets exactly that pile. Instead of a shape.xml, you put app:bl_corners_radius, app:bl_solid_color and app:bl_stroke_width directly on the TextView or Button, and the library builds the drawable for you. The README states the goal plainly: generate shape through tags, no need to write shape.xml again. The audience is Android developers writing view XML by hand, especially those maintaining several visual states per widget. It is not a design system and not a theming layer. It is a shortcut for one specific, repetitive artifact.

How the bl_ attributes become a Drawable

The mechanism is attribute-driven. You attach bl_ attributes to a normal view, and the library reads them and constructs a Drawable, then applies it as the view's background. Nothing about the view class changes: the README describes the integration as seamless with native views, meaning a standard TextView works. The attribute vocabulary mirrors the shape XML element names closely, so bl_corners_radius maps to corners, bl_solid_color to solid, bl_stroke_color and bl_stroke_width to stroke. State handling follows the same idea: bl_pressed_drawable and bl_unPressed_drawable produce what a selector with state_pressed would produce. There is a second entry point for code. DrawableCreator.Builder exposes the same knobs as methods, so setCornersRadius, setSolidColor, setStrokeColor, setStrokeWidth, setRipple and setPressedDrawable build a drawable that you assign with setBackground. The README shows both paths for the same visual result, which suggests the XML route is a front end over the same builder. Version 2.0.0 extends the attribute set with stroke gradients (bl_stroke_gradient_startColor, bl_stroke_gradient_endColor, and optional bl_stroke_gradient_centerColor and bl_stroke_gradient_angle).

Installing BackgroundLibrary and drawing a first button

The README gives dependency coordinates for both support-library and AndroidX projects, and it is explicit that the artifact names differ. Add the JitPack repository to your project-level build file first. Note that the repository URL is quoted in the README, and the version is 2.0.0.

Choosing the right artifact for support library or AndroidX

This is the step people get wrong, because the two artifacts are not interchangeable. If the project uses the old support library, the README pairs com.android.support:appcompat-v7 with com.github.JavaNoober.BackgroundLibrary:library. If the project uses AndroidX, it pairs androidx.appcompat:appcompat with com.github.JavaNoober.BackgroundLibrary:libraryx. The suffix is the whole difference, and the repository layout backs this up: there are separate library/ and libraryx/ directories at the top level, alongside androidx/, app/ and test/. The release notes for 2.0.0 also mention a fix for background and text styles not taking effect under newer AndroidX (androidx core 1.1.0 and above), which is worth knowing if you are on a recent AndroidX version and previously saw the attributes silently ignored.

A border, a gradient and a pressed state in one view

The README's first example is a TextView with rounded corners, a solid fill, a dashed stroke and a text color. Every one of those values lives on the view, and the equivalent shape XML is shown side by side in the README so you can compare them.

Where BackgroundLibrary stops being the right tool

The library is a declaration shortcut, not a drawable engine. Anything the bl_ attributes and DrawableCreator.Builder do not expose, you cannot express, and you fall back to XML or custom code. Shared drawables are the clearest case: if twelve screens reference one selector, inlining the attributes twelve times is worse than one file, because a color change becomes twelve edits. Theming is another. A drawable resolved from a theme attribute or swapped at runtime from server-driven configuration does not fit a model where the values are literal in the layout. There is also a maintenance signal to weigh. The repository is not archived, and the last push was on 2026-08-15, the same day 2.0.0 was released. The release before it, 1.7.6, is dated 2023-03-09, so the gap between 1.7.6 and 2.0.0 is roughly two and a half years. That is a long quiet stretch for a library whose value depends on tracking AndroidX and platform changes, and the 2.0.0 changelog is largely a list of fixes for exactly that kind of drift. The README also notes that issue replies are not timely and points readers to a QQ group, which tells you where support actually happens. If you need a guaranteed response path, plan for that.

RTL mirroring and how it compares to writing selectors by hand

Version 2.0.0 adds right-to-left support, and the way it is switched on matters. The README says bl_corners_*, bl_padding_*, bl_stroke_position and bl_position mirror their left and right values automatically under RTL, but only when you call BackgroundLibrary.setRtlSupportEnabled(true). It is off by default. That is a deliberate compatibility choice: turning mirroring on by default would change the rendering of existing layouts, so the library makes you opt in. The alternative to this library is the plain Android approach: write the shape and selector XML yourself and reference it with android:background. The difference is not rendering, because the README states the result is the same as native shape and selector. The difference is where the values live. Hand-written XML centralizes a style in one file that many views can share and that designers can diff. BackgroundLibrary localizes it at the view, which is faster to write and easier to read in the layout, and harder to reuse across screens. Neither is strictly better; they optimize for different things.

Licence and the cost of staying on 2.0.0

The project is licensed under Apache-2.0, which permits commercial use and modification and requires that you retain the licence and notice files when redistributing. That is a permissive arrangement, and nothing in the repository suggests additional terms. The upgrade cost is the more practical question. Moving from 1.7.x to 2.0.0 is a major version, and the changelog mixes additions with behavioural fixes: RTL support is new and opt-in, while the AndroidX background and text style fix, the RadioButton and CheckBox bl_enabled fix, the white #FFFFFF color fix and the horizontal text gradient fix all change behaviour that a 1.7.x user may have worked around. If you are on 1.7.6 and those workarounds exist in your code, remove them as part of the upgrade rather than leaving both in place. The README does not document a rollback procedure or a migration guide beyond the changelog, so treat the changelog as the migration document.

Editorial conclusion

BackgroundLibrary is for Android teams that keep writing near-identical shape.xml and selector.xml files for every button state and want those declared inline on the view instead. Skip it if your drawables are already shared, themed, or generated at runtime from server data, since the library only covers what its bl_ attributes and DrawableCreator.Builder expose. Before adopting 2.0.0, verify on a real device that bl_enabled and bl_unEnabled still work on your RadioButton and CheckBox instances, that white #FFFFFF is accepted as a color, and that bl_text_gradient_orientation="horizontal" actually renders horizontally, because those are the four behaviours the release notes list as fixed in this version.

Frequently asked questions

Official sources

1. Issues
2. JavaNoober/BackgroundLibrary on GitHub
3. License: Apache-2.0
4. README
5. Releases