Android pre-release v3.4 is now available (Updated 10/09/2025)

Beta Testing
22

It's true pluging don't work anymore.Missing selections in configurations

23

3.4.4 has just been released (changelog not published yet) which fixes the plugin issue

24

v3.4.4

1 Like
25

Sorry about the delay to fix this plugin issue. I actually thought I had released the new version but obviously didn't

1 Like
26

Joplin Mobile: 3.4.4
Tested without any plugins enabled.

I don't know if this is exclusive to this version. However, I wanted to report it as it came up in everyday usage and I couldn't find a duplicate report here.

In the editor, Markdown links with square bracket sets inside the title are not collapsed by default as expected. They don't collapse when moving the cursor off of them either.

[title [tag]](https://example.com) results in only [tag] and https://example.com being highlighted as link components. The remaining characters incorrectly retain normal text coloration.

27

I'm not sure that's valid markdown? Probably the square brackets should be escaped

28

Since Joplin uses CommonMark, the latest CommonMark Spec Links section says the following on brackets inside inline link text:

Brackets are allowed in the link text only if (a) they are backslash-escaped or (b) they appear as a matched pair of brackets, with an open bracket [, a sequence of zero or more inlines, and a close bracket ].

I see Example 512, its explanation prior, its entry into the CommonMark Spec Playground, and the same result in Joplin's reader view as illustrating that brackets inside link text is valid:

The link text may contain balanced brackets, but not unbalanced ones, unless they are escaped:

[link [foo [bar]]](/uri) renders link [foo [bar]].

You're correct that escaped brackets via backslashes or surrounding backticks would also solve the issue. That said, tools like Copy as Markdown use neither (though square brackets in link text is rare to begin with).

29

v3.4.5

30

v3.4.6

1 Like
31

@laurent There seems to be an issue with the latest pre-release Release android-v3.4.7 · laurent22/joplin-android · GitHub

It has built a new apk with the new version number on the about screen, but it does not include all the changes up to Android 3.4.7 · laurent22/joplin@f25db9b · GitHub, which might be to do with only 9/10 pipelines passing on that commit

For example, both Mobile: Fixes #12956: Resize the notes menu to the viewport when the keyboard is open by mrjo118 · Pull Request #13035 · laurent22/joplin · GitHub and Android: Fixes #13079: Fix dropdown menus are offset on Android 15+ by mrjo118 · Pull Request #13106 · laurent22/joplin · GitHub are not fixed in the latest pre-release, but when I build the code locally they are fixed, including if I build a release version of the apk

32

This is may be because the v3.4.7 APK was built from the release-3.4 branch, which does not contain these changes. The linked pull requests seem to only be present in dev, which should correspond to the v3.5.x releases going forward.

1 Like
33

Ah I see. Makes sense

34

v3.4.7

35

Hi @personalizedrefriger @laurent

I’ve just updated to the new version and am disappointed to notice that the scrollable/viewable tags area in the new tags dialog is much smaller than before.

For those of us that are used to quickly scanning and scrolling through our tags this is a real usability downgrade; some of us don’t use the search in this dialog but simply want to quickly scroll through and select tags and we know where to go to fast. Now that less tags are viewable on screen at once it feels like a waste of screen space and is a frustrating experience compared with previous versions - you can’t so quickly find what you want.

Are there plans to restore the add tag layout to where it was before? Or perhaps we could have an option for this? I hate to say it but the new tag screen really feels like a regression to me unfortunately. Hopefully it can be improved!

Many thanks as ever for all your work.

Best

Ben

36

The current tags window is scrollable (so if switching to landscape on a small screen, the whole window can be accessed), so I think if the default height of the window were increased to match the screen height, and the height of the tag selection area were to be increased to fill the added space, this might make it a similar user experience to before

1 Like
37

Thanks, yes that’s it - it’s the height of the scrollable area that needs to be increased. It used to be virtually the whole screen and this just feels natural and intuitive when you want to scroll through a large list.

Basically if you know your tags, even unrelated ones often act as cues for the mind to find the one you’re after - ie it’s natural and intuitive human user interface stuff. And this has been taken away somewhat.

38

@_Ben I’ve created PR Mobile: Increase height of tag association screen to cater for a larger tag list area by mrjo118 · Pull Request #13521 · laurent22/joplin · GitHub

1 Like
39

Thank you so much.

40

I've just tried your fix in 3.5.1 and it works very well - exactly what we were discussing. Thank you very much again for your help. Best, Ben

1 Like