Android Rich Text Editor: a span based rich text view for Android

Everything is a span on a real EditText

The central technical decision is that all the styles are based on Android spans, the platform's own text styling mechanism, which means the editor is an EditText with spans attached rather than a separate document model. The supported style list is long and specific: bold, italic, underline, strikethrough, numeric list, bullet list, alignment left, centre and right, insert image, background colour, hyperlink, at sign, quote, foreground colour, emoji icon, superscript, subscript, font size, video, image from internet and a dividing line. Two capabilities are worth pulling out because they are about the document rather than the styling. All styles support saving as an HTML file, and you can load from HTML and then continue editing or displaying, which the changelog marks as new in 0.1.0. The primary language of the repository is Java, the licence is Apache-2.0, the last push was on 2026-09-08, and the newest published release is 0.2.1 from December 2020.

Two ways to assemble it

The component comes in two usage modes, and choosing between them is the first decision you make. In the first, AREditor combines the input area and the styling tools in one component, so putting it in your layout XML gives you the input area and the toolbar, with the bold, italic, alignment and list tools, inside your activity. In the second, AREditText and the toolbar are standalone components and you decide where the toolbar goes, below or above the input area, left or right, or any other alignment, because the toolbar is itself a HorizontalScrollView in the default implementation, and you also decide which tool items it contains. So the second mode is the one to use when the editor is part of a larger screen and the toolbar does not belong directly under the text. The two modes share the same internals, so you can switch between them without rewriting anything about the styling behaviour.

How the styling actually gets applied

The mechanism is worth understanding because it explains the whole design. AREditor extends RelativeLayout and contains two child components, AREditText and ARE_Toolbar. AREditText extends AppCompatEditText, and in its afterTextChanged method of a TextWatcher it calls the applyStyle method of an IARE_Style. So the trigger is the text changing, and the work is delegated to a style object. The toolbar side is the mirror image. ARE_Toolbar extends LinearLayout, and the tool items inside it are IARE_Style instances, each of which contains an ImageView that is what you actually see in the toolbar. The upshot is that a toolbar button is not a click handler that mutates the text, it is a style object that the text watcher calls, which is what makes a toolbar item and the resulting span a single thing rather than two that have to be kept in step.

Nineteen tool items, and the interfaces behind them

The component ships nineteen tool item implementations, and the names make the coverage obvious: an abstract base, three alignment variants for centre, left and right, and then bold, horizontal rule, image, italic, link, bullet list, numbered list, quote, strikethrough, subscript, superscript, underline, an updater default, video and the at sign item. Underneath them are two interfaces. IARE_Toolbar defines what a toolbar has to implement, with methods such as addToolbarItem and getToolItems, and the default implementation ARE_ToolbarDefault extends HorizontalScrollView and implements all of them. IARE_ToolItem defines the behaviour a tool item should have, with getView returning the view shown in the toolbar and getStyle returning the IARE_Style that responds to the text change. Adding an item is a matter of calling addToolbarItem with an IARE_ToolItem, and writing your own means implementing that interface, with any of the nineteen as a reference. The at sign item is singled out as the example of a tool item with no image on the toolbar, which is a useful thing to copy when your button is a character rather than an icon.

Integration, and the recommendation to vendor the source

The dependency goes into the app module of your gradle build, and the documented lines are:

    implementation 'com.github.bumptech.glide:glide:4.9.0'
    implementation 'com.github.chinalwb:are:0.1.7'

Glide comes along because the image and video tool items need to load remote content. The more interesting instruction is the one that follows, because the author says that since the library is still not stable enough to handle the issues that come up in different business scenarios, they would recommend importing it into your project directly and adding it as a local module dependency, which in the build is:

implementation project(':are')

That is a strong signal about the state of the project, and it is consistent with the version numbers, since the documented example pins 0.1.7 while the newest published release is 0.2.1. The zero major version is the other signal, and the changelog in the readme shows a 0.2.0 release that migrated to AndroidX with Glide updated to 4.11.0, with 0.1.10 named as the last version before that.

The author is open to paid work, and the code stays open

There is a part of the readme that deserves to be quoted rather than paraphrased, because it explains the shape of the project. The author says that starting from the beginning of the project all the code was open-sourced and it helped tens to hundreds of friends out of their troubles, for free, but now they have to charge for future help, starting at 49 dollars per feature implementation and 19 dollars per feature contact, while all the improvements will still be open-sourced to help others out. So the library is a free, complete implementation of a rich text editor, and the paid part is consultancy on building on top of it. Two related components are published separately as standalone reusable pieces, a colour picker and an emoji picker, both under the same author's name, and the same reasoning is applied to them. The repository also carries a Chinese language readme, an AGENTS.md and a CLAUDE.md, a usage document and a tools directory, and the project is described as still in progress with a plan for the next version that lists undo and redo.

Editorial conclusion

ARE suits an Android developer who needs styled text input inside an existing app and wants to avoid a WebView based editor, because the output is real spans on a real EditText. It does not suit a project that needs a mature editor with a document model behind it, and the author is direct that the library is not yet stable enough for all business scenarios and recommends importing it as a local module. Before you take the dependency, read the stability note in the integration section, and plan for the two zero version releases, since the last published release is 0.2.1 from December 2020 and the repository itself is still being worked on.

Frequently asked questions

Official sources

1. chinalwb/Android-Rich-text-Editor on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases