Pinephone Pro

• Performance: 3/5
• Affordability: A bit expensive for the performance but decent for linux first devices
• Compatibility: 4/5
• Battery Life: 2/5

Setup information

• OS: Danct Archlinux 2025/07/28 (Updated 2025/12/01)
• Kernel: 6.15.6 Megi Danct
• DE: Phosh
• Mesa: 25.2.7
• Uboot: Megi 2024.04 uboot w/ rkbin

Hardware Supported

Hardware	Supported
GPS
aGPS ¹
Cameras
Microphone
Bluetooth
Modem
Accel/Tilt
Orientation/Gyroscope
Light/Proximity

¹ Not hardware but important usability feature, not built in and requires a 3rd party python script to use it

Cell Service

Cell service was tested in the US utilizing US Mobile MVNO, referral link, as it allows for easy testing of the 3 major US network providers. The downside is the TMobile service has deprioritized download speeds so your speeds can be on the slower side. Download/Upload speed tests were done using ookla speedtest.net and netflix fast.com with the data waster option enabled. As service seems to vary from moment to moment, I ran multiple tests and grabbed the best results for each section.

Note: US Mobile seems to think the EG25-G/PPP is a mobile hotspot device and will kick the line offline if you are on an unlimited plan and requires you to be on a by the gig/pooled line instead. Learned this the hard way by physically moving my personal sim from my FLX1 to the pinephone pro and the line went dead and required customer support and inserting it into my pixel 6 to fix it.

The eSIM adapter works on the PPP but it doesnt have a built in way to change profiles easily. It does not work with eSIM Manager, hopefully it will in the future as I see there are discussions and even commits related to enabling AT backend support.

US Mobile Light Speed (Tmobile)

Phone	Tech	Speedtest down	Fast down	Fast up	VoLTE / VoNR
PPP	4G
Pixel 6	5G
Pixel 6	4G

Performance

The PPP is not a fast device, while leagues faster than the original pinephone it does not hold a candle to other devices in its price point. The RK3399s with its 4GB of memory can be pretty limiting but is decent enough for non demanding end users that have some patience. Where it falls flat though is when it comes to doing development work that requires compliation or even with any application or framework that is compute heavy that isn't accelerated somewhere in hardware. The RK3399s even though is binned is still not really designed for such a small form factor so it gets very hot and as a result will start to throttle in any sustained workload, the modem itself also generates significant heat when in use which only exasterbates the problem when trying to use the device out in the real world. Luckily GTK4 and QT6 "should" all be accelerated automatically so most applications run just fine without any hassle. Browsing the web is not fast but is decent enough to not be painful to use and can even handle video playback in software.

Compatibility

The PPP is almost compatible with everything, its a mainline device running a downstream kernel that has been built into pretty much every mobile linux OS and works with every mobile linux DE. The SOC is way newer than the one in the pinephone so it has support for opengl ES 3.1 so it doesnt run into the same issues that the pinephone is running into now adays with GTK dropping GLES 2.0 support. It is sadly lacking support for vulkan so applications that are vulkan only or even applications that implement GLES as an after thought might run into issues. One example of this is the rust WGPU library which is the main library used most rust applications for getting hardware acceleration. WGPU gles implementation seems to be spotty on mobile linux so it doesn't actually work on the PPP so all rust GUI applications need to be forced to run in software. Some of the other qualcom mainline devices work around this by just running WGPU in vulkan but that isn't an option on the PPP. The good thing though is those are far and few in between and pine has a large community around it so when new mobile linux applications are developed they are usually tested on the PP or the PPP.

Other OS have varying levels of community support such as Sailfish, Ubuntu Touch, postmarketos and mobian. While sailfish and ubuntu touch are prodominetely OS used in halium devices they run on the PPP perfectly fine utilizing the mainline drivers for everything. UT on the PPP though does lack some features that make it hard to daily, OTA/Camera/Spotty Calls, compared to other halium UT devices. All the OS that the PPP runs though are all community supported with no involvment usually from the parent companies, with the exception of mobian with the mobian team officially supporting the PPP.

Android

Android support is handled by the upstream waydroid. Setting it up is pretty easy by installing waydroid from the danctnix repo or from aur. Another helpful tool is waydroid-helper which is also in the aur for easy install. Waydroid does not integrate with the system in anyway so theres no settings for it in the gnome settings app but waydroid helper does atleast make it easy to manager certain features such as mapping in folders and even stopping and starting the container from a GUI. Sensor passthrough is pretty limited which some work arounds existing such as for GPS with the following script geobridge. Waydroid performance is actually better than expected though there is a slight delay when tapping. Leaving it running will eat up limited resources so its best to keep it off, luckily startup time is under a minute so you can start it up just when needed and then shut it down.

Sensors passed to Android

Tested using Sensors Toolbox app

Sensor	Passed through
GPS
Cameras
Microphone
Bluetooth
Modem
Accelerometer
Geomagnetic
Orientation
Gyroscope
Light
Pressure
Proximity
Gravity
Linear Acceleration
Rotation Vector

Docking

The PPP similar to the original PP has excellent docking support. It supports video out natively through DP-Alt mode so you can use any dock that utilizes that standard or even plug directly into something like a NexDock for a laptop like experience. This level of docking support is what all other mobile linux devices should strive for and makes it great for using it as a single device to cover all your needs. It makes it super handy for traveling as it allows you to keep all your files in a single location and research information in a bigger screen and then take it to go with you when you are heading out.

What is missing though is a way to handle wireless docking such as the halium devices running UT that can wirelessly cast to a remote display via miracast. If the PPP does support miracast in hardware then no one has gotten around to getting the software side of it implemented and UT on the PPP does not have this feature implemented. There is limited development around miracast in general though so not sure if this is something someone will ever develop/research for the PPP.

Web Browsing

Web browsing works decently. Firefox runs well and comes with postmarketos mobile-config-firefox for a better experience on the mobile screen. Benchmarking results with speedometer 3.1 with scale set to 100% are below, based on results below kumo works the best for performance but stuggles with videos as shown in the next section. Kumo itself is relatively new so if you run into any issues please report them so they can be fixed, the developers are very active and friendly. Waydroid firefox actually has really good performance and scales really well since its an android app, just know since it requires waydroid running it will tear through your battery and resources so its not something you want to keep running all the time.

Media Playback

Below is a table of different video codecs and their playback performance. The hardware has support for decoding h264/h265/vp9 and there is work being done on adding in the software support though no timeline on when it will be widely avaliable in everything. Results seem to be pretty mixed though luckily almost everything is able to play h264 which is still pretty much everywhere. It does struggle to play some of the newer codecs that are starting to take over such as AV1 being limited to just 720p. Waydroid firefox struggles with everything so if you need a browser for video playback just stick with native firefox. Kumo seems to be in a weird part where it can play 720p av1 and vp9 but h264 stutters and seems to struggle.

Player Information

H.264/AVC

Player	1080p@30	720p@30
MPV
Clapper
Livi
Celluloid
Firefox
Waydroid Firefox
Kumo

H.265/HEVC

Player	1080p@30	720p@30
MPV
Clapper
Livi
Celluloid
Firefox
Waydroid Firefox
Kumo

AV1

Player	1080p@30	720p@30
MPV
Clapper
Livi
Celluloid
Firefox
Waydroid Firefox
Kumo

VP9

Player	1080p@30	720p@30
MPV
Clapper
Livi
Celluloid
Firefox
Waydroid Firefox
Kumo

Camera

Cameras on the PPP are working but not in a great position. The libcamera stack that is used across multiple apps such as gnome snapshot/camera and what the browsers use lack autofocus so its almost impossible to use in the real world as everything will be out of focus and blurry. There was a PoC that someone created for the rkisp for libcamera but looks like its been stuck and has not progressed upstream into libcamera. On the other hand Megapixles has autofocus and manual focus but the processing on it is very slow as it is all done on the CPU instead of the rkisp like libcamera. Megapixels processing by default also has a green tint to all the images though it can be worked around by using an external postprocessing script like mine or manually processing the images via darktables and/or gimp or modifying postprocessd to enable auto white balance in the raw processing step. Overall its great that the camera works at all so in a pinch you can make use of it but its not something you would want to use as your main camera for taking pictures. If autofocus support is added to libcamera in the future then the camera situation will be greatly improved as libcamera has way better performance than megapixels and the quality is already really good even without the image tuning. There is a WiP autofocus for the software isp in libcamera so maybe onces thats merged in we can use that as a base for designing the rkisp version for atleast a generic autofocus implementation and maybe down the line someone can implement the phase detection autofocus that the imx258 supports.

Library	Supported
Libcamera	¹

¹ Libcamera supports the sensors but as of this review, it is missing autofocus which is a hard requirement for actual usage

Abstraction Layer	Supported
LibMegapixels
Gstreamer
Pipewire

Example

Flashlights were pointed at the ceiling and everything left on auto, pixel 9 and Iphone 12 both have a night mode where it took 3s for the low light photos

Versions

Normal Temp Medium Light

Megapixels Postprocessd	Megapixels Personal	Gnome Snapshot

Pixel 9	iPhone 12

Normal Temp Low Light

Megapixels Postprocessd	Megapixels Personal	Gnome Snapshot

pixel 9	iPhone 12

Low Temp Medium Light

Megapixels Postprocessd	Megapixels Personal	Gnome Snapshot

pixel 9	iPhone 12

Low Temp Low Light

Megapixels Postprocessd	Megapixels Personal	Gnome Snapshot

pixel 9	iPhone 12

Battery Life

The phone is not great when it comes to active usage battery life. The RK3399s is a power hungry SOC and the PPP has a relatively small battery for the power draw of the SOC and will require charging throughout the day if you are a heavy phone user. Standby battery life is decent enough though and will last throughout the day, so for users that only need a phone for communication this is more that good enough. One major problem though is the phone seems to lose the battery percentage that it's at, with it sometimes just staying at 100% until the battery runs dry and the phone turns off. This problem is made even worse when utilizing suspend which seems to cause more problems with the battery percentage drifting off. One workaround for this seems to be removing the battery from the phone itself and holding the power button while the battery is unplugged. While this seems to temporarily fix the issue, this is not an ideal solution as you wont know your battery percentage is stuck so you cant rely on the battery not being almost dead when you need it. Since non suspended battery is not great you could end up in a situation where the phone didnt enter suspend and ate up your battery and you won't know until it suddenly dies on you. During the standby tests below, the phone was reporting that it still had 54% battery left when it suddenly shut off and would not turn back on until plugged in for a while to bring the battery back to life.

Testing was done using the following settings:

• Screen brightness set to 50%
• Screen timeout disabled
• Measured from 100% battery to device shutdown
• Without android unless specified
• With sim unless specified
• With Wifi enabled
• Video playback is 720p 30 fps h264
• Charge time tested on pinepower v1 desktop
• Prometheus polling every 15 seconds

Screen Time

Video Playback

Standby

• taken with sleepwalk enabled utilizing the default settings
  • SLEEP_STEP=30
  • SLEEP_MAX_SECS=600
  • WAKE_SECS=30

Charging

Charging Curve

• Prometheus polling every 5 seconds
• Measured from Sonoff S31 running esphome

Support

Support from Pine64 on the software side is nonexistent, especially now that they have officially discontinued the device and are no longer producing it. Even before the discontinuation the only official support pine provided was if something was broken on arrival but due to the low warranty period it was a rush job to go through that process of validating it and contacting them. I've had to contact them once for a separate pine device, keyboard, and the support itself was great for me. In that instance they sent me a replacement motherboard that I then had to go in and manually swap out and this was outside the warranty period at the time. Most of the support for the pine devices actually come from the community side. Due to the low price of entry for most pine devices, the community itself is massive especially compared to all other mobile linux communities. The PINE64 discord community is the primary place where everyone works and talks all pine things so if you are keeping up with the conversations you know everything going on with all the pine ecosystems. Most of the developers that work on pine devices all hangout in there so its great to ask them questions about what they are working on or if you run into issues. One of the great things about the community based development is that tons of people can pick it up and focus on things that are important for them, one of the main driving forces is Megi on the downstream kernel that is used everywhere on pine devices and you can read his blog, though its imporant to note that his development on the PPP has basically come to a standstill and is just carrying forward his current patches so we can continue to use newer linux kernels. Some members in the community though are not so keen on relying on a downstream kernel forever so there are a handful of memebers in the community that have been working on upstreaming bits and pieces to reduce the hard requirement of the downstream kerenel. Overall the community is great and very helpful so if you run into any issues or need help setting something up you can usually find someone willing to help you out. Though after so many years with the same pine devices it seems like actual development has slowed down a lot compared to a few years ago.

My Involvement / Disclosures

I've been involvement in multiple different pine related projects. Ive worked on Megapixels and Libcamera for the user camera software stack on implementing fixes and features for a better experience. My biggest contribution I'm most proud of would be locating the Raspberry PI imx258 (rear camera) driver in the pi downstream kernel and adapting it so it supports the imx258 variant used by the PPP and pushing it all upstream to the offical linux kernel which then made its way to megi's kernel and all pine devices. This brought an improvement to the camera quality in the driver side of things and also allows for less reliance on a downstream kernel for camera support.

The pinephone pro and all pine devices were all purchased with my own money. I have financially contributed to multiple developers in the pine/mobile linux ecosystem such as Megi (Kernel), Martijn (Megapixels), Guido (Phosh), PostmarketOS (OS), Ubuntu Touch (OS) and hope to continue to provide financial support.

My involvement with the pine community has mostly dwindled as I've moved to other devices in the mobile linux ecosystem but I do try to keep up with things that are happening as I still have some pine devices I wish to use more in the future such as my PineTab 2.

Conclusion

The Pinephone Pro is in a weird place when it comes to its future outlook and if it will ever reach the point of recommendation for daily usage. The hardware itself is decent enough for actual usage as long as the battery life is enough for you but the real problem comes from the software side with things being in a almost good enough state but not quite there. The camera situation is a big issue with it lacking autofocus in libcamera which is a hard requirement for actually using the camera in the real world, the megapixels side lacking performance and having the green tint issue by default. The battery percentage issue is also a big problem since you can't relying on your phone to not being close to dying when you need it. The dwindling amount of active developers working on the PPP itself also makes it hard to have a positive outlook on the future of the device as it seems like most developers have moved on to other devices/projects. The lack of first party software support from pine64 also means if the remaining developers in the community move on to other things then development will stop entirely. Luckily all the work that was done is still being carried forward so the PPP continues to run newer kernels and OS releases instead of rotting away like downstream only SBC boards but improvements seem to be coming at a dripping pace at this point. So if the PPP functions well enough for you as it currently stands then it can be a decent enough daily driver but I would not get it with the expectation that it will continue to improve as it has in the past.