AndroidStudy: two Maven artefacts, seven modules, and no licence file

Two artefacts on Maven Central with no licence anywhere

The most important thing about this repository is an absence, and it is one that a consumer of the published libraries cannot easily discover.

AndroidStudy publishes two libraries to Maven Central. The coordinates are:

implementation 'io.github.mqcodedev:lib_dialog:1.3.0'
implementation 'io.github.mqcodedev:lib_mvpager2:1.0.0-rc3'

The repository's licence field reads as unknown, and the top-level entries are .gitattributes, .gitignore, README.md, app/, build.gradle, buildSrc/, compileTimeCost.gradle, gradle.properties, gradle/, gradlew, gradlew.bat, seven lib_ directories, multiprocess_sever/, pic/, plugin/, qrcode.png and settings.gradle. There is no LICENSE file, and no COPYING or equivalent.

So the code is under default copyright. Publishing to Maven Central does not require a licence, and the coordinate namespace being a personal GitHub identity does not imply one. What that means in practice is that the grant you would normally rely on, the right to use, copy, modify and redistribute, is not stated anywhere in the artefact or its source repository. Reading the code is permitted; using it in a shipped product is not something the author has authorised in writing, and a company that puts it in a commercial app is relying on an assumption rather than a term.

This is worth being blunt about because the failure is quiet and expensive. Nothing breaks. The build resolves, the code works, and the licence question surfaces in a legal review months later, at which point the options are to remove the dependency and redo the work, or to go back to a single author and ask. Neither is a good position to be in, and both are avoidable with one email. The author's contact details are not in the repository README, but the project is a WeChat public account with a CSDN blog linked from the repository homepage, and either is a route to the person who wrote it.

The pattern is not unusual for repositories of this kind. A developer publishes a library, gets a few stars, and moves on. It is still a real constraint, and it is the first thing to resolve before writing the dependency line.

A struck-through JCenter coordinate, kept on purpose

The changelog table in the README documents a migration that most projects delete, and keeping it is a genuine courtesy to anyone with a stale build file.

The lib_dialog row records that the dialog library has moved to a Maven repository, with the current coordinate and the instruction to declare mavenCentral() in the root build.gradle, noting that new projects include it by default. Below that, the previous coordinate appears struck through: implementation 'com.ninetripods:lib-dialog:1.1.0', with a note in Chinese that JCenter will not allow version updates in the future and that the Maven route is strongly recommended.

Three things are worth noticing. The old coordinate is preserved rather than removed, so a developer who finds com.ninetripods:lib-dialog:1.1.0 in a build file can search the README and find the replacement. The reason is stated rather than implied, and the reason is not that the old library was bad but that JCenter, the Bintray-hosted repository that was central to the Android ecosystem for years, went read-only and then sunset. Any Android project published between roughly 2018 and 2021 has coordinates of that shape somewhere. And the current coordinate has a different group id entirely, io.github.mqcodedev rather than com.ninetripods, which is what a migration to a personal Maven Central namespace looks like rather than a version bump.

The version numbers tell the rest of the story. The JCenter line was 1.1.0 and the Maven line is 1.3.0, and the repository's only release tag is v1.3 dated 2018-09-20 with the message Encapsulate a common dialog. So the tag, the current artefact version and the migration all refer to the same library, and they all point at 2018.

That is the point to carry into an evaluation. This migration documentation was written in 2018 or shortly after, the artefact it produced has not been released since, and the second library was never in the same position. The lib_viewpager2 row shows it at 1.0.0-rc3, a release candidate that the README presents as the way to use it, with the ordinary use cases illustrated as animated GIFs: a Taobao-style search bar carousel, and a Taobao and JD style banner for browsing product details.

Two published libraries out of seven modules

The repository contains seven library modules and the README documents two of them. The gap is the interesting part, because the undocumented ones describe what this project is actually for.

The documented pair is lib_dialog, a DialogFragment wrapper described as a general-purpose dialog encapsulation, and lib_viewpager2, an automatic and manual infinite carousel built on ViewPager2 with custom item views and transition animations. Both have their own README inside the module directory, linked from the changelog table, so the per-library documentation exists even though the root README does not summarise it.

The undocumented five are lib_bytecode, lib_bytecode_common, lib_kt_plugin, lib_protobuf and multiprocess_sever/. Read the names together and the pattern is a single developer's curriculum rather than a product. lib_bytecode and lib_bytecode_common are bytecode manipulation, which is compiler-adjacent work. lib_kt_plugin is Kotlin compiler plugin development, which is also compiler-adjacent and considerably harder. lib_protobuf is schema-driven serialisation. multiprocess_sever/ is multi-process communication between Android app processes, and the directory name appears to be a typo for server that has been committed and never corrected, which is the kind of detail that tells you a directory has been there a long time.

None of the five is published to Maven Central, none is in the changelog table, and none is described in the root README. There is also an app/ module, which is the demo application, and the README's first section links a QR code and a download through pgyer.com, a Chinese app distribution service, for a sample APK. So the demo is distributed through a hosted service rather than built from the repository by a reader.

What this adds up to is a portfolio: the two libraries polished enough to publish, four or five more kept as working code inside the same tree, and an app that exercises them. That is a completely coherent thing for one person to maintain and a poor thing to consume as a dependency, because there is no signal about which modules are meant to be stable and which are experiments. The two published coordinates are the signal, and the rest is context.

The canonical documentation is a CSDN blog and a WeChat account

The repository's declared homepage is not a documentation site. It is a personal blog on CSDN, a Chinese developer blogging platform, at blog.csdn.net/u013700502.

That matters for two reasons, one about access and one about durability. The README's third section is a link index, not documentation, and it is close to forty-four entries across seven series: Jetpack, Kotlin, Gradle, multithreading, the 深入理解 or in-depth series, Android storage, and Android View. The Jetpack series covers Lifecycle, LiveData, ViewModel, LiveDataBus, MVVM, MVI and DataStore. The Kotlin series has eleven entries on inline functions, Flow, scope functions, collections, Handler usage, JVM interop annotations, data classes and sealed classes, coroutines, varargs and generics. The multithreading series has fourteen, from HandlerThread and IntentService through Callable and Future to a run of JUC topics on AbstractQueuedSynchronizer, ThreadPoolExecutor, BlockingQueue, CountDownLatch, Semaphore, CyclicBarrier, ReentrantLock and ReentrantReadWriteLock.

A series that reaches from HandlerThread to ReentrantReadWriteLock, and from DataStore to SharedPreferences source reading, is a coherent body of work on its own terms. It is also, as documentation, entirely off-repository.

A substantial share of those links point at mp.weixin.qq.com, which is WeChat's article platform, rather than at CSDN. Both are third-party platforms with their own moderation, availability and indexing behaviour, and neither is under the author's control in the way a docs directory would be. A link that works today can stop resolving, and the content is not in the repository's git history, so there is no fallback.

For a Chinese-reading Android developer this is a well-organised index and probably a good one. For anyone else, it is a language barrier and a platform dependency at the same time, and the repository README itself is almost entirely in Chinese. The honest position is that this project has no English documentation and no repository-hosted reference, and anyone evaluating it in English is evaluating the two Maven coordinates and reading the source.

compileTimeCost.gradle, and a build-performance interest

One entry in the repository root is unusual enough to deserve its own look: compileTimeCost.gradle.

A Gradle script at the root, outside any module, named for measuring compile time, is not part of a normal Android project skeleton. It indicates a deliberate interest in build performance, and the blog index supports that reading. The Gradle series has six entries, and the most recent is titled around adding build.gradle configuration for multi-channel packaging, which is a build-engineering topic rather than an application topic.

Alongside it, buildSrc/ and plugin/ plus lib_kt_plugin/ describe a project that develops its own Gradle plugins and its own Kotlin compiler plugin. buildSrc/ is the conventional location for build logic that should be compiled and shared across a multi-module build, which is what you use when your build logic is substantial enough to want type checking. plugin/ is a standalone location, which is where a plugin that gets published to the Gradle Plugin Portal would live. Combined with lib_kt_plugin/, the picture is a developer who has gone past consuming the toolchain and started extending it.

None of that is in the README. The Gradle series that documents it lives on the blog, and the root README is a link table. So a reader looking for evidence that the build setup is competent will not find it in the documentation and has to read the file listing to infer it.

For an adopter of the two published libraries, none of this matters, because they consume a Maven coordinate rather than the build. For anyone considering this repository as a source of patterns for their own Android build, it matters a great deal, and the honest characterisation is that the interesting material is in the tree rather than in the prose. The wrapper files gradlew and gradlew.bat, the settings.gradle and the gradle.properties are all present, so the build is at least self-contained enough to clone and run.

One release tag from 2018, and a library still at rc3

The version history of this repository is one line long, and the two published libraries are on different lines.

There is a single release, v1.3, tagged 2018-09-20, with the message Encapsulate a common dialog. That is the whole release history. No 1.4, no 2.x, and nothing in the eight years since.

Against that, the last push was on 2026-07-25, so the repository is not abandoned and has not been archived. The distinction matters: recent commits and an old tag together mean work is happening without being released, which is the normal state of a personal project and the normal state of a blog. The topics confirm which is which, listing jetpack, jetpack-mvvm, jetpack-mvi, jetpack-viewmodel, jetpack-livedata, jetpack-lifecycle, jetpack-datastore, kotlin, mvvm, kotlin-dsl, banner, dialog, dialogfragment, gradle, handlerthread, juc-multithread and thread. That is a knowledge-summary topic set, and the description calls the repository an Android knowledge-point summary covering Jetpack, MVVM, MVI, Kotlin, ViewPager2 and JUC multithreading.

So the picture is: an active writing and sample-code project, with two libraries frozen at the point where they were good enough to publish. lib_dialog sits at 1.3.0, which matches the 2018 tag. lib_mvpager2 sits at 1.0.0-rc3, and rc3 is a more awkward coordinate than 1.3.0 in one specific way. A patch-level version reads as settled. A release candidate reads as unfinished, and most developers add a dependency without registering the distinction, which means the standard advice about not shipping release candidates does not reach the people most likely to install it. The README presents the rc3 coordinate as the way to use the library, with no warning attached.

If you are evaluating this for production use, that is the single most actionable fact. Either the library has been stable for years at rc3, in which case the coordinate should probably be promoted, or it is genuinely unfinished, in which case you should read lib_viewpager2's own README before wiring it into a product.

Who this is for, and what you get for the visit

The README opens with a subscription request and an APK download before it says anything about the libraries, and that ordering is the clearest statement of the project's purpose.

Section 1 is 扫码关注, scan the code to follow. It asks readers to scan a QR code or search the WeChat public account 代码说 for the latest articles, and offers a sample APK by QR code or through a direct pgyer.com download link. The WeChat account is the publication; the repository is its source.

Section 2 is the changelog table for the two libraries. Section 3 is Blog发布, the published article index across seven series. Sections after that are thin: Get Started is implied by the article index, and there is no contributing guide, no changelog for the repository itself, no code of conduct and no issue template described anywhere in what the README shows.

What a visitor gets, then, is three things in a fixed order. An invitation to a WeChat account, two Maven coordinates, and roughly forty-four article links split between CSDN and WeChat. The seven library modules in the tree, the build tooling, the Kotlin compiler plugin work and the app module are not part of the pitch, and the repository's own development history is not documented at all.

That is a coherent shape for what it is, and it is worth being clear-eyed that it is a personal knowledge archive with two publishable byproducts rather than a library project. The two byproducts are real, small and useful in their own domains: a DialogFragment wrapper and a ViewPager2 infinite carousel, both with per-module READMEs, both on Maven Central under a personal namespace, and both without a licence.

For an English-reading Android developer the practical route is short. Read lib_viewpager2's README and lib_dialog's README inside the repository, check whether either duplicates something already in your build, and if one does the job, ask the author for a licence before you use it. Everything else in this repository is a link farm pointing at content in a language you may not read, hosted on platforms you do not control.

Editorial conclusion

Use AndroidStudy if you are an Android developer working in Chinese who wants the ViewPager2 infinite-banner library or the DialogFragment wrapper, and you are content to take them as-is from Maven Central. Do not adopt either artefact inside a commercial product until you have asked the author which licence applies, because io.github.mqcodedev:lib_dialog and io.github.mqcodedev:lib_mvpager2 are published with no licence file in the repository and default copyright is the only rule in force. Do not treat the repository as a maintained framework, since the only release tag is v1.3 from 2018-09-20, lib_mvpager2 is still published at 1.0.0-rc3, and the last push on 2026-07-25 is almost certainly blog and sample work rather than library maintenance. Verify four things. Ask the maintainer for a licence, and get the answer in writing. Check whether the rc3 coordinate is one you want in a build script, because an rc in a dependency string is not a signal most developers act on. Read the library's own README in the module directory rather than the repository root, since the root README is a blog index. And plan for the documentation being on CSDN and WeChat rather than a site you control, which means the reference material for these libraries can move without notice. The deciding fact is that the code is good enough to publish and the packaging was never finished, so the risk here is legal rather than technical.

Frequently asked questions

Official sources

1. crazyqiang/AndroidStudy on GitHub
2. Issues
3. Project website
4. README
5. Releases