Google Docs link in Folder -> "Shortcut disabled"

[ChimeraLove]

Hi,
It used to work before,
Need to have both Google Drive and Docs

1. Go to Drive
2. Choose a doc file
2. Click the 3 dots menu and then "Add to home screen"
3. Link on desktop works it open Google Docs
4. Put it inside folder
5. Click link, now "Shortcut disabled"

Thanks

Update: actually its links in general that become disabled inside folders

[juwlz]

Yes, I've reported exactly the same issue too.

[Wayland]

Same problem.

[franc]

Same issue since a while.
Unfortunately LL development (and bugfix) is now really dead
I guess it's only on Android 9+ (or earlier even).
Still best and by far mightiest Launcher of all

Xiaomi Mi A1 mit Android 9

[franc]

I found a kind of solution for these dead links, a workaround:
I use the LL-Tap-event (in settings for that icon > properties) and created a simple "Browse HTML"-Action-Task in Tasker App for it. The URL in this action is the URL the icon / shortcut should open (and doesn't when moved into a LL folder).

It's not very handy, but i have only a few direct browser icons, so for each i created a Task in Tasker.
This works and no more error message from LL "shortcut disabled"
Frank

[papa4narchia]

Hi,
could you explain how you did this in Tasker?
I do not find the right action / how to submit the URL to my browser for it to open in a task.
Regards,
Tobi

[franc]

Task's Name is abritrary, then add an Action:

Action: Net > Browse URL
URL: <your icon's URL>

Very, very simple thing. You need to know the URL of your Icon, though.
For me it was some website, on which I wanted to have a direct link in a folder, but the thread-beginner had some Google Doc Link, which I don't know if it is easy to get. If there is a Link, then it should be as easy. If it is some intent, then it might be some more difficulties and I would try it with one of those handy AutoApps, I think there must be one for it.
Hope helps.

[franc]

I found that Google Assistant can now create shortcuts to home screen. Unfortunately only for "Routines" but it's good enough.
Only the move into a LL-folder makes them disabled for LL, as in this thread posted.
But here I don't know at all how to trigger them with Tasker.
It must be a way, with AutoTools at least.
If I found out I will post it here...
If someone found it, please feel free to post it too
Thank

[franc]

...
1. Go to Drive
2. Choose a doc file
2. Click the 3 dots menu and then "Add to home screen"
3. Link on desktop works it open Google Docs
4. Put it inside folder
5. Click link, now "Shortcut disabled"
...
Update: actually its links in general that become disabled inside folders

I just tested it on a clean install of LL: Wipe data of LL, create a folder, move some shortcut in it and try to run it: it is the same, nothing to do with to much garbage in my settings.
Android 9 with Xiaomi Mi A1.

[franc]

Strange thing:
I made some experiments in the meantime, so I created a Shortcut for a Google Home Routine on the homescreen, made a LL-Backup, moved the shortcut to a folder and moved it back out of this folder (context-menu: Move out of folder) and made another LL-Backup.
The two backups had nearly no difference. Only an increment in a number in core/statistics, which I consider as not a real difference.
Thing is, the shortcut doesnt work, when its moved into a folder, this is well-known and the subject of this thread. But the shortcut doesn't work neither, when it is moved back out of this folder!
The move into a folder destroys the shortcut's functionality ("Shortcut disabled").
But in the backup this destruction is invisible!

Next thing to check was, if the backups restore to the same behavior, what did not do.
The Backup with the working Shortcut on the home screen restored to a not-working shortcut.
If the shortcut is broken, it will stay broken, not related to the backup-restore.
The backup is anyway only the folder's content:
/data/data/net.pierrox.lightning_launcher_extreme/files

So my conclusion is, that it is a real bug inside the code of LL

[TrianguloY]

They are app shortcuts, their availability dependes on whether the app currently has the shortcut or not, the intent of both items is the same, but after moving it the app shortcut is removed so the intent no longer works. Your can check this by showing the app shortcuts (for example in the swipe up event). After adding the shortcut swiping up will show the same shortcut, but after moving it to the folder it will not.
Perhaps the item is deleted before adding it again in the folder, and triggers the removal of the app shortcut.

But this means there is a really easy workaround (and I feel dumb for not finding it before).

1) Duplicate the shortcut (in edit mode the [+]] button)
2) Move one item to the second container (the original or the copy, doesn't matter)
3) Delete the item in the original container.

This method ensures that there is always at least one shortcut active, so it doesn't get deleted

Does it work for you?

[franc]

Wow!
This works
Thank!!!

I don't feel dumb at all that I didn't find this work-around

So this thread is solved!
Before moving a shortcut into a folder, copy it and then move it, delete the first one (or not).

Great!

[franc]

They are app shortcuts, their availability dependes on whether the app currently has the shortcut or not, the intent of both items is the same...

But where are these shortcuts saved in the Backup?
How can it be, that I don't find it in comparison of a backup with a working shortcut and one without?
The conclusion would be, that restoring a backup would break all shortcuts, but this is not.

[TrianguloY]

They are app shortcuts, their availability dependes on whether the app currently has the shortcut or not, the intent of both items is the same...

But where are these shortcuts saved in the Backup?
How can it be, that I don't find it in comparison of a backup with a working shortcut and one without?
The conclusion would be, that restoring a backup would break all shortcuts, but this is not.

Good question. I don't have the exact details so my explanation may be slightly wrong, but this is what I think happens.

Since Android...can't remember version, apps can now register what is called 'app shortcuts'. This is a list of shortcuts that the app manually registers (with a special api) and can remove at any time. This list is shown when you use the action 'show app shortcuts'. Those shortcuts use an identifier given by the app (or more precisely by android with some data from the app) and their intent look like this (which you can check using a script to retrieve the intent uri of an item).

#Intent;action=net.pierrox.lightning_launcher.APP_SHORTCUT;S.id=driveShortcut_abcdeffhijklmnopqrstuvwxyz1234567890;S.pkg=com.google.android.apps.docs;end

This intent, when launched, opens the Google docs app, which takes the id and does the corresponding action based on the shortcuts list. The action is from ll, which perhaps means that the launcher converts this internal intent to a different one, unfortunately I haven't checked.
In any case, if the app removes the shortcut, the pair id->action is removed, so when you try to launch it again it says 'not found' because now that id doesn't have a corresponding action.

I haven't checked backups in a long time, but you should be able to find the specific shortcut intent there. The reason the backups aren't different is because they aren't. The intent is the same, the difference is whether the corresponding app has the id-action pair present or not. This is also why restoring a previously working backup does not fix the issue, because the corresponding pair is missing from the app, not the launcher.

As I discovered, moving the shortcut alone seems to remove the old item THEN create the new one, and this triggers the shortcut (the pair) removal from the app. Restoring a backup probably doesn't trigger the removal, so the shortcut remains usable if you restore a backup while the pair is present.