I need to check the code and clean it up a bit before pushing it to public, it’s just too ugly right now because of the missing parts and commented out code.
15 Likes
if you need it, i volunteer to test it on 10 ii
1 Like
Hello,
Any progress with this? I would really love to use the Camera 2 API on Droidian, the Camera 1 is very basic and can’t take decent photos with it.
8 Likes
Any progress anyone could share so others could join?
Taking a photo from a moving target is pretty much impossible with X10III at the moment… Extracting frames from videos it is 
1 Like
Just letting everyone know that I have given up on this (for now). There is a multitude of reasons and I will list them here because I feel some things regarding SFOS needs to be said:
- I received numerous messages from community regarding Camera2 api development - everyone wants to test. This is all fine but literally not a single person contacted me with actual information/help how to set up dev enviroment for development and testing camera. I have spent a lot of time to make this work but I have a company to run and family that I want to spend time with and just didn’t want to countinue hacking
- There is no documention provided by Jolla regarding core system development. There is not even a README file on github. To make things work, stock camera app is closed source. Providing a link to C++ header file is not enough if you want to attract people to help out
- Looking at last couple of releases I see only minor updates or updates that are largely handled by community. Android support was updated but aside from having “bigger version number” no real improvements regarding android support have been made (as a matter of fact, a lot of android apps stopped working due to the way android app rendering was handled)
- More and more apps (that I use regularly) on android rely on having bootloader locked and this is a trend that will over time make android support less and less useful
- android support for NFC, bluetooth (other than audio), biometrics is non-existent. I regularly use apps that require biometrics (fingerprint reader) that provide no alternative
All in all, I feel that the feature gap between android and SFOS has grown so much that it is nearly impossible to catch up with the current state of things. I don’t really see any real roadmap and plan made by jolla and a lot of OS (stock apps) are still closed source which makes it very hard for community to move this OS into brighter future.
For now, I’m keeping my 10 III in drawer and using Xperia 5 IV with android as a daily driver. Until I see some significant progress made regarding HW compatibility with 10 III (echo cancellation fixed, battery usage and other reported stuff) I will not be returning to SFOS.
As a person that runs business I feel what Jolla does currently will eventually kill off SFOS completely. The only way to get back on track is to partner with companies like Volla / Gigaset, fairphone, pinephone and similar which already have a vibrant community and support and opens up ability to ship phones with locked bootloader and overall better user experience.
I feel that sony open source program is just not worth it - by the time OS gets open sourced devices are already 1 year old and hard to buy…
These are just my 2 cents on the matter, I might be wrong but given the current state of things buying sony device + SFOS licence and then have so much bugs and reliability problems is just not worth it.
28 Likes
Hi @mjun, I understand your opinion and partially share some of the frustration.
For this subject alone, the header linked in this post is from a piece of software called droidmedia.
My understanding from the steps to build a hardware adaptation is that droidmedia is actually an Android package with hybris interface.
There are at least two clients for it that I know of: gstreamer1.0-droid plugin (which makes the droid part available for gstreamer clients) and gecko-camera (before: gmp-droid) which makes droid parts available for the gecko browser.
So basically it’s a C interface to Android software, and you partly need to be an Android C++ developer to understand how to refactor it (but who is an Android developer and uses Sailfish…? yup you guessed it.)
So basically jolla camera needs to use droidmedia one way or another to work across devices with different android bases.
My frustration comes more in line with what I once heard rinigus saying: we can’t help with Camera2 api since we’re too busy with the proprietary VoLTE “solution” (sorry, I can’t find the exact place of the quote and I might remember it incorrectly)
(And sorry to be writing so late in this thread - I’ve postponed looking into this for some time. Only now I got to the point of my zenfone port needing Camera2 API too;)
6 Likes
Hi @mjun ,
I really appreciate the efforts you put into this. From your last post I got the intention, that you actually managed to build the droidmedia package.
I just procrastinated from learning, looked into it shortly and I totally agree with you: the documentation is not that well. I
f you finally got it working could you imagine to share some of your insights? Maybe someone else can pick up your work and go on with that?
I don’t want to bother you and really appreciate the time you spend!
Re VoLTE and Camera 2: not that I had a chance to work on VoLTE either, but it is priority for me. I expect that VoLTE would be a major obstacle in some time and there is no difference on whether you have a camera or not if you cannot use your phone as a phone. But priorities for other developers could be different…
10 Likes
To be honest, I don’t think the camera 2 api would make a huge difference for Linux based phones. I mean, for planning to use the phone as a… phone.
However, there are many old phones that are sitting in a drawer somewhere, or end up in the garbage dump. Having access to Camera 2 API (and a way to install a working Linux distro, such as Sailfish, Ubuntu Touch, Droidian, etc.) would give many of those phones a new life. They could be used for security applications (remote security cams in areas where there is no electricity), time lapse cameras, baby monitors, and so on.
So having access to the Camera 2 API would possibly bring more people to try the non android OSes.
1 Like
Xperia 10 III has the ultrawide and optical-zoom lenses disabled because there is a firmware issue in camera1 api that makes the selfie lens inaccessible. camera2 api would solve that.
plus, features like (true) manual-focus (not what adv-camera calls manual-focus) and HDR are only in camera2.
3 Likes
but really, i came here to say that opencamera with camera2 api supports all 4 lenses in SFOS android app support, IF you are very careful (and you enabled them in camxoverridesettings.txt).
[+] button changes main => ultrawide
[+] button again changes ultrawide => zoom
[+] button switches to WEIRD SELFIE MODE, and then any further action CRASHES the app.
so INSTEAD, to return to main camera lens, press selfie-camera twice. this works from any of the 3 back lenses.
selfie toggle button works normally, as long as youre not in the weird duplicate selfie camera mode (at which point, every action crashes the app).
if you get into the weird duplicate selfie camera, the only way i know of to make opencamera work again is to restart appsupport. restarting cameraserver no longer works as of SFOS 4.5 (although it totally DOES work in SFOS 4.4)
NOTE: opencamera in camera1 does NOT work with all 4 lenses. it does something akin to what jolla-camera does, and breaks on selfie mode. it is somewhat alarming that opencamera lens switching doesn’t work perfectly even with camera2 api, though.
4 Likes
Maybe its time to release special versions of Jolla-/advanced-Camera-App which will adress this issues
this thread is about why you cant do that. the camera api used in SFOS is camera1. jolla believes (apparently correctly) that no solution aside from implementing camera2 api will work (although i STILL see weirdness in camera2 api, it is a weirdness that can very likely CAN be managed in software once camera2 is impld)
jolla ALSO decided that its not worth their devs time, and asked the community to do it for them for free. someone valiantly tried, found that jolla makes community devel of system stuff difficulty on purpose, and gave up.
this is the sonyxperidadev bug report:
https://github.com/sonyxperiadev/bug_tracker/issues/732
5 Likes
Camera 2.0 was released with Android 5.0 in November 2014, almost 9 (!) years ago.
Its a real shame that Jolla has never found the time to implement it
1 Like
@mal, did you progress with cleaning up your code in the past 7,5 months? Even if not, why don’t you just publish your work in order to enable any collaboration on Camera API 2 in SailfishOS?
P.S.: We have regularly seen such outcomes as this (frustrated developer ceases working on something, because sailors did never seriously reply, only formally), which is one crucial aspect of Jolla’s failure to foster and collaborate with a developer community.
9 Likes
Jolla is literally in administration with probably over half of their staff taking redundancy or effectively massive pay cuts.
I would be surprised if Jolla deliberately made system development difficult unless it’s part of their proprietary code or makes significant demands on their time. Especially since they’ll be deprived of Camera2 goodness as well on their 10 iiis
For me, Snap Camera works very well on Dalvik though I haven’t used it with a >2 camera phone yet.
How far has anyone gotten with native Camera2 API?
well, one could certainly argue about the level of intent, deliberate/careless/whatever, but also bear in mind that i was saying what someone ELSE found to be the case. in any case, this is what i was referring to:
at the very least, this is not the minimum level of community support that i think would be required to justify statements to the effect of ‘the community can implement it, we are too busy’, even though they really ARE just actually too busy.
3 Likes
During the summer I gave a look to the Camera 2 API, and here are some complements to the information @vlagged provided.
The main purpose of the task is to replace the underlying implementation of droidmedia with a Camera 2 API. But as a simpler target, I just tried to take a picture from Sailfish OS side, using a Camera 2 API function in droidmedia.
The first step is to compile the Android side of droidmedia. For this, I followed part of this tutorial: Sailfish X Xperia Android 10 Build and Flash | Sailfish OS Documentation namely
repo init -u https://github.com/mer-hybris/android.git -b $HAVERSION -m tagged-localbuild.xml
repo sync -jX --fetch-submodules
git clone --recurse-submodules https://github.com/mer-hybris/droid-src-sony droid-src -b "hybris-"$HAVERSION
ln -s droid-src/patches
droid-src/apply-patches.sh --mb
./setup-sources.sh --mb
source build/envsetup.sh
lunch aosp_$DEVICE-user
git clone https://github.com/sailfishos/droidmedia external/droidmedia
make libdroidmedia
This creates a library libdroidmedia.so under out/target/product/$HABUILD_DEVICE/system/lib64/libdroidmedia.so. I copy this library to a user directory on the phone (let’s call it devel).
The second step is to compile the libhybris glue of droidmedia for Sailfish OS side of things. I followed these steps in the SDK docker:
cd external/droimedia
mb2 -t SailfishOS-4.5-aarch64 -s rpm/droidmedia-devel.spec build
sb2 -t SailfishOS-4.5-aarch64.default -R rpm -U --force RPMS/droidmedia-devel-0.20170214.0-1.aarch64.rpm
This compile and install the libhybris glue in the SDK. I’ll use it later to compile a simple executable that is supposed to tkae a picture.
This small executable is made of the following main:
#include <QtQuick>
#include <QDebug>
#include <droidmediacamera2.h>
#include <sailfishapp.h>
void plop()
{
qDebug() << droid_media_camera2_get_number_of_cameras();
}
int main(int argc, char *argv[])
{
QScopedPointer<QGuiApplication> app(SailfishApp::application(argc, argv));
app->setOrganizationName("Demo");
app->setApplicationName("Sextant");
plop();
DroidMediaCamera2 *camera = droid_media_camera2_connect(1);
if (camera) {
qDebug() << droid_media_camera2_take_picture(camera);
//droid_media_camera2_disconnect(camera);
}
QScopedPointer<QQuickView> view(SailfishApp::createView());
view->setSource(SailfishApp::pathToMainQml());
view->show();
return app->exec();
}
As you see, it is calling a new droidmedia function droid_media_camera2_get_number_of_cameras() testing the listing of cameras and then calling droid_media_camera2_connect(1) to connect to the second listed camera and finally call droid_media_camera2_take_picture(camera) to shot a picture. These functions are basically the same than the currently existing ones, except that they are supposed to use a Camera 2 API.
I implemented these functions in droidmedia, see my branch GitHub - dcaliste/droidmedia at camera2, following various sources like android.hardware.camera2 | Android Developers or https://github.com/justinjoy/native-camera2/blob/master/app/src/main/jni/native-camera2-jni.cpp
To run the executable (called sextant here), I compile it within the SDK, using my new libhybris glue from my droidmedia branch and send it to the phone under the same devel directory. To run it, one needs to export the devel directory as a source for hybris libraries:
cd devel
HYBRIS_LD_LIBRARY_PATH=$PWD:/usr/libexec/droid-hybris/system/lib64 ./sextant
What is working: the listing of cameras and their characteristics. What is not working: shooting a picture :(( The Camera2 functions are not reporting any error as far as I know. It is reporting that the session is ready. But nothing happens.
So I’m stuck there. Since the Camera 2 implementation is open source in Android, I added some debug messages here and there, but was not able to understand what was wrong.
18 Likes
Interesting. I have some ideas.
2 Likes
Looking at a kotlin example they seem to initialize a few things before. Maybe some of this is helpful? https://github.com/android/camera-samples/blob/main/Camera2Basic/app/src/main/java/com/example/android/camera2/basic/fragments/CameraFragment.kt#L213
1 Like