The most fun TODOs from the Android framework

Hello, my name is Abakar and I work as the chief Android technical lead at Alfa-Bank.
Sometimes in a project (especially if it is large) some TODOs are doomed to remain there forever, and the Android Open Source Project is no exception.
Today I will tell you about the funniest jokes from AOSP (Android Open Source Project) which I came across while studying the source code.

Disclaimer: The article will not reveal new knowledge or approaches, just a little fun. There is also a desire to show that everywhere there are problems – even in large projects carried out by highly qualified specialists. And that's okay.

Someday we will fix the tests

Let's take a look at a piece of code.

Actually, the condition is added only for tests and does not provide any functional usefulness. TODO from the beginning of the 24th year. Such a case, when the source code is adjusted for the sake of tests, looks like an antipattern.

Located in class CarDisplayCompatScaleProviderUpdatableImpl.

By the way, another example with TODO in Javadoc – DragEvent.

Never put off improving your documentation until later. It is better to immediately correct the documentation if it becomes obvious that it is difficult to understand. Otherwise it will never be fixed.

It would be nice to add documentation

One more piece of code for the studio!

Seems pretty logical. It would be nice to have a document to describe the function arguments and the restrictions associated with them. Tudushka was left in 2013, and, most likely, there is no idea yet what this Javadoc should be 🙂

Lies in CommandsInterface.

Another example confirming that it is better to write documentation right away if you feel that it is necessary. It is located in ViewGroup.java.

This TODO has been hanging around since 2012. Let's hope that the dock will appear, because ViewGroup not the simplest class from the Android framework ( -_•)

How can this happen?

Lifecycle – how much is put into this word. Let's take a look at the code right away.

The code is in ActivityThread. Accordingly, this method comes from TransactionExecutor. And, it would seem, if we have activity in the started state and TransactionExecutor already called handleStartActivitythen our activity is in a started state. However, everything can change right during the execution of the method handleStartActivity.

They even left an intricate fuss about this in 2019, but it hasn’t been resolved yet. Post your ideas in the comments why this might happen.

A small workaround: we’ll definitely remove it

How often have you had to solve a problem through a workaround with the hope that a targeted solution will be applied in the future? I think that everyone has encountered this, and in a large number of cases the temporary remains permanent. ActivityThread did not change traditions.

I think there is no point in describing in detail what happens in the method. But this same workaround has been alive since 2021.

Descendants will understand exactly what's going on

Let's look at this kind of TODO, which is in View.java.

Do you see something strange in the code above? The first thing that may catch your eye is that TODO is absolutely not informative. It was added in 2011, and apparently since then it has not been possible to understand what to use here.

But there is one more nuance, if you look closely.

Inside a method getHorizontalScrollFactor method is called getVerticalScrollFactor. But we will no longer be able to reveal this secret of a forgotten civilization. And, of course, the important point is that this method is annotated @UnsupportedAppUsage.

Quiz

I think you know that in Android we have a UI thread (aka MainThread). There are also RenderThread.java but we won’t dive into it now. You can change the UI of our application only with MainThread. Let's look at this TODO, which is located in ViewGroup.java.

There is such a settings section – developer optionsin which we can enable various application debugging settings, including debugging of UI components. For example, Show Layout Bounds – this setting shows the borders of all elements on the screen.

So, inside the class ViewGroup There are special methods that are called when we enable such options. This includes calling the method that you saw above in the screenshot. And the TODO explicitly states that logic with debugLines will not work with multiple UI threads in one process.

I wonder why this TODO appeared there and why it has not yet been resolved (and most likely will not be resolved)? Write your thoughts in the comments.

Slow hashCode

Have you ever come across the collections that appeared with Android? For example, with SparseArray? It is better to look at why it appeared and what its advantages are by following the link in the official doc. But it’s interesting that this collection has a twin brother called SparseRectFArrayused in graphical computing. Let's look at his method hashCode.

Question: “How can this hash function be improved?” And what are its shortcomings now? However, these shortcomings have not prevented her from working since 2014.

All users are equal (but not always)

Let's take a look in DexPathList.javawhich is in the package dalvik.system. You can read about Dalvik and ART in the article Android from the inside: comparison of Dalvik and ART. Here we have not exactly TODO, but it’s also interesting.

We will not dive into the class itself and the logic of its work (if the audience is interested, perhaps a separate article will be published about this). The most interesting thing is that the method was not deleted just because it was used reflection from a third party application.

Disclaimer: Dalvik is not very relevant now, since ART is used.

And now let's get to the results.

Results

It is important to note that the presence of old TODOs does not mean that the project is of poor quality or was made by bad engineers.

There are different cases, and in some of them it is really best to simply not touch TODO. But if you want to put some TODO on your code right now, think a few times – maybe it makes sense to fix it right away, because there is always a chance that it will remain in the code forever. So as not to end up with something like this.

And second: if you dive into any big project, you can always find a lot of fun and interesting things in the comments and TODO.

PS Write what funny TODOs or comments you came across in development.