When I record a video via com.fp5.camera, more frequently than not, its duration is exactly 1 s. An example is undermentioned:
Environment
The camera is versionName=v6.00.04.0038.16.0 (604000437).
I don’t think it’s necessary to also link and reference the other issue which got nothing to do with Fairphone or the Camera app at all.
About the actual problem you have. Have you tried updating the camera app? It seems there’s at least already a version starting with v7.00…
Note: I’m on Android 14. It seems they changed the app name fp5 → fp
Or downgrade…the one on my Fairphone with Android 13 has a slightly lower version number:
Both work as expected.
1 Like
@JohnnyD, it’s less semantic, but I’ve switched them around (apologies those using screen readers). If only Discourse supported oneboxes in <blockQuote>s. 
@JohnnyD, how have you updated yours? I don’t see an update at com.google.android.gms/.update.SystemUpdateActivity:
Though, I do get a keystore error upon invoking a check:
2025-05-27 23:25:46.749 8638-8655 Checkin com.google.android.gms I [CheckinApiChimeraService] onGetService 2025-05-27 23:25:46.750 8638-8655 Checkin com.google.android.gms I [CheckinApiStub] startCheckinAndGetCheckinResult 2025-05-27 23:25:46.767 8638-9268 Checkin com.google.android.gms I [CheckinIntentOperation] onHandleIntent, Intent { act=com.google.android.gms.checkin.CHECKIN_START_ACTION cat=[targeted_intent_op_prefix:.checkin.CheckinIntentOperation] cmp=com.google.android.gms/.chimera.GmsIntentOperationService (has extras) } 2025-05-27 23:25:46.772 8638-9268 GmsTaskScheduler com.google.android.gms W ScheduledCheckinGmsTaskService is not available. This may cause the task to be lost. 2025-05-27 23:25:46.776 8638-8655 BinderCallGmsPrvdr com.google.android.gms W Found invalid Chimera context. Getting Best guess RequestContext from trace. [CONTEXT service_id=357 ] 2025-05-27 23:25:46.777 8638-9268 Checkin com.google.android.gms I [CheckinOperation] Starting Checkin: Default Task Reason : 8 Force : true UserId : 0 Start time : 259104102 2025-05-27 23:25:46.777 8638-9268 CheckinUtil com.google.android.gms I Classify the device as Phone. [CONTEXT service_id=130 ] 2025-05-27 23:25:46.816 8638-9268 Checkin com.google.android.gms I [AndroidCheckinProtoModule] Checkin reason type: 8 attempt count: 1. 2025-05-27 23:25:46.870 1071-1071 sensors-hal and....sensors@2.0-service.multihal I batch:242, android.sensor.linear_acceleration/101, period=20000000, max_latency=0 2025-05-27 23:25:46.870 1071-1071 sensors-hal and....sensors@2.0-service.multihal I set_config:64, sample_period_ns is adjusted to 20000000 based on min/max delay_ns 2025-05-27 23:25:46.870 1071-1071 sensors-hal and....sensors@2.0-service.multihal I batch:251, android.sensor.linear_acceleration/101, period=20000000, max_latency=0 request completed 2025-05-27 23:25:46.871 1071-1071 sensors-hal and....sensors@2.0-service.multihal E flush:267, invalid flush request, active=0, oneshot=0 2025-05-27 23:25:46.871 1071-1071 sensors-hal and....sensors@2.0-service.multihal I activate:209, android.sensor.linear_acceleration/101 en=1 2025-05-27 23:25:46.871 1071-1071 sensors-hal and....sensors@2.0-service.multihal I get_qmi_debug_flag:241, support_qmi_debug : false 2025-05-27 23:25:46.872 1044-1246 minksocket ssgtzd E MinkIPC_QRTR_Service: client with node 1 port 453f went down 2025-05-27 23:25:46.874 1044-1246 minksocket ssgtzd E MinkIPC_QRTR_Service: client with node 1 port 4540 went down 2025-05-27 23:25:46.874 1044-1246 minksocket ssgtzd E MinkIPC_QRTR_Service: client with node 1 port 4541 went down 2025-05-27 23:25:46.875 1071-1071 sensors-hal and....sensors@2.0-service.multihal I send_sync_sensor_request:358, send sync request 2025-05-27 23:25:46.875 1071-1071 sensors-hal and....sensors@2.0-service.multihal I send_sync_sensor_request:384, wait for notification of response 2025-05-27 23:25:46.875 1044-1246 minksocket ssgtzd E MinkIPC_QRTR_Service: client with node 1 port 4542 went down 2025-05-27 23:25:46.876 1071-9271 sensors-hal and....sensors@2.0-service.multihal I ssc_conn_resp_cb:663, resp_value = 0 2025-05-27 23:25:46.876 1071-1071 sensors-hal and....sensors@2.0-service.multihal I send_sync_sensor_request:390, takes 1 ms to receive the response with 0 2025-05-27 23:25:46.876 1071-1071 sensors-hal and....sensors@2.0-service.multihal I activate:220, android.sensor.linear_acceleration/101 en=1 completed 2025-05-27 23:25:46.878 1071-1071 sensors-hal and....sensors@2.0-service.multihal I batch:242, android.sensor.rotation_vector/111, period=20000000, max_latency=0 2025-05-27 23:25:46.878 1071-1071 sensors-hal and....sensors@2.0-service.multihal I set_config:64, sample_period_ns is adjusted to 20000000 based on min/max delay_ns 2025-05-27 23:25:46.878 1071-1071 sensors-hal and....sensors@2.0-service.multihal I batch:251, android.sensor.rotation_vector/111, period=20000000, max_latency=0 request completed 2025-05-27 23:25:46.878 1071-1071 sensors-hal and....sensors@2.0-service.multihal I activate:209, android.sensor.rotation_vector/111 en=1 2025-05-27 23:25:46.879 1071-1071 sensors-hal and....sensors@2.0-service.multihal I get_qmi_debug_flag:241, support_qmi_debug : false 2025-05-27 23:25:46.879 1044-1246 minksocket ssgtzd E MinkIPC_QRTR_Service: client with node 1 port 4544 went down 2025-05-27 23:25:46.881 1044-1246 minksocket ssgtzd E MinkIPC_QRTR_Service: client with node 1 port 4545 went down 2025-05-27 23:25:46.882 1044-1246 minksocket ssgtzd E MinkIPC_QRTR_Service: client with node 1 port 4546 went down 2025-05-27 23:25:46.884 1071-1071 sensors-hal and....sensors@2.0-service.multihal I send_sync_sensor_request:358, send sync request 2025-05-27 23:25:46.884 1071-1071 sensors-hal and....sensors@2.0-service.multihal I send_sync_sensor_request:384, wait for notification of response 2025-05-27 23:25:46.884 1044-1246 minksocket ssgtzd E MinkIPC_QRTR_Service: client with node 1 port 4547 went down 2025-05-27 23:25:46.885 1071-9273 sensors-hal and....sensors@2.0-service.multihal I ssc_conn_resp_cb:663, resp_value = 0 2025-05-27 23:25:46.885 1071-1071 sensors-hal and....sensors@2.0-service.multihal I send_sync_sensor_request:390, takes 0 ms to receive the response with 0 2025-05-27 23:25:46.885 1071-1071 sensors-hal and....sensors@2.0-service.multihal I activate:220, android.sensor.rotation_vector/111 en=1 completed 2025-05-27 23:25:46.905 672-6618 keystore2 keystore2 W system/security/keystore2/src/remote_provisioning.rs:102 - Error occurred: system/security/keystore2/src/rkpd_client.rs:226: Trying to get to IRegistration service. Caused by: 0: system/security/keystore2/src/rkpd_client.rs:120: Trying to get IRPC name. 1: system/security/keystore2/src/globals.rs:440 2: Error::Km(r#HARDWARE_TYPE_UNAVAILABLE) 2025-05-27 23:25:46.908 645-654 DrmLibTime qseecomd D got the req here! ret=0 2025-05-27 23:25:46.908 645-654 DrmLibTime qseecomd D command id, time_cmd_id = 770 2025-05-27 23:25:46.908 645-654 DrmLibTime qseecomd D time_getutcsec starts! 2025-05-27 23:25:46.908 645-654 DrmLibTime qseecomd D QSEE Time Listener: time_getutcsec 2025-05-27 23:25:46.908 645-654 DrmLibTime qseecomd D QSEE Time Listener: get_utc_seconds 2025-05-27 23:25:46.908 645-654 DrmLibTime qseecomd D QSEE Time Listener: time_get_modem_time 2025-05-27 23:25:46.908 645-654 DrmLibTime qseecomd D QSEE Time Listener: Checking if ATS_MODEM is set or not. 2025-05-27 23:25:46.908 645-654 QC-time-services qseecomd D Lib:time_genoff_operation: pargs->base = 13 2025-05-27 23:25:46.908 645-654 QC-time-services qseecomd D Lib:time_genoff_operation: pargs->operation = 2 2025-05-27 23:25:46.908 645-654 QC-time-services qseecomd D Lib:time_genoff_operation: pargs->ts_val = 0 2025-05-27 23:25:46.909 645-654 QC-time-services qseecomd D Lib:time_genoff_operation: Send to server passed!! 2025-05-27 23:25:46.909 868-879 QC-time-services time_daemon D Daemon: Connection accepted:time_genoff 2025-05-27 23:25:46.910 868-9275 QC-time-services time_daemon D Daemon:Received base = 13, unit = 1, operation = 2,value = 0 2025-05-27 23:25:46.910 868-9275 QC-time-services time_daemon D Daemon:genoff_opr: Base = 13, val = 0, operation = 2 2025-05-27 23:25:46.910 868-9275 QC-time-services time_daemon D offset is: 1 for base: 13 2025-05-27 23:25:46.910 645-654 QC-time-services qseecomd E Receive Passed == base = 13, unit = 1, operation = 2, result = 0 2025-05-27 23:25:46.910 645-654 DrmLibTime qseecomd D QSEE Time Listener: ATS_MODEM is set. Try to retrieve it. 2025-05-27 23:25:46.911 868-879 QC-time-services time_daemon E Daemon: Time-services: Waiting to acceptconnection 2025-05-27 23:25:46.911 868-879 QC-time-services time_daemon D Daemon: Connection accepted:time_genoff 2025-05-27 23:25:46.912 868-9276 QC-time-services time_daemon D Daemon:Received base = 13, unit = 1, operation = 1,value = 0 2025-05-27 23:25:46.912 868-9276 QC-time-services time_daemon D Daemon:genoff_opr: Base = 13, val = 0, operation = 1 2025-05-27 23:25:46.912 868-9276 QC-time-services time_daemon D Daemon: genoff get for 13 2025-05-27 23:25:46.912 868-9276 QC-time-services time_daemon D Daemon:Value read from QTimer mseconds = 259107647 2025-05-27 23:25:46.912 868-9276 QC-time-services time_daemon D Daemon:Value read from RTC mseconds on boot = 6677700000 2025-05-27 23:25:46.912 868-9276 QC-time-services time_daemon D Daemon:Value read from QTimer mseconds = 259107647 2025-05-27 23:25:46.912 868-9276 QC-time-services time_daemon D Daemon:Value read from generic offset = 1713973216886 2025-05-27 23:25:46.912 868-9276 QC-time-services time_daemon D Daemon:Delta read on boot mseconds = 6677692313 2025-05-27 23:25:46.912 868-9276 QC-time-services time_daemon D Daemon:Final Time = 1720910016846 2025-05-27 23:25:46.912 645-654 DrmLibTime qseecomd D QSEE Time Listener: Time GenOff - seconds: 1720910016 2025-05-27 23:25:46.912 645-654 DrmLibTime qseecomd D time_getutcsec returns 0, sec = 1720910016; nsec = 0 2025-05-27 23:25:46.912 645-654 DrmLibTime qseecomd D time_getutcsec finished! 2025-05-27 23:25:46.912 645-654 DrmLibTime qseecomd D iotcl_continue_command finished! and return 0 2025-05-27 23:25:46.912 645-654 DrmLibTime qseecomd D before calling ioctl to read the next time_cmd 2025-05-27 23:25:46.913 868-879 QC-time-services time_daemon E Daemon: Time-services: Waiting to acceptconnection 2025-05-27 23:25:46.942 1071-9271 sensors-hal and....sensors@2.0-service.multihal I handle_indication_realtime:471, SCHED_FIFO(10) for qmi_cbk 2025-05-27 23:25:46.961 1071-9273 sensors-hal and....sensors@2.0-service.multihal I handle_indication_realtime:471, SCHED_FIFO(10) for qmi_cbk 2025-05-27 23:25:47.091 8732-8757 libc com.google.android.gms.unstable W Access denied finding property "persist.adb.tls_server.enable" 2025-05-27 23:25:47.087 8732-8732 binder:8732_1 com.google.android.gms.unstable W type=1400 audit(0.0:29019): avc: denied { read } for name="u:object_r:system_adbd_prop:s0" dev="tmpfs" ino=12676 scontext=u:r:gmscore_app:s0:c512,c768 tcontext=u:object_r:system_adbd_prop:s0 tclass=file permissive=0 app=com.google.android.gms 2025-05-27 23:25:47.158 8732-8757 AdrenoGLES-0 com.google.android.gms.unstable I QUALCOMM build : a3cdec2236, Ief33eea0db Build Date : 08/23/22 OpenGL ES Shader Compiler Version: EV031.35.01.12 Local Branch : Remote Branch : Remote Branch : Reconstruct Branch : 2025-05-27 23:25:47.158 8732-8757 AdrenoGLES-0 com.google.android.gms.unstable I Build Config : S P 10.0.7 AArch64 2025-05-27 23:25:47.158 8732-8757 AdrenoGLES-0 com.google.android.gms.unstable I Driver Path : /vendor/lib64/egl/libGLESv2_adreno.so 2025-05-27 23:25:47.162 8732-8757 AdrenoGLES-0 com.google.android.gms.unstable I PFP: 0x016dc094, ME: 0x00000000 2025-05-27 23:25:47.164 8732-8757 Adreno-AppProfiles com.google.android.gms.unstable W Could not find QSPM HAL service. Skipping adreno profile processing. 2025-05-27 23:25:47.203 1071-1071 sensors-hal and....sensors@2.0-service.multihal I activate:209, android.sensor.rotation_vector/111 en=0 2025-05-27 23:25:47.204 1071-1071 sensors-hal and....sensors@2.0-service.multihal I activate:220, android.sensor.rotation_vector/111 en=0 completed 2025-05-27 23:25:47.205 1044-1246 minksocket ssgtzd E MinkIPC_QRTR_Service: client with node 1 port 4548 went down 2025-05-27 23:25:47.207 1071-1071 sensors-hal and....sensors@2.0-service.multihal I activate:209, android.sensor.linear_acceleration/101 en=0 2025-05-27 23:25:47.207 1071-1071 sensors-hal and....sensors@2.0-service.multihal I activate:220, android.sensor.linear_acceleration/101 en=0 completed 2025-05-27 23:25:47.209 1044-1246 minksocket ssgtzd E MinkIPC_QRTR_Service: client with node 1 port 4543 went down 2025-05-27 23:25:47.387 28766-28877 native com....android.googlequicksearchbox I I0000 00:00:1748384747.387838 28877 soda_impl.cc:1747] Adding hotword timeout event 2025-05-27 23:25:47.393 28766-29023 ProxyAndro...gerBackend com....android.googlequicksearchbox W Too many Flogger logs received before configuration. Dropping old logs. 2025-05-27 23:25:47.393 28766-29023 ProxyAndro...gerBackend com....android.googlequicksearchbox W Too many Flogger logs received before configuration. Dropping old logs. 2025-05-27 23:25:47.394 28766-29023 ProxyAndro...gerBackend com....android.googlequicksearchbox W Too many Flogger logs received before configuration. Dropping old logs. 2025-05-27 23:25:47.486 28766-28798 word_detector_0 com....android.googlequicksearchbox W Reducing the number of considered missed Gc histogram windows from 132 to 100 2025-05-27 23:25:47.489 8638-9268 Checkin com.google.android.gms I [CheckinRequestProcessor] updateCheckinIdTokenFileFromResponse, Reading existing AID 2025-05-27 23:25:47.490 8638-9268 Checkin com.google.android.gms I [CheckinRequestProcessor] Default Task : Checkin Succeeded: https://android.googleapis.com/checkin (fragment #1). 2025-05-27 23:25:47.495 1448-1871 ActivityManager system_server D sync unfroze 9160 com.google.android.euicc for 3 2025-05-27 23:25:47.497 9160-9160 EuiccGoogle com.google.android.euicc I [2] CheckinCompletedReceiver.onReceive: intent action: com.google.android.checkin.CHECKIN_COMPLETE Check-in success: true 2025-05-27 23:25:47.498 22847-23037 BinderSender shizuku_server D onUidCachedChanged: uid=10064, cached=false 2025-05-27 23:25:47.498 22847-23037 BinderSender shizuku_server V Uid 10064 already starts
I certainly don’t see an entrant for com.fp5.camera at any application store:
-
play.google.com/store/apps/details?id=com.fp5.camera:We’re sorry, the requested URL was not found on this server.
-
f-droid.org/en/packages/com.fp5.camera:404 Page Not Found
-
No results found matching your query
Even if I manage to locate an APK, I’m uncertain that applications in /system can be updated by the user (insofar as the vendor signatures match, of course):
Do you know? The last time I tried was on an LGE distribution of AOSP 7.0.
You cant update the Camera manually
and I also have version 6…with FPOS Android 14 however 14.0 at the end
@JohnnyD you dont use FPOS?
1 Like
Are you on stock rom? On my FP5 with stock A14 and latest/May update:
com.fp5.camera
v6.00.04.0038.16.0
1 Like
@yvmuell and @k3dAR No I’m not on Stock-ROM/FPOS. I’m on /e/OS. But I was under the impression that this camera app comes directly from Fairphone, in other words is exactly the same app which they deploy in their stock OS. Why would Fairphone hand out different versions to /e/OS and even withhold potentially better versions for their own OS?!
Another version number doesnt mean better or worse. Did you check the linked topic also to the e/OS forum, where you might ( I dont know) find details? Here I would say its rather off topic,unless @rokejulianlockhart wants to discuss further.
1 Like
I searched a bit and now I understand…
You have Camera App from stock FP4, same appid and version:
https://cweiske.de/tagebuch/android-write-system-partition.htm
Edit: not you, but rokejulianlockhart 
1 Like
@k3dAR, I do? That’s untrue – the package ID contains fp5, as aforementioned. (pm list packages -f | grep fp5 returns package:/system/priv-app/FPCamera/FPCamera.apk=com.fp5.camera.) Additionally, you and @yvmuell have stated that you’ve the same version installed. Please elaborate.
@yvmuell, you’re correct that I’d rather get back to the problem at hand. Consequently, I’ve asked at /e/OS’s forum for an explanation to this discrepancy:
1 Like
Incredibly, @JohnnyD appears to be correct that his version is also from FP themselves:
I suppose I should contact FP ZenDesk about this, but I just can’t be bothered to wait for 4 months for a response. I’ll mention if I eventually do, unless anyone else here experiences the same problem with their installation. I’ll remember to check the camera version next time the OS updates, though.
1 Like
Sure it is, its just a bit unclear why @JohnnyD claims to have on their e/OS Fp5 v7 which seem to be the FP4 version. FP4 and FP5 camera app are not the same.
1 Like
I think there have been some misunderstandings, on all sites… so…
I didn’t claim anything. Agreed, I could have been more specific from the start in retro-perspective.
To be clear:
FP4 → /e/OS (Android 14, March 2025) → v7
FP5 → /e/OS (Android 13, March 2025) → v6
But it didn’t seem relevant to me at the time since I thought and I’m still thinking it’s the very same app we’re talking about. I did say there are different versions, though. Clearly meaning those apps are not exactly identical. If they were, why would I suggest up or downgrading? From my point of view it’s the same base app, only called differently and maybe configured a little bit differently. But for the vast majority of source code I’d say it’s pretty much the same.
In that respect I was saying there might be better app versions because all versions I use seem to work indeed better than the one the OP meantioned. I was also wondering why there are so many versions in the first place. I would have thought no matter the OS or phone version the app version would be everywhere the same. Hence my question…
However, I did confuse the Fairphone camera app with the /e/OS camera app. So my appologies. Consequently up and downgrading indeed turns out to be much more difficult now.
@JohnnyD, if you’re referring to com.fp5.camera, you have no way of knowing that, bar decompilation (and I believe it would breach ToS for me to even instruct on this). [1] A major version increment usually represents backward ABI incompatibility, which would indicate the opposite of your presumption, because that’s generally caused by major refactor.