On Windows.

The problem

Deeply nested directories are sometimes created during the course of software development. Imagine NPM packages, or C# solution with bin\debug directories and dlls named after project name. It quickly adds up. Issue is exacerbated with tendency of (some) development tools to suggest user dir as a home for new stuff. As a result we get a file path like C:\Users\user.name\source\project\MyAwesomeCompany.MyAwesomeProduct\MyAwesomeCompany.MyAwesomeProduct.Repository.Interface\bin\debug\MyAwesomeCompany.MyAwesomeProduct.Repository.Interface.dll

With even more creative names hitting the maximum path length of 260 characters is within reach :)

Deleting such path can prove difficult as doing it from Windows Explorer fails. Sometimes, a directory near the root can be renamed to one character which then helps with the delete. Sometimes, that does not work either.

Robocopy

One approach that consistently works and does not depend on third party utilities is using robocopy:

1. create an empty directory, e.g. c:\temp
2. open command prompt
3. copy and paste the following command, replacing the example directory with the one you want to delete:

robocopy c:\temp C:\Users\user.name\source\project\MyAwesomeCompany.MyAwesomeProduct /mir

Essentially, it tells robocopy to mirror the source directory onto the destination. Since the source is empty, it will delete everything in the destination. And it will do that quickly.

Bonus tip - if there is space somewhere in problem directory path, double quotes can be used:

robocopy c:\temp "C:\Users\user with a space\source\project\MyAwesomeCompany.My Awesome Product" /mir

Check whether Database inspector is running and stop it. Restart Android Studio. It helped me with:

java.lang.UnsatisfiedLinkError: No implementation found for long com.android.tools.profiler.support.network.HttpTracker$Connection.nextId() (tried Java_com_android_tools_profiler_support_network_HttpTracker_00024Connection_nextId and Java_com_android_tools_profiler_support_network_HttpTracker_00024Connection_nextId__)
 at com.android.tools.profiler.support.network.HttpTracker$Connection.nextId(Native Method)
 at com.android.tools.profiler.support.network.HttpTracker$Connection.<init>(HttpTracker.java:209)
 at com.android.tools.profiler.support.network.HttpTracker$Connection.<init>(HttpTracker.java:201)
 at com.android.tools.profiler.support.network.HttpTracker.trackConnection(HttpTracker.java:294)
 at com.android.tools.profiler.agent.okhttp.OkHttp3Interceptor.trackRequest(OkHttp3Interceptor.java:84)
 at com.android.tools.profiler.agent.okhttp.OkHttp3Interceptor.intercept(OkHttp3Interceptor.java:45)
 at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)

While working on a new feature for our app, I needed to add notifications. Copy and paste being developer’s best friends, I duly copy/pasted notifications for some other feature and went about adjusting the code. The plan was to display notifications as ongoing for a while so that they can’t be dismissed and then remove the ongoing flag to convert them to dismissible notifications. Everything worked without a hitch, except for the minor detail - Clear button in the notification shade which usually dismisses all notifications (bar ongoing ones) was not clearing these notifications. I could manually dismiss, but Clear would not remove them. After commenting out everything that could be commented out, after looking (in vain) into documentation, a thought occurred that too much may have been removed. Looking at the other feature’s notifications code I noticed that they are grouped.

And sure enough, after a group was assigned to notifications, Clear started working again.

This was not reproduced in sample app. However, in production app the issue and solution were real and reproducible. Possible explanation could be that in production app notifications transition thru several stages, while sample app was simpler.

What’s depressing here is that these things are not documented. Maybe this is explained somewhere, but after checking many notifications related pages in the docs, I was unable to find the rationale for the observed behavior.