element-android
element-android copied to clipboard
Increase max length of voice messages to 15m (PSG-663)
Relates to: vector-im/element-ios#5415 Relates to: https://github.com/vector-im/element-android/issues/4160
Signed-off-by: Johannes Marbach [email protected]
Type of change
- [x] Feature
- [ ] Bugfix
- [ ] Technical
- [ ] Other :
Content
This raises the recording limit for voice messages from 2 to 15 minutes.
Motivation and context
vector-im/element-ios#5415
Tests
- Start recording a voice message
- Lock the recording or keep holding the button past 2 minutes
- See that the recording is still running
Tested devices
- [ ] Physical
- [x] Emulator
- OS version(s): 12
Checklist
- [x] Changes has been tested on an Android device or Android emulator with API 21
- [ ] UI change has been tested on both light and dark themes
- [ ] Accessibility has been taken into account. See https://github.com/vector-im/element-android/blob/develop/CONTRIBUTING.md#accessibility
- [x] Pull request is based on the develop branch
- [x] Pull request includes a new file under ./changelog.d. See https://github.com/vector-im/element-android/blob/develop/CONTRIBUTING.md#changelog
- [ ] Pull request includes screenshots or videos if containing UI changes
- [x] Pull request includes a sign off
- [x] You've made a self review of your PR
- [ ] If you have modified the screen flow, or added new screens to the application, you have updated the test UiAllScreensSanityTest.allScreensTest()
You can rebase the branch to avoid CI Lint job failing. It has now been fixed.
After some tests on my device (Nokia 7.2, Android 11) I have got a non responding app at around 6 minutes of recording: the UI was freezed. But I could send the recording of around 11 minutes. There may be some memory or threading issue, I don't know exactly. Can you test a long recording to check if you have the same behavior?
Hm, testing in the emulator, I'm hitting an OOM crash on longer recordings.
java.lang.OutOfMemoryError: Failed to allocate a 216 byte allocation with 1987280 free bytes and 1940KB until OOM, target footprint 201326592, growth limit 201326592; giving up on allocation because <1% of heap free after GC.
at java.util.ArrayList.<init>(ArrayList.java:166)
at kotlin.collections.CollectionsKt___CollectionsKt.takeLast(_Collections.kt:917)
at im.vector.app.features.voice.AudioWaveformView.handleNewFftList(AudioWaveformView.kt:161)
at im.vector.app.features.voice.AudioWaveformView.add(AudioWaveformView.kt:99)
at im.vector.app.features.home.room.detail.composer.voice.VoiceMessageViews.renderRecordingWaveform(VoiceMessageViews.kt:352)
at im.vector.app.features.home.room.detail.composer.voice.VoiceMessageRecorderView.onUpdate(VoiceMessageRecorderView.kt:228)
at im.vector.app.features.home.room.detail.timeline.helper.AudioMessagePlaybackTracker.setState$lambda-5(AudioMessagePlaybackTracker.kt:72)
at im.vector.app.features.home.room.detail.timeline.helper.AudioMessagePlaybackTracker.$r8$lambda$sBlsGupRu4nYAHWT2P9ZLOQIiQ8(Unknown Source:0)
at im.vector.app.features.home.room.detail.timeline.helper.AudioMessagePlaybackTracker$$ExternalSyntheticLambda1.run(Unknown Source:8)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:7842)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
After some tests on my device (Nokia 7.2, Android 11) I have got a non responding app at around 6 minutes of recording: the UI was freezed. But I could send the recording of around 11 minutes. There may be some memory or threading issue, I don't know exactly. Can you test a long recording to check if you have the same behavior?
Hm, testing in the emulator, I'm hitting an OOM crash on longer recordings.
java.lang.OutOfMemoryError: Failed to allocate a 216 byte allocation with 1987280 free bytes and 1940KB until OOM, target footprint 201326592, growth limit 201326592; giving up on allocation because <1% of heap free after GC. at java.util.ArrayList.<init>(ArrayList.java:166) at kotlin.collections.CollectionsKt___CollectionsKt.takeLast(_Collections.kt:917) at im.vector.app.features.voice.AudioWaveformView.handleNewFftList(AudioWaveformView.kt:161) at im.vector.app.features.voice.AudioWaveformView.add(AudioWaveformView.kt:99) at im.vector.app.features.home.room.detail.composer.voice.VoiceMessageViews.renderRecordingWaveform(VoiceMessageViews.kt:352) at im.vector.app.features.home.room.detail.composer.voice.VoiceMessageRecorderView.onUpdate(VoiceMessageRecorderView.kt:228) at im.vector.app.features.home.room.detail.timeline.helper.AudioMessagePlaybackTracker.setState$lambda-5(AudioMessagePlaybackTracker.kt:72) at im.vector.app.features.home.room.detail.timeline.helper.AudioMessagePlaybackTracker.$r8$lambda$sBlsGupRu4nYAHWT2P9ZLOQIiQ8(Unknown Source:0) at im.vector.app.features.home.room.detail.timeline.helper.AudioMessagePlaybackTracker$$ExternalSyntheticLambda1.run(Unknown Source:8) at android.os.Handler.handleCallback(Handler.java:938) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loopOnce(Looper.java:201) at android.os.Looper.loop(Looper.java:288) at android.app.ActivityThread.main(ActivityThread.java:7842) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
And profiling the memory usage I see it keeps increasing while the recording is in progress. So it will end either by Out Of Memory exception or application not responding on long recording. I am afraid this is the reason we set a 2 minutes limit on the current implementation of audio recording.
@jakewb-b FYI ☝️
I had a strange behavior with my 15 minutes recording. I have let it stop automatically. It stops effectively at 15 minutes but I got a more than 17 minutes of recording... I don't know where it comes from. Will try again to understand with another timer to check the time. I suspect a drift in the timer clock.

I had a strange behavior with my 15 minutes recording. I have let it stop automatically. It stops effectively at 15 minutes but I got a more than 17 minutes of recording... I don't know where it comes from. Will try again to understand with another timer to check the time. I suspect a drift in the timer clock.
![]()
I confirm there is more than 2 minutes drift when recording during 15 minutes.
Also, we set a flag to keep the screen on during recording but it seems it is not reset after it has ended. My screen does not go to sleep after a recording is done. The activityListeners
in AudioMessagePlaybackTracker
may not be called? Let me know if you can check. Sorry for asking so many changes...
I had a strange behavior with my 15 minutes recording. I have let it stop automatically. It stops effectively at 15 minutes but I got a more than 17 minutes of recording... I don't know where it comes from. Will try again to understand with another timer to check the time. I suspect a drift in the timer clock.
I confirm there is more than 2 minutes drift when recording during 15 minutes.
After some investigations, it may be partially due to our CountUpTimer
implementation. When logging, it seems the counter is drifting from a few milliseconds at each tick. And maybe this drift is increasing as the time goes, to be confirmed.
Also, we set a flag to keep the screen on during recording but it seems it is not reset after it has ended. My screen does not go to sleep after a recording is done. The
activityListeners
inAudioMessagePlaybackTracker
may not be called? Let me know if you can check. Sorry for asking so many changes...
Maxime, you're an awesome tester!
I think you're right. There was nothing that tracked the end of a recording. I've added a few calls in AudioMessageHelper.kt
and can confirm that we now it false -> endKeepScreenOn()
in RoomDetailActivity.kt
.
Warnings | |
---|---|
:warning: |
vector/src/main/java/im/vector/app/features/home/room/detail/composer/voice/VoiceMessageViews.kt#L63 - Custom view |
:warning: |
vector/src/main/java/im/vector/app/features/home/room/detail/composer/voice/VoiceMessageViews.kt#L63 - Custom view |
:warning: |
vector/src/main/java/im/vector/app/features/home/room/detail/composer/voice/VoiceMessageViews.kt#L63 - |
:warning: |
vector/src/main/java/im/vector/app/features/home/room/detail/composer/voice/VoiceMessageViews.kt#L63 - |
:warning: |
vector/src/main/java/im/vector/app/features/home/room/detail/timeline/item/MessageVoiceItem.kt#L112 - Custom view |
:warning: |
vector/src/main/java/im/vector/app/features/home/room/detail/timeline/item/MessageVoiceItem.kt#L112 - Custom view |
:warning: |
vector/src/main/java/im/vector/app/features/home/room/detail/timeline/item/MessageVoiceItem.kt#L112 - |
:warning: |
vector/src/main/java/im/vector/app/features/home/room/detail/timeline/item/MessageVoiceItem.kt#L112 - |
Generated by :no_entry_sign: dangerJS against fced3de8ef50c82bb7bfb04e894956c880ede375
I had a strange behavior with my 15 minutes recording. I have let it stop automatically. It stops effectively at 15 minutes but I got a more than 17 minutes of recording... I don't know where it comes from. Will try again to understand with another timer to check the time. I suspect a drift in the timer clock.
I confirm there is more than 2 minutes drift when recording during 15 minutes.
After some investigations, it may be partially due to our
CountUpTimer
implementation. When logging, it seems the counter is drifting from a few milliseconds at each tick. And maybe this drift is increasing as the time goes, to be confirmed.
I would suggest to try to use the CountDownTimer
coming from Android SDK instead to see if it can fix this issue. And maybe, with this, we will no longer need to call post
method on some views inside the callback on each tick?
@Johennes is the PR ready to be merged?
@bmarty sorry this got forgotten about on my end. We actually decided not to follow through on this at this time. Increasing the length limit has amplified a number of other bugs that greatly diminished the usefulness of this change and we haven't been able to easily fix all of them. I'll close this for now and we may return at a later time.