Develop Bugs

Google Android and Linux for Kaiser Volume II

The original thread:http://forum.xda-developers.com/showthread.php?t=396782 needs an abridged version.
==================================================
Go to http://www.androidonhtc.com/ if you're just starting as it has the latest info. This thread is to highlight the info from the original thread only.
Latest Builds
Port Status
==================================================
Compiling Android Kernel for Kaiser
Modify initrd.gz files and CPIO handling
system.img mounting, editing and rebuilding with ext2/3
system.img mounting, editing and rebuilding with cramfs
Howto: Pull from git (new/update/resync)
[WIP] Configuring WiFi Interface
==================================================

system.img mounting, editing and rebuilding with ext2/3
seidler2547: Post:
Actually I've played with Android a bit for now, and I changed to ext3. It doesn't only work - it's much faster, too! Startup time during the blinking android is about half of what it was before.
How-To:
Code:
Code:
cd /tmp
# prepare dirs
mkdir a-sys
mkdir a-ext
# prepare image
dd if=/dev/zero of=/where/is/sdcard/system.img.new bs=1M count=64
mkfs.ext3 /where/is/sdcard/system.img.new
# mount old image and copy to new
mount -o loop /where/is/the/system.img a-sys
mount -o loop /where/is/sdcard/system.img.new a-ext
cp -a a-sys/* a-ext/
Now you can unmount the old image and happily edit in the new image. Don't forget to rename the system.img.new to system.img (after you have unmounted it).
In your initrd, in file init, where it says
Code:
losetup /dev/block/loop1 /sdcard/system.img
...
mount -t cramfs -o ro,noatime,nodiratime /dev/block/loop1 /system
change "-t cramfs" to "-t ext2" or "-t ext3". You can also change the path (/sdcard/system.img) there.
Click to expand...
Click to collapse

Modify initrd.gz files and CPIO handling
dcordes: Post:
There is no magick in the initrd files. They are .cpio.gz files, gzipped cpio balls. To extract a .cpio.gz file named initrd-android.cpio.gz simply do
Code:
gunzip initrd-android.cpio.gz && cpio -i < initrd.android.cpio
Then you have the extracted rootfs. The reverse way would be, assuming you are inside your rootfs folder:
Code:
find ./ | cpio -H newc -o | gzip > ../my-initr-android-with-custom-stuffs.cpio.gz
And yes, you can remove and add applications you find that way.
Click to expand...
Click to collapse

system.img mounting, editing and rebuilding with cramfs
dzo: Post:
Hi, you can't just use mkcramfs on the system folder because the permissions will be wrong. This is the script I use:
Code:
Code:
out/host/linux-x86/bin/genext2fs -d out/target/product/generic/system -b 80000 -a system.ext2
mount -o loop system.ext2 /mnt/system
cp /mnt/system/usr/keychars/qwerty2.kcm.bin /mnt/system/usr/keychars/vogue-ts.kcm.bin
cp com.google.android.maps.jar /mnt/system/framework
cp Maps.apk Street.apk /mnt/system/app
mkfs.cramfs /mnt/system system.img
umount /mnt/system
#pcp system.img :/Storage\ Card/system.img
This also puts the maps app in (just copy from one of my images) and the vogue keymap. Without the source for the ril you will also need to copy my RIL (libreference-ril.so).
Click to expand...
Click to collapse

[WIP] Configuring WiFi Interface
This has been able to initialize the interface, assign arbitrary IP addresses but can not go further at the moment.
Code:
# ifconfig tiwlan0 192.168.1.100
# ifconfig tiwlan0 up
error: SIOCSIFFLAGS (Cannot assign requested address)
# ifconfig tiwlan0
tiwlan0: ip 192.168.1.100 mask 255.255.255.0 flags (down broadcast multicast)
dmesg will show:
Code:
wlan: no version for "struct_module" found: kernel tainted.
TIWLAN: Driver loading
trout_wifi_power: 1
trout_wifi_reset: 0
trout_wifi_set_carddetect: 1
TIWLAN: Found SDIO control (vendor 0x104c, device 0x9066)
TIWLAN: Driver initialized (rc 0)
TIWLAN: Driver loaded
Android's built-in wireless settings seem to disable the interface beyond just interfering with it, therefore it's best to stay with terminal and using 'ash' will give you a shell with command history (up/down scroll).
markya23: Post:
Need to create a folder in you system image package called /etc/wifi and copy tiwlan.ini, wpa_supplicant.conf and fw1251r1c.bin.
Need to copy the wlan.ko to /lib/modules in the system image (create the dir if required).
Create the new system image and boot Android. Start the dev console and type:
Code:
cp /system/etc/wifi/wpa_supplicant.conf /data/misc/wifi/wpa_supplicant.conf
insmod /system/lib/modules/wlan.ko
wlan_loader -f /system/etc/wifi/Fw1251r1c.bin -e /proc/calibration -i /system/etc/wifi/tiwlan.ini
cd /data/local/tmp
wpa_supplicant -f -Dtiwlan0 -itiwlan0 -c/data/misc/wifi/wpa_supplicant.conf &
ifconfig tiwlan0 192.168.1.100 netmask 255.255.255.0
ifconfig tiwlan0 up
Click to expand...
Click to collapse

Compiling Android Kernel for Kaiser
dwaradzyn: Post:
Here are brief instructions on how to compile android kernel for Kaiser from git.linuxtogo.org repository. I assume that running OS is Linux and it has everything required to build x86 or ia64 kernel. Beside that latest git software should be installed. The shell is assumed to be bash.
1. Let's start with creating a directory for kernel in home directory:
Code:
mkdir ~/android-kernel
cd android-kernel
2. Next thing is to get the sources from repository. To make it happen (this could take a while, it downloads 280MB):
Code:
git clone git://git.linuxtogo.org/home/groups/mobile-linux/kernel.git
OUTPUT:
Code:
Initialized empty Git repository in /home/user/android-kernel/kernel/.git/
remote: Counting objects: 908251, done.
remote: Compressing objects: 100% (153970/153970), done.
remote: Total 908251 (delta 755115), reused 906063 (delta 753016)
Receiving objects: 100% (908251/908251), 281.86 MiB | 292 KiB/s, done.
Resolving deltas: 100% (755115/755115), done.
Checking out files: 100% (22584/22584), done.
3. The htc-msm branch is of our interest (again it could take a few seconds):
Click to expand...
Click to collapse
*** Update, poly_poly-man states we are working off of htc-vogue not htc-msm. I'm leaving the original code here but I would urge you to modify the next line as poly has suggested:
Code:
cd kernel
git checkout -b htc-msm origin/htc-msm
OUTPUT:
Code:
Branch htc-msm set up to track remote branch refs/remotes/origin/htc-msm.
Switched to a new branch "htc-msm"
4. Let's take care of arm toolchain. Download this file (64MB) into ~/android-kernel:
Code:
[url]http://www.codesourcery.com/gnu_toolchains/arm/portal/package2549/public/arm-none-linux-gnueabi/arm-2008q1-126-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2[/url]
Unpack it:
Code:
cd ~/android-kernel
tar xjf arm-2008q1-126-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
5. Compile the kernel
Prepare default .config for Kaiser:
Code:
cd ~/android-kernel/kernel
make htckaiser_defconfig ARCH=arm
OUTPUT:
Code:
........
lots of output
........
# configuration written to .config
#
And finally compile the kernel to get zImage (takes a minute or two):
Code:
export PATH=~/android-kernel/arm-2008q1/bin:$PATH
make zImage ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
OUTPUT:
Code:
........
lots of output
........
Kernel: arch/arm/boot/zImage is ready
Now copy ~/android-kernel/kernel/arch/arm/boot/zImage to your phone and play with it.
Some ending tips:
A. You can compile earlier versions of sources in repository. To do that click on one of "commit" links on page:
Code:
http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=summary
and read commit id (for example: f9d1bcea9342348623f5a57588044f76d8b649cd):
Code:
git reset --hard f9d1bcea9342348623f5a57588044f76d8b649cd
It will override any changes you made to files in ~/android-kernel/kernel.
B. Once you have downloaded git repository, you can swallow latest changes by issuing:
Code:
cd ~/android-kernel/kernel
git pull
C. If your machine has more than one cpus/cores you can speed up kernel compilation by adding -j <cores/cpus_number>, for example (dual core):
Code:
make -j 2 zImage ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
Click to expand...
Click to collapse

bad internet makes for double post. Please delete

wrong directions for kernel - we are working off of htc-vogue branch... not htc-msm...

can we make the internet work through the usb cable?

how does android know which device node is gps? it's not picking it up for kaiser...
if you enable gps in winmo (or enable it in smd0 - I believe the command is @startgps), smd7 is a nmea stream (acts as a serial GPS).... could a symlink possibly be the right solution to this?

Howto: Pull from git (new/update/resync)
This will download the latest from git:
dwaradzyn: Post:
Here are brief instructions on how to compile android kernel for Kaiser from git.linuxtogo.org repository. I assume that running OS is Linux and it has everything required to build x86 or ia64 kernel. Beside that latest git software should be installed. The shell is assumed to be bash.
1. Let's start with creating a directory for kernel in home directory:
Code:
mkdir ~/android-kernel
cd android-kernel
2. Next thing is to get the sources from repository. To make it happen (this could take a while, it downloads 280MB):
Code:
git clone git://git.linuxtogo.org/home/grou
ps/mobile-linux/kernel.git
OUTPUT:
Code:
Initialized empty Git repository in /home/user/android-kernel/kernel/.git/
remote: Counting objects: 908251, done.
remote: Compressing objects: 100% (153970/153970), done.
remote: Total 908251 (delta 755115), reused 906063 (delta 753016)
Receiving objects: 100% (908251/908251), 281.86 MiB | 292 KiB/s, done.
Resolving deltas: 100% (755115/755115), done.
Checking out files: 100% (22584/22584), done.
3. The htc-msm branch is of our interest (again it could take a few seconds):
Code:
cd kernel
git checkout -b htc-msm origin/htc-msm
OUTPUT:
Code:
Branch htc-msm set up to track remote branch refs/remotes/origin/htc-msm.
Switched to a new branch "htc-msm"
4. Let's take care of arm toolchain. Download this file (64MB) into ~/android-kernel:
Code:
http://www.codesourcery.com/gnu_toolchains/arm/portal/package2549/public/arm-none-linux-gnueabi/arm-2008q1-126-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
Unpack it:
Code:
cd ~/android-kernel
tar xjf arm-2008q1-126-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
5. Compile the kernel
Prepare default .config for Kaiser:
Code:
cd ~/android-kernel/kernel
make htckaiser_defconfig ARCH=arm
OUTPUT:
Code:
........
lots of output
........
# configuration written to .config
#
And finally compile the kernel to get zImage (takes a minute or two):
Code:
export PATH=~/android-kernel/arm-2008q1/bin:$PATH
make zImage ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
OUTPUT:
Code:
........
lots of output
........
Kernel: arch/arm/boot/zImage is ready
Now copy ~/android-kernel/kernel/arch/arm/boot/zImage to your phone and play with it.
Some ending tips:
A. You can compile earlier versions of sources in repository. To do that click on one of "commit" links on page:
http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=summary
and read commit id (for example: f9d1bcea9342348623f5a57588044f76d8b649cd):
Code:
git reset --hard f9d1bcea9342348623f5a57588044f76d8b649cd
It will override any changes you made to files in ~/android-kernel/kernel.
B. Once you have downloaded git repository, you can swallow latest changes by issuing:
Code:
cd ~/android-kernel/kernel
git pull
C. If your machine has more than one cpus/cores you can speed up kernel compilation by adding -j <cores/cpus_number>, for example (dual core):
Code:
make -j 2 zImage ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
Click to expand...
Click to collapse
poly_poly-man: Post:
This will pull from git which will update/resync a git pull:
Code:
mkdir foo
cd foo
git init
git pull git://git.linuxtogo.org/home/groups/mobile-linux/kernel.git htc-vogue
Click to expand...
Click to collapse

I'll follow-up with some nice, full instructions...
1. prerequisites: arm-none-linux-gnueabi toolchain (gentoo users can use crossdev - otherwise.... uhh... idk?), git, a host toolchain (gentoo users have this by default, most other distros have this under "development" in their package managment... if you have gcc, you're probably set).
2. mkdir kernel
cd kernel
git init
git pull git://git.linuxtogo.org/home/groups/mobile-linux/kernel.git htc-vogue
3. make vogue_defconfig
4. make
5. cp arch/arm/boot/bzImage /path/to/sdcard/
6. to update, run the git pull command by itself again, run make (may have to do the config line again if it's changed) and cp.

Thanks for the post poly. I don't know how that's different from what the post I referenced as I'm not +4 at this stuff.. I did what you posted with android kernel from git and got a 1.2mb zImage that crashed HaRET.. I'm guessing this is my bad. What could I have overlooked? Thanks

enatefox said:
Thanks for the post poly. I don't know how that's different from what the post I referenced as I'm not +4 at this stuff.. I did what you posted with android kernel from git and got a 1.2mb zImage that crashed HaRET.. I'm guessing this is my bad. What could I have overlooked? Thanks
Click to expand...
Click to collapse
where'd you get your toolchain?
does building a regular (host arch) kernel work?
Also - what's the proper way to build a system.img by hand? I'm looking to modify that quite a bit, but can't find a persistent source tree besides the main one, which is seriously crippled.

I thought you were one of the experts, lol. I've been left with no support on how dzo, et all are customizing kernels so I've been in read only mode on the 'other thread' looking elsewhere for support.
Just wanted to ask you first, what's with the Dream radio? I know you posted the mods censored it but what's with the sig now? It piqued my interest... as I'm using (shudder) winmo on the regular while Android is being worked on I was hoping it would be worth looking into if it doesn't brick my phone.
Answers to your questions:
As I said, my own zImage is no go. Check this link (not for our phone but the links at the bottom are pretty useful): http://wiki.xda-developers.com/index.php?pagename=BlackstoneLinux#Runningx20.Linuxx20.onx20.blackstone
I got the toolchain from the steps I (re)posted on this thread:
http://forum.xda-developers.com/showpost.php?p=2269384&postcount=184 so that gave me a 1.2mb zImage where everyone's been posting 1.4mb-- I know there's something not right. As far as building a system.img by hand? I've taken existing ones either from posted bundles or from Android src directly. Maybe I suck (real possibility) but cupcake and 1.0 have been pretty flaky for me (there are system.img's included in the source). You should know how to mount and edit them though (look at the first post on this thread). My experience is the git source is useless unless you've got a G1-- I don't know how to make it run on Tilts. If it does work, then the answer to your question about host arch compiling is no-- it has to be ARMv5 for our phones. That's where this line comes in:
make zImage ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
Click to expand...
Click to collapse
Seriously, I need help learning how to modify the kernel-- I've been a "google will have the answer for me" Linux bystander for a while and while I'm good at what I've done I'm not so good at this uncharted territory. I'm really looking for help to figure out how to compile modules (saurik and dzo never got back to me about that) and all I've gotten is "wait while I do it myself" which is cool they're working on it but we're obviously here to work on it too.
I've even been trying to get Debian installed (familiar territory for me) so I can at least get stuff working. You do know that Android is nothing but a Java VM layer for Linux and it will (could be) put on any self-respecting distro. Personally, I want Debian on my phone with an Android chroot as that would trump all.
Sorry to rant but you seem more about figuring this out like me and I don't know who else is really working on this besides the dev-gods who have no tutorials.

enatefox said:
I thought you were one of the experts, lol. I've been left with no support on how dzo, et all are customizing kernels so I've been in read only mode on the 'other thread' looking elsewhere for support.
Just wanted to ask you first, what's with the Dream radio? I know you posted the mods censored it but what's with the sig now? It piqued my interest... as I'm using (shudder) winmo on the regular while Android is being worked on I was hoping it would be worth looking into if it doesn't brick my phone.
Click to expand...
Click to collapse
It never actually worked... maybe. My phone was reporting the wrong version on a *different* radio (1.65.21.18, was saying 19) before, and trying to flash this changed the version to be correct. 0x300 radios will never flash, and this as a 0x301 *will* brick your phone. Then again... like 2 people reported epic success... In other words, no, it never really existed.
Answers to your questions:
As I said, my own zImage is no go. Check this link (not for our phone but the links at the bottom are pretty useful): http://wiki.xda-developers.com/index.php?pagename=BlackstoneLinux#Runningx20.Linuxx20.onx20.blackstone
I got the toolchain from the steps I (re)posted on this thread:
http://forum.xda-developers.com/showpost.php?p=2269384&postcount=184 so that gave me a 1.2mb zImage where everyone's been posting 1.4mb-- I know there's something not right. As far as building a system.img by hand? I've taken existing ones either from posted bundles or from Android src directly. Maybe I suck (real possibility) but cupcake and 1.0 have been pretty flaky for me (there are system.img's included in the source). You should know how to mount and edit them though (look at the first post on this thread). My experience is the git source is useless unless you've got a G1-- I don't know how to make it run on Tilts. If it does work, then the answer to your question about host arch compiling is no-- it has to be ARMv5 for our phones. That's where this line comes in:
make zImage ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
Click to expand...
Click to collapse
unnecessary - zImage is implied, and the other two are in the Makefile already.
Seriously, I need help learning how to modify the kernel-- I've been a "google will have the answer for me" Linux bystander for a while and while I'm good at what I've done I'm not so good at this uncharted territory. I'm really looking for help to figure out how to compile modules (saurik and dzo never got back to me about that) and all I've gotten is "wait while I do it myself" which is cool they're working on it but we're obviously here to work on it too.
Click to expand...
Click to collapse
we have 0 modules at the moment (but perhaps support - I forget). Just compile stuff in - modules are very bad.
I've even been trying to get Debian installed (familiar territory for me) so I can at least get stuff working. You do know that Android is nothing but a Java VM layer for Linux and it will (could be) put on any self-respecting distro. Personally, I want Debian on my phone with an Android chroot as that would trump all.
Click to expand...
Click to collapse
It's a nice idea, but remember where a lot of the current coding is taking place - the ril, which is part of android (the system.img, at least), and doesn't go across to other distros quite as well. I think running Dalvik alongside whatever you're running in Debian might be too much for this phone's epically slow processor (compared to msm7201a).
Sorry to rant but you seem more about figuring this out like me and I don't know who else is really working on this besides the dev-gods who have no tutorials.
Click to expand...
Click to collapse
my instructions should work - they are what I use, at least.

Someone should change the instructions to (in the Wiki they are correct):
make ARCH=arm vogue_defconfig
I compiled my kernel, booted in Ubuntu, but had no touchscreen at all, I am not sure if the vogue_defconfig file takes care of everything necessary, so now I am checking everything via menuconfig to see whether eveything is all right or not.
DOMy

Do not Use Ext3 on SD cards
enatefox said:
seidler2547: Post:
Click to expand...
Click to collapse
You should NOT be using ext3 on any sort of flash ram device. You will wear out the medium. Journaling is just a bad idea in this sort of situation.
http://www.handhelds.org/hypermail/familiar/273/27320.html
3) ext3 is "very bad" because of the way it does journaling. It does journal, which seems like a good idea, but it also automatically periodically writes a lot of things out to the same secors on disk. I don't have first hand experience with this, but I remember somebody familiar with ext3 writing about this. It's method of journaling is not particularly intended for any kind of wear leveling at all.
Click to expand...
Click to collapse
http://www.mail-archive.com/[email protected]/msg38988.html
There are three disadvantages with the journaled file system:
- lower performance at write time, since there is the extra work of the
journal
- increased chance of damaging the SD card due to extra use of the
journal causing wearing
- increased space usage (for the journal)
Click to expand...
Click to collapse
And this is the general consensus within most of linux on ext3 and wearing mediums. I'm not sure if Andriod's kernel can do ext4, but ext4 can run without a journal.
Yet another reason not to use ext3 is that is near impossible to undelete something, something you can do with ext2.
-edit-
It looks like Android can use Ext4
http://thatsbadass.com/android/tag/ext4/

haha! is a good job, i like it

can't run android on my kaiser
hi folks,
i have read many threads here and on androidonhtc.com, i have read also the install instructions, but it seems im too stupid to run it.
it fails on "can't find system.img". i wil not flash it, i will run it from sd-card.
so, please can anyone attached an actually zip file which i just unpack und run haret.exe to work android on my kaiser ?
thanks and best regards
lenzen

Better MTP access from linux

An MTP filesystem for linux that I believe works better than anything else currently out there.
http://research.jacquette.com/jmtpfs-exchanging-files-between-android-devices-and-linux/
I tried to make the filesystem implementation robust and as complete as possible within the limits of MTP. Everything except chown, chmod, symlinks, and updating the modification time without actually changing the file should work.
I've only tested it under Fedora 16, but the code is generic enough that it should work on any linux system (and probably Mac OS X as well) with libmtp 1.1.3, fuse, and libmagic.
Give it a try, and let me know if you find any bugs or other issues.
- J

Hi. This looks great. I tried mtpfs a couple of weeks ago and found it unreliable and buggy.
I'm trying to use this on mac. I installed gcc 4.7 since xcode command line tools ship with gcc 4.2 which doesn't support C++11.
However I still get this when I run make:
Code:
Making all in src
g++ -DPACKAGE_NAME=\"jmtpfs\" -DPACKAGE_TARNAME=\"jmtpfs\" -DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"jmtpfs\ 1.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"jmtpfs\" -DVERSION=\"1.0\" -DHAVE_LIBMAGIC=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_MAGIC_H=1 -I. -framework IOKit -I/usr/local/Cellar/libmtp/1.1.2/include -I/usr/local/Cellar/libusb-compat/0.1.3/include -D__DARWIN_64_BIT_INO_T=1 -D__FreeBSD__=10 -D_FILE_OFFSET_BITS=64 -I/usr/local/include/osxfuse/fuse -g -O2 -std=c++0x -MT jmtpfs-jmtpfs.o -MD -MP -MF .deps/jmtpfs-jmtpfs.Tpo -c -o jmtpfs-jmtpfs.o `test -f 'jmtpfs.cpp' || echo './'`jmtpfs.cpp
cc1plus: error: unrecognized command line option "-std=c++0x"
make[1]: *** [jmtpfs-jmtpfs.o] Error 1
make: *** [all-recursive] Error 1
Any ideas?
---------- Post added at 09:51 PM ---------- Previous post was at 09:34 PM ----------
Ok nevermind that. I had a symlink problem.
I still couldn't compile though:
Code:
jmtpfs.cpp:411:62: error: macro "fuse_main" passed 4 arguments, but takes just 3
jmtpfs.cpp: In function 'int main(int, char**)':
jmtpfs.cpp:411:15: error: 'fuse_main' was not declared in this scope

Hi,
I tested on gentoo x64, it worked very well.
Mounted my galaxy nexus as normal user, showed in nautilus as a drive. Copied some flac files to it, so far so good.
Thanks and please keep this going, since mtpfs didn't work for me either.

OSX build
With the patch below I got jmtpfs to build under Lion using libmtp, fuse4x, gcc46 (or gcc47), and file (libmagic) installed via macports. I'll include the patch in my next release.
There is still one weird issue though. If jmtpfs is run without the foreground (-f) option, you just get i/o errors when trying to access the device. It looks like something in the way fuse4x is backgrounding the process is messing up libmtp. But with -f it seems to work fine.
Index: src/jmtpfs.cpp
===================================================================
--- src/jmtpfs.cpp (revision 5445)
+++ src/jmtpfs.cpp (working copy)
@@ -22,11 +22,10 @@
#include "ConnectedMtpDevices.h"
#include "mtpFilesystemErrors.h"
#include "Mutex.h"
+#include "FuseHeader.h"
#include <MtpRoot.h>
#include <iostream>
-#include <fuse.h>
-#include <fuse_opt.h>
#include <cstddef>
#include <errno.h>
#include <sstream>
Index: src/MtpNode.h
===================================================================
--- src/MtpNode.h (revision 5445)
+++ src/MtpNode.h (working copy)
@@ -25,7 +25,7 @@
#include "MtpMetadataCache.h"
#include "MtpFilesystemPath.h"
#include "MtpDevice.h"
-#include <fuse.h>
+#include "FuseHeader.h"
#include <time.h>
#include <vector>
#include <string>
Index: src/FuseHeader.h
===================================================================
--- src/FuseHeader.h (revision 0)
+++ src/FuseHeader.h (revision 5447)
@@ -0,0 +1,30 @@
+/*
+ * FuseHeader.h
+ *
+ * Author: Jason Ferrara
+ *
+ * This software is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 3 as published by the Free Software Foundation.
+ *
+ * This software is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this library; if not, write to the
+ * Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+ * Boston, MA 02111-1301, USA.
+ * [email protected]
+ */
+
+#ifndef FUSEHEADER_H_
+#define FUSEHEADER_H_
+
+#define FUSE_USE_VERSION 26
+#include <fuse.h>
+#include <fuse_opt.h>
+
+
+#endif /* FUSEHEADER_H_ */
Index: src/MtpLocalFileCopy.cpp
===================================================================
--- src/MtpLocalFileCopy.cpp (revision 5445)
+++ src/MtpLocalFileCopy.cpp (working copy)
@@ -22,6 +22,7 @@
#include "mtpFilesystemErrors.h"
#include <sys/stat.h>
#include <iostream>
+#include <unistd.h>
MtpLocalFileCopy::MtpLocalFileCopy(MtpDevice& device, uint32_t id) :
m_device(device), m_remoteId(id), m_needWriteBack(false)

I released a version that builds and runs correctly under Mac OS X.
If you follow the link in my first post you'll now see a link to download the new version at the top of the blog post.

J F said:
I released a version that builds and runs correctly under Mac OS X.
If you follow the link in my first post you'll now see a link to download the new version at the top of the blog post.
Click to expand...
Click to collapse
Awesome! I didn't expect such a quick response. I got it working with gcc 4.7 and fuse4x installed using homebrew. I still can't copy/move anything due to permission errors. I tried running with sudo but it wouldn't mount at all. I also caught a couple of crashes: http://pastebin.com/JFgc0n5s http://pastebin.com/1d8FgvVX

Great work!
I'll try it on Archlinux 64 as soon as I get home

New release 0.4 with improved Mac OS X compatibility. Follow the link in my first post.
Apparently if you don't lie to the Finder and tell it MTP supports chmod and utime, the Finder throws a fit.
I'm also using the user that started jmtpfs for the uid and gid for the files. This fixes the permissions problems in OS X. And I report the combined free space of all the storage devices as the free space of the mount point. If I report 0 (which is the truth, since the mount point is read only and only contains directory entries for the storage devices, and its each subdirectory of the mount point which is read/write and has its own free space) then the finder assumes there is no free space in any directory under the mount point and refused to copy over files.

J F said:
New release 0.4 with improved Mac OS X compatibility. Follow the link in my first post.
Apparently if you don't lie to the Finder and tell it MTP supports chmod and utime, the Finder throws a fit.
I'm also using the user that started jmtpfs for the uid and gid for the files. This fixes the permissions problems in OS X. And I report the combined free space of all the storage devices as the free space of the mount point. If I report 0 (which is the truth, since the mount point is read only and only contains directory entries for the storage devices, and its each subdirectory of the mount point which is read/write and has its own free space) then the finder assumes there is no free space in any directory under the mount point and refused to copy over files.
Click to expand...
Click to collapse
0.4 compiled with the addition of "#include <unistd.h>" to jmtpfs.cpp and it worked! I was able to send/receive files! Thanks a lot for your efforts. At last we have a viable alternative to Android File Transfer.
Here is a little toturial for less techsavvy Mac owners:
1. Get Xcode from App Store if you haven't already. Open it and go to Preferences>Downloads and install "Command Line Tools".
2. Install homebrew
3. In terminal, run "brew doctor" to check for any issues. Then run "brew update && brew upgrade" to get the latest database.
4. Run this to get gcc 4.7 with C++ support:
Code:
brew install https://raw.github.com/Homebrew/homebrew-dupes/master/gcc.rb
5. Run "brew install fuse4x libmtp libmagic".
6. Run the following to install the fuse kernel extentions:
Code:
sudo cp -rfX /usr/local/Cellar/fuse4x-kext/0.9.0/Library/Extensions/fuse4x.kext /Library/Extensions && sudo chmod +s /Library/Extensions/fuse4x.kext/Support/load_fuse4x
7. Now you should have all the pre requisites installed. Download (fixed) jmtpfs from here and extract it.
8. cd to the extracted directory and run:
Code:
CXX=g++-4.7 CXXFLAGS="-D FUSE_USE_VERSION=25" ./configure --prefix=/usr/local/Cellar/jmptfs/0.4 && make && make install && brew link jmptfs
9. Run "mkdir ~/Android" to create a directory in your homefolder.
10. Finally, run "jmtpfs ~/Android". At this point, you should see a mountpoint called "fuse4x volume 0 jmtpfs" in your home directory, which you can treat as any external harddrive.

This is very interesting, but I can't seem to get it to work on Ubuntu Precise 12.04.
This is what I get on the "make" command:
[email protected]:~/Downloads/jmtpfs$ make
Making all in src
make[1]: Entering directory `/home/betto/Downloads/jmtpfs/src'
g++ -g -O2 -std=c++0x -lmagic -o jmtpfs jmtpfs-jmtpfs.o jmtpfs-MtpDevice.o jmtpfs-ConnectedMtpDevices.o jmtpfs-Mutex.o jmtpfs-MtpFilesystemPath.o jmtpfs-MtpMetadataCache.o jmtpfs-MtpNode.o jmtpfs-MtpRoot.o jmtpfs-MtpLibLock.o jmtpfs-MtpStorage.o jmtpfs-MtpFolder.o jmtpfs-MtpFile.o jmtpfs-TemporaryFile.o jmtpfs-MtpLocalFileCopy.o -L/usr/local/lib -lmtp -lusb -pthread -lfuse -lrt -ldl
jmtpfs-MtpDevice.o: In function `MtpDevice':
/home/betto/Downloads/jmtpfs/src/MtpDevice.cpp:69: undefined reference to `magic_open'
/home/betto/Downloads/jmtpfs/src/MtpDevice.cpp:72: undefined reference to `magic_load'
/home/betto/Downloads/jmtpfs/src/MtpDevice.cpp:73: undefined reference to `magic_error'
jmtpfs-MtpDevice.o: In function `MtpDevice::SendFile(LIBMTP_file_struct*, int)':
/home/betto/Downloads/jmtpfs/src/MtpDevice.cpp:242: undefined reference to `magic_buffer'
collect2: ld returned 1 exit status
make[1]: *** [jmtpfs] Error 1
make[1]: Leaving directory `/home/betto/Downloads/jmtpfs/src'
make: *** [all-recursive] Error 1
Click to expand...
Click to collapse
I've installed the libmagic-dev package(or something like that. What are those undefined references? Am I missing some packages??

Hey, i have now w7, pls support for me.
Sent from my Galaxy Nexus using Tapatalk 2

Rimher said:
This is very interesting, but I can't seem to get it to work on Ubuntu Precise 12.04.
This is what I get on the "make" command:
I've installed the libmagic-dev package(or something like that. What are those undefined references? Am I missing some packages??
Click to expand...
Click to collapse
It looks like maybe you ran configure, installed libmagic-dev, and then ran make without rerunning configure.
Do "make distclean;./configure" and make sure configure doesn't report any errors. Then try make again.
If things go right at the final link command there should be a -lmagic at the end of the command line. The -lmagic you see near the beginning of the command line is because of a mistake I made in configure.ac (the LDFLAGS="$LDFLAGS -lmagic" line shouldn't be there), but it has no effect because it comes before the object files that need it.

J F said:
It looks like maybe you ran configure, installed libmagic-dev, and then ran make without rerunning configure.
Do "make distclean;./configure" and make sure configure doesn't report any errors. Then try make again.
If things go right at the final link command there should be a -lmagic at the end of the command line. The -lmagic you see near the beginning of the command line is because of a mistake I made in configure.ac (the LDFLAGS="$LDFLAGS -lmagic" line shouldn't be there), but it has no effect because it comes before the object files that need it.
Click to expand...
Click to collapse
Seems to work correctly now! Thanks a lot =)
The weird thing is that some folders that are available into my Android are not visible through the file system. How's that possible?

Ubuntu 12
Hey OP,
When I run the ./configure command I get this output
:/home/jd/Downloads/jmtpfs-0.3# ./configure
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for g++... no
checking for c++... no
checking for gpp... no
checking for aCC... no
checking for CC... no
checking for cxx... no
checking for cc++... no
checking for cl.exe... no
checking for FCC... no
checking for KCC... no
checking for RCC... no
checking for xlC_r... no
checking for xlC... no
checking whether the C++ compiler works... no
configure: error: in `/home/jd/Downloads/jmtpfs-0.3':
configure: error: C++ compiler cannot create executables
See `config.log' for more details
After this when I try make and make install it says
make: *** No targets specified and no makefile found. Stop.
I also tried the latest jmtpfs package too with the same results, what am I doing wrong?
Is this because of the compiler errors above? Any help would really be great. I use Airdroid normally but I would love to try your method. Thank you.

You have to install g++
sudo apt-get install g++

I installed libmagic-dev, autoconf and automake. Before running ./configure, I ran autoreconf, and that also seemed to fix it.
You can do most operations much quicker than with mtpfs, but it's still silly-slow to do something like 'tree'. MTP really sucks in some use-cases. DON'T think of it as a filesystem!

jangutter said:
I installed libmagic-dev, autoconf and automake. Before running ./configure, I ran autoreconf, and that also seemed to fix it.
You can do most operations much quicker than with mtpfs, but it's still silly-slow to do something like 'tree'. MTP really sucks in some use-cases. DON'T think of it as a filesystem!
Click to expand...
Click to collapse
I agree. It's way slower than UMS. Granted, on mac, google's own Android File Transfer app works way faster than jmtpfs or mtpfs (it's very buggy and unreliable though)

Hey Rimher,
Thanks for that I installed g++
No when I try to run through the ./configure command I get this
checking for FUSE... no
configure: error: Package requirements (fuse >= 2.6) were not met:
No package 'fuse' found
Any ideas?

jd1001 said:
Hey Rimher,
Thanks for that I installed g++
No when I try to run through the ./configure command I get this
checking for FUSE... no
configure: error: Package requirements (fuse >= 2.6) were not met:
No package 'fuse' found
Any ideas?
Click to expand...
Click to collapse
it's pretty self explanatory. You need to install fuse, as mentioned in OP.

jd1001 said:
Hey Rimher,
Thanks for that I installed g++
No when I try to run through the ./configure command I get this
checking for FUSE... no
configure: error: Package requirements (fuse >= 2.6) were not met:
No package 'fuse' found
Any ideas?
Click to expand...
Click to collapse
sudo apt-get install libfuse-dev
sudo apt-get install libmagic-dev
you have to install a bunch of libraries, not sure if those two are enough, try it

Requesting help with "make-standalone-toolchain.sh" for AFTV2

Yesterday, I cross-compiled DropBear for the 2nd Gen Fire TV, but I am receiving a linkage error that points to it being compiled with an incorrect toolchain.
I downloaded and extracted the "android-ndk-r10e-linux-x86_64.bin" and used the following command to make the standalone toolchain:
Code:
/home/william/android-ndk/build/tools/make-standalone-toolchain.sh --ndk-dir=/home/william/android-ndk --platform=android-21 --toolchain=arm-linux-androideabi-4.9 --system=linux-x86_64 --install-dir=/home/william/aftv2-toolchain
What are the correct platform and toolchain for the AFTV2 on 5.0.4? I tried to look this up, but I was unable to find it posted in any of the expected places. If I don't hear back, I suppose I'll give it a try with aarch64-linux-android-4.9, because the error I'm receiving when I try to connect to server complains about the bitness of "libc.so" (is 32-bit instead of 64-bit), but I can't even seem to find confirmation that the AFTV2 uses a 64-bit arm processor.
Thanks,
William

fecaleagle said:
Yesterday, I cross-compiled DropBear for the 2nd Gen Fire TV, but I am receiving a linkage error that points to it being compiled with an incorrect toolchain.
I downloaded and extracted the "android-ndk-r10e-linux-x86_64.bin" and used the following command to make the standalone toolchain:
Code:
/home/william/android-ndk/build/tools/make-standalone-toolchain.sh --ndk-dir=/home/william/android-ndk --platform=android-21 --toolchain=arm-linux-androideabi-4.9 --system=linux-x86_64 --install-dir=/home/william/aftv2-toolchain
What are the correct platform and toolchain for the AFTV2 on 5.0.4? I tried to look this up, but I was unable to find it posted in any of the expected places. If I don't hear back, I suppose I'll give it a try with aarch64-linux-android-4.9, because the error I'm receiving when I try to connect to server complains about the bitness of "libc.so" (is 32-bit instead of 64-bit), but I can't even seem to find confirmation that the AFTV2 uses a 64-bit arm processor.
Thanks,
William
Click to expand...
Click to collapse
Yes, you need aarch64. I've used both the NDK and the aarch64 compiler straight from AOSP. Both work.

rbox said:
Yes, you need aarch64. I've used both the NDK and the aarch64 compiler straight from AOSP. Both work.
Click to expand...
Click to collapse
Thanks, I actually just rebuilt the toolchain with aarch64 and re-compiled. I'll follow-up, because I'm assuming that was the only thing preventing the server from functioning properly. Thanks for all your assistance.

fecaleagle said:
Thanks, I actually just rebuilt the toolchain with aarch64 and re-compiled. I'll follow-up, because I'm assuming that was the only thing preventing the server from functioning properly. Thanks for all your assistance.
Click to expand...
Click to collapse
Well, I'm obviously still doing something wrong. The file command on my build-system reports:
Code:
./dropbearmulti: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, stripped
, which looks correct.
But clients are still receiving the following error when I try to connect to the server:
Code:
CANNOT LINK EXECUTABLE DEPENDENCIES: "libc.so" is 32-bit instead of 64-bit
I'll keep digging, but basically, I am building the toolchain like so:
Code:
/home/william/android-ndk/build/tools/make-standalone-toolchain.sh --ndk-dir=/home/william/android-ndk --platform=android-21 --toolchain=aarch64-linux-android-4.9 --system=linux-x86_64 --install-dir=/home/william/aftv2-toolchain
Then running configure:
Code:
./configure --build=x86_64-unknown-linux-gnu --host=aarch64-linux-android --prefix=/home/william/aftv2-toolchain --disable-zlib --disable-largefile --disable-loginfunc --disable-shadow --disable-utmp --disable-utmpx --disable-wtmp --disable-wtmpx --disable-pututline --disable-pututxline --disable-lastlog
Then, I am setting CC and PATH to the following:
Code:
CC=aarch64-none-linux-gnueabi-gcc
PATH=/home/william/aftv2-toolchain/bin:$PATH
Then, I am building as such:
Code:
STATIC=1 MULTI=1 SCPPROGRESS=0 PROGRAMS="dropbear dropbearkey scp dbclient" make strip
No complaints during the build or from the file command, but the issue persists. Surely I am missing something.

Interesting. So when I poke around my toolchain, all of the copies of libc.so are 64-bit, according to the linux file command.
However, just to see if it would tell me anything, I compiled the binary dynamically-linked rather than statically linked and used the ndk-depends tool, and it reports the following:
Code:
Building dependency graph...
dropbearmulti depends on: libc.so libdl.so
Android system library: libc.so
Android system library: libdl.so
Building sorted list of binaries:
dropbearmulti -> ./dropbearmulti
libdl.so -> $ /system/lib/libdl.so
libc.so -> $ /system/lib/libc.so
This obviously indicates that when I build dynamic, it is attempting to link with the 32-bit libraries and not the 64-bit libraries. How can I correct this so that when I do any build, the linkages are correct?

fecaleagle said:
Interesting. So when I poke around my toolchain, all of the copies of libc.so are 64-bit, according to the linux file command.
However, just to see if it would tell me anything, I compiled the binary dynamically-linked rather than statically linked and used the ndk-depends tool, and it reports the following:
Code:
Building dependency graph...
dropbearmulti depends on: libc.so libdl.so
Android system library: libc.so
Android system library: libdl.so
Building sorted list of binaries:
dropbearmulti -> ./dropbearmulti
libdl.so -> $ /system/lib/libdl.so
libc.so -> $ /system/lib/libc.so
This obviously indicates that when I build dynamic, it is attempting to link with the 32-bit libraries and not the 64-bit libraries. How can I correct this so that when I do any build, the linkages are correct?
Click to expand...
Click to collapse
I was compiling kexec dynamically by setting CC and it was working. And I've compiled other things with Android.mk files using the NDK and compiling them static and it worked. Why are you compiling dropbear static to begin with? You say CLIENTS are receiving that message. It almost sounds like dropbear is trying to fork a 32bit shell for them. Since you are running dropbear as the server fine, itself is compiled correctly...

rbox said:
I was compiling kexec dynamically by setting CC and it was working. And I've compiled other things with Android.mk files using the NDK and compiling them static and it worked. Why are you compiling dropbear static to begin with? You say CLIENTS are receiving that message. It almost sounds like dropbear is trying to fork a 32bit shell for them. Since you are running dropbear as the server fine, itself is compiled correctly...
Click to expand...
Click to collapse
I'm compiling static because I'm following the guide posted here:
http://forum.xda-developers.com/nexus-7-2013/general/guide-compiling-dropbear-2015-67-t3142412
Running the dynamically-linked version on the fire tv reports:
Code:
error: only position independent executables (PIE) are supported.
I suppose I should be reaching out to @jocala at this point, since I'd guess he's managed to compile it successfully for the 2nd gen fire tv.

fecaleagle said:
I'm compiling static because I'm following the guide posted here:
http://forum.xda-developers.com/nexus-7-2013/general/guide-compiling-dropbear-2015-67-t3142412
Running the dynamically-linked version on the fire tv reports:
Code:
error: only position independent executables (PIE) are supported.
Click to expand...
Click to collapse
http://stackoverflow.com/questions/...id-l-error-only-position-independent-executab
You need to enable PIE in CFLAGS and LDFLAGS:
CFLAGS = -fPIE
LDFLAGS = -fPIE -pie

fecaleagle said:
I suppose I should be reaching out to @jocala at this point, since I'd guess he's managed to compile it successfully for the 2nd gen fire tv.
Click to expand...
Click to collapse
I'm working on the adbFire update for AFTV2 root; ssh is on the list, but I'm not there yet.

rbox said:
http://stackoverflow.com/questions/...id-l-error-only-position-independent-executab
You need to enable PIE in CFLAGS and LDFLAGS:
CFLAGS = -fPIE
LDFLAGS = -fPIE -pie
Click to expand...
Click to collapse
Doing this allows it startup correctly dynamically linked, but clients still fail to connect. Debian reports the most useful information:
Code:
dispatch_protocol_error: type 51 seq 6
CANNOT LINK EXECUTABLE DEPENDENCIES: "libc.so" is 32-bit instead of 64-bit
As usual, dropbear reports:
Code:
[6329] Jan 04 13:48:35 Child connection from 192.168.1.210:53425
void endusershell()(3) is not implemented on Android
void endusershell()(3) is not implemented on Android
[6329] Jan 04 13:48:42 password auth succeeded for 'root' from 192.168.1.210:53425
[6329] Jan 04 13:48:43 Exit (root): Disconnect received
To me, it appears that the server is throwing up the error to the client, but I still suspected that I am linking the 32-bit version of libc.so when I build dropbear, and I am still at a loss for how to correct that.
Thanks for all of your help. I'll get there eventually.

fecaleagle said:
Doing this allows it startup correctly dynamically linked, but clients still fail to connect. Debian reports the most useful information:
Code:
dispatch_protocol_error: type 51 seq 6
CANNOT LINK EXECUTABLE DEPENDENCIES: "libc.so" is 32-bit instead of 64-bit
As usual, dropbear reports:
Code:
[6329] Jan 04 13:48:35 Child connection from 192.168.1.210:53425
void endusershell()(3) is not implemented on Android
void endusershell()(3) is not implemented on Android
[6329] Jan 04 13:48:42 password auth succeeded for 'root' from 192.168.1.210:53425
[6329] Jan 04 13:48:43 Exit (root): Disconnect received
To me, it appears that the server is throwing up the error to the client, but I still suspected that I am linking the 32-bit version of libc.so when I build dropbear, and I am still at a loss for how to correct that.
Thanks for all of your help. I'll get there eventually.
Click to expand...
Click to collapse
Dropbear itself is 64-bit, because you are actually running it fine. If you could turn up the logging on dropbear, maybe you can get it to tell you what it's doing between password succeeded and disconnect received. Or you could just add a ton of logging to the code. My guess is it's forked the connection and trying to start a secondary program, and that program isn't 64bit. My guess would be the shell, but it should just be using the system shell, so unsure.

jocala said:
I'm working on the adbFire update for AFTV2 root; ssh is on the list, but I'm not there yet.
Click to expand...
Click to collapse
Thanks for your work on adbFire. I'll report back if I'm ever able to get this resolved.

rbox said:
Dropbear itself is 64-bit, because you are actually running it fine. If you could turn up the logging on dropbear, maybe you can get it to tell you what it's doing between password succeeded and disconnect received. Or you could just add a ton of logging to the code. My guess is it's forked the connection and trying to start a secondary program, and that program isn't 64bit. My guess would be the shell, but it should just be using the system shell, so unsure.
Click to expand...
Click to collapse
This suggestion is making more and more sense. I'll take a look at the source and start thinking about my own patchset for the latest source version. I'm annoyed that the verbose flag is not included in the source version of dropbear that the patch was created for, so I think I will end up going that route eventually. I'll take your advice and focus adding debug messages when dropbear initializes the shell, since the authentication goes of without a hitch and it's at that point that the process breaks down. I really appreciate all of your suggestions!

@rbox,
This is rather helpful, and the post from July 31st, 2015 all but confirms your suspicion about forking the shell and points me in the right direction:
http://www.kevinboone.net/kbox3_diary.html
I will start by modifying the patches to use: /bin/sh rather than /system/bin/sh when launching the shell and see if that resolves my issue, then get started on the long slog.

The blog post above seems to have shed some light on the issue. Updating the patches to refer to /bin/sh rather than /system/bin/sh seems to have resolved the "CANNOT LINK EXECUTABLE DEPENDENCIES: "libc.so" is 32-bit instead of 64-bit" error. As @rbox suspected, dropbear seems to be creating the appropriate shell upon connect now on a 64-bit system (aftv2).
Unfortunately, I'm still receiving the "dispatch_protocol_error":
Code:
dispatch_protocol_error: type 51 seq 6
[5761] Jan 04 19:47:46 Exit (root): Child failed
Connection to 192.168.1.213 closed.
Any thoughts on this one @jocala? Googling dispatch_protocol_error type 51 returns zilch.

Linageos 17.1 Build faild Python Error - Use prebuilts python for ninja?

Hello,
my Linux OS have a strange Python Version or setting, so the Build failed with:
Code:
FAILED: //art/build/apex:art-check-release-apex-gen generate art-check-release-apex-gen.dummy
Outputs: out/soong/.intermediates/art/build/apex/art-check-release-apex-gen/gen/art-check-release-apex-gen.dummy
Error: exited with code: 1
Command: rm -rf out/soong/.intermediates/art/build/apex/art-check-release-apex-gen/gen && out/soong/host/linux-x86/bin/sbox --sandbox-path out/soong/.temp --output-root out/soong/.intermediates/art/build/apex/art-check-release-apex-gen/gen -c 'out/soong/host/linux-x86/bin/art-apex-tester --debugfs out/soong/host/linux-x86/bin/debugfs --tmpdir __SBOX_OUT_DIR__ out/soong/.intermediates/art/build/apex/com.android.runtime.release/android_common_com.android.runtime.release/com.android.runtime.release.apex && touch __SBOX_OUT_FILES__' __SBOX_OUT_DIR__/art-check-release-apex-gen.dummy
Output:
.path_interposer: no python-exec wrapped executable found in /usr/lib/python-exec.
sbox command (out/soong/host/linux-x86/bin/art-apex-tester --debugfs out/soong/host/linux-x86/bin/debugfs --tmpdir out/soong/.temp/sbox333717900 out/soong/.intermediates/art/build/apex/com.android.runtime.release/android_common_com.android.runtime.release/com.android.runtime.release.apex && touch out/soong/.temp/sbox333717900/art-check-release-apex-gen.dummy) failed with err "exit status 127"
Its on the Finish-Line of the building Process. ( [ 99% 11533/11603] )
I try to use
Code:
virtualenv --version
virtualenv 20.0.18 from /usr/lib64/python3.6/site-packages/virtualenv/__init__.py
With the Python in:
prebuilts/python/linux-x86/2.7.5/bin/python2.7
Some hints for me?
Building Lineage 16, works fine, sure the build process is different.
Can i just use the Command from lineageos16, which create the zip file if all parts are finnished?

I've been having the same issue on Gentoo since LineageOS 17.1.
I have Python 2.7, 3.6, 3.7 and 3.8 installed.
If nobody has a solution and you find it, please comment with the solution, I'm sure we are not the only two people affected by this issue.

Thank you Yurienu,
easy would be to juse another live-Distro with a build Tree on a mounted file System.
However i think the error is in the tools of google, like apex or how the script use and call this function. Not sure if i like to debug this.
I think it because the path.interposer try to present a list of tools to art-check-release-apex-gen, from where the program to do its job. And a wrapper might failed and put its path there. When art-check do its job, try it and failed, because its not design to handle the error message (and so because of that bug).
For this speaks the error message:
But take a look on my error code: "Error: exited with code: 1" from the command: //art/build/apex:art-check-release-apex-gen generate art-check-release-apex-gen.dummy".
I think there is the bug. Whatever art-check-release-apex-gen do, it fail here. Then check, see the wrapper and say that there is no python.
I try to use python 2.7.18 (Gentoos Python 2.7), and it did not work.
I try to use virtuelenvwrapper*** and it failed but the error was like: "no Module with python 2.7.5, named virtuelenvwrapper". However i got this misconfigured. But it sound compelling. Because a Module for python 2.7.18, is maybe not byte compatible with python 2.7.5.
Think i try to use another distro for building this.
Bye the way, there is a Google Summer of code 2020 project, that's sound very interesting. So there is hope for a proper lineage and gentoo support in the future.
However, if i find a solution i share it here!
I stay a little bit longer with lineageos 16.0, because self build security updates are more important for me, as Android 10 is.
*** I just linked the prebuild binary an path as environment to /usr/local/bin/

Hello everyone,
I too met the same issue, the exact same content in the "out/error.log" than the first post; I am sharing the research I got around this issue, because I don't have the same conclusion.
First I tried to discard the error about ".path_interposer", and seek the error from the "sbox" software output.
I dig around "out/soong/host/linux-x86/bin/art-apex-tester", and got those information:
Code:
% file out/soong/host/linux-x86/bin/art-apex-tester
out/soong/host/linux-x86/bin/art-apex-tester: Zip archive data, made by v?[0x314], extract using at least v2.0, last modified Thu Nov
4 03:39:44 1999, uncompressed size 2619, method=store
% unzip -l out/soong/host/linux-x86/bin/art-apex-tester
Archive: out/soong/host/linux-x86/bin/art-apex-tester
Length Date Time Name
--------- ---------- ----- ----
2619 01-01-2008 00:00 __main__.py
28376 01-01-2008 00:00 art_apex_test.py
--------- -------
30995 2 files
It looks like it’s a Zip archive which can execute the Python script "__main__.py".
The "__main__.py" is a wrapper, which its goal is to call the other python file, "art_apex_test.py" with the correct parameters.
By reading its content, I noticed it searchs Python 3 executable, and calls the following command:
Code:
/usr/bin/python3 -S relative_path/to/art_apex_test.py […]
When I execute this command under a temporary directory, I have this output (still under the current directory as parent of the "out" directory):
Code:
python3 -S /tmp/art_apex_test.py --debugfs out/soong/host/linux-x86/bin/debugfs --tmpdir out/soong/.temp out/soong/.intermediates/art/build/apex/com.android.runtime.release/android_common_com.android.runtime.release/com.android.runtime.release.apex
--bitness=auto, trying to autodetect. This may be incorrect!
Detected multilib
I have the same ouput by either executing the Zip archive with the same arguments.
Unfortunately, the "tmpdir" "out/soong/.temp" remains empty.
What about "path_interposer" then? No idea, I found no match in either the two Python scripts.
And then I don't think it's related to the Python 2.7 embedded program.
Oddly enough, the full command with sbox has the same output, but not error. I start to think this error is in a build system file.
Hope to have help (a little).
Best regards,

thican said:
I too met the same issue, the exact same content in the "out/error.log" than the first post; I am sharing the research I got around this issue, because I don't have the same conclusion.
Click to expand...
Click to collapse
I've been having this issue a while also, turns out it's fixable (not that Gentoo won't override it every time you upgrade python) I linked /usr/bin/python3.7 to /usr/bin/python3 instead of /usr/bin/python-exec2c.
Now the apex tester thinger works fine, I'm guessing that inside the sandbox can't find /usr/lib/python-exec.
Hope this works for you guys as well.

SOLVED LineageOS 17.1: .path_interposer: no python-exec wrapped executable found
superfes said:
I've been having this issue a while also, turns out it's fixable (not that Gentoo won't override it every time you upgrade python) I linked /usr/bin/python3.7 to /usr/bin/python3 instead of /usr/bin/python-exec2c.
Now the apex tester thinger works fine, I'm guessing that inside the sandbox can't find /usr/lib/python-exec.
Hope this works for you guys as well.
Click to expand...
Click to collapse
OH! That's the trick, it finally works!
For an easy fix without needing to touch files hold by system, I just create a bin directory at the root of the home directory of the user, put its path inside the PATH environment variable, at its beginning (PATH="${HOME}/bin:${PATH}"), and then creating the symbolic links.
It was so easy it's so frustrating, having this issue for months, even during 16.0 branch IIRC.
Just to be sure, I create those links (I picked Python 3.8 for my example):
Code:
ln -s /usr/bin/python3.8 ~/bin/python3
ln -s python3 ~/bin/python
Now let's try this new build. Thank you very much for you help! :good:
PS: in your message, the links are backward, it's currently python3 which is linked to python-exec2c, and /usr/bin/python3.7{,m} are there own executable. I advice you to avoid editing your system files

@superfes and @thican you guys deserve three internets!
I was struggling with this error as well (not for 16.0, only for 17.1 -- Gentoo here as well). This fixed it!
So again: Thanks!

thican said:
OH! That's the trick, it finally works!
For an easy fix without needing to touch files hold by system, I just create a bin directory at the root of the home directory of the user, put its path inside the PATH environment variable, at its beginning (PATH="${HOME}/bin:${PATH}"), and then creating the symbolic links.
It was so easy it's so frustrating, having this issue for months, even during 16.0 branch IIRC.
Just to be sure, I create those links (I picked Python 3.8 for my example):
Code:
ln -s /usr/bin/python3.8 ~/bin/python3
ln -s python3 ~/bin/python
Click to expand...
Click to collapse
This is the way that worked fully for me. Thanks all! Running Gentoo latest hardened with python 3.7 as default.

Thank you superfes and thican!
I had not the time do investigate since covid19 blow up my personal workingdesk. Nice to go on with Lineage 17.1!

Tnx! Worked for me too!

With dev-lang/python-exec-2.4.6-r2
/usr/bin/python3 is a symlink to python-exec2c which cause this error.
Workaround is use vanilla python version of python-exec2c
before brunch command you can use like
Code:
[[ -d ~/bin/ ]] || mkdir ~/bin
[[ -e ~/bin/python3 ]] || ln -s /usr/lib/python-exec/python-exec2 ~/bin/python3
export PATH=~/bin:$PATH
Hence, in future shebang support of python or python3 will removed also.
762406 – [TRACKER] Packages that have failures with dev-lang/python-exec[-native-symlinks]
bugs.gentoo.org

How To Guide Getting Freedreno Turnip (Mesa Vulkan Driver) on a Poco F3

Bellow follows a compilation and magisk packaging guide for the Turnip driver, if you just want an optimized build for magisk and don't care to compile get it from https://cdn.discordapp.com/attachments/930104429309460533/942122346960027698/mesa_lto.zip This build is built as release with LTO enabled. Just make sure that on /vendor/lib64/hw you have a file called vulkan.adreno.so ,if the name is different then you have to patch it with patchelf and rename it as stated bellow.
In this guide I'm going to teach you how to compile the mesa's Turnip vulkan driver of the Freedreno project for any smartphone with a Snapdragon SOC on a PC. If you want to compile on your phone (guest) check the second post.
You are going to need Linux in order to follow this guide and recommended is a distro with latest packages, for example Arch Linux (including derivatives like EndeavourOS, Manjaro, Garuda, Calamarch, etc.), while this may also work on WSL/WSL2 I haven't tested it and you are on your own for this.
You are also going to need a mobile phone that’s rooted with the latest magisk and magisk manager.
Before starting you need to satisfy some dependencies:
git to clone the mesa repository
patchelf to patch the binary with the name your phone expects
meson which is mesa’s build system
To get all these on Arch you can use the below command:
Code:
sudo pacman -Syu git patchelf meson
You also need NDK since you are compiling native code for Android. There are two ways to get this:
From the SDK Manager on Android Studio Beta or Canary (Stable Android Studio doesn’t have the latest NDK) by going to More Actions>SDK Manager>SDK Tools on the welcome screen or Tools>SDK Manager>SDK Tools if a project is open and download the latest one. If you already have it and it shows a – sign you need to click it again to become a tick since you already have it but it is an older version. After you get the NDK you can close Android Studio.
Manually from https://developer.android.com/ndk/downloads. Make sure to get the latest NDK for Linux at the bottom of the page.
Now you need to find the absolute path of the NDK, which will be referred to as NDKDIR from now on.
If you got the NDK from Android Studio, then there should be a folder called Android on your home folder with a folder called Sdk inside it, get in. Click the ndk folder then get inside the folder of the biggest version (25.0.8141415 at the time of writing this) and copy the path. In my case the path is
Code:
/home/username/Android/Sdk/ndk/25.0.8141415
If you downloaded the NDK manually then you need to extract it somewhere. For example I created a folder called Turnip in the root of my home folder and extracted it there. The latest NDK is android-ndk-r25-beta1-linux.zip at the time of writing this so my NDKDIR is
Code:
/home/username/Turnip/android-ndk-r25-beta1
Inside your NDKDIR create a folder called pkgconfig and another folder for dependencies which I will call deps.
Next you must create a meson cross file. To do this create a file called android-aarch64 at ~/.local/share/meson/cross/ (~ means your home folder). If you don’t see any folders starting with a dot you need to press ctrl+h, if the path doesn’t exist create it.
On that file paste the following and using your text editor automatically find and replace all instances of NDKDIR with your NDKDIR from above.
Code:
[binaries]
ar = 'NDKDIR/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-ar'
c = ['ccache', 'NDKDIR/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android31-clang']
cpp = ['ccache', 'NDKDIR/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android31-clang++', '-fno-exceptions', '-fno-unwind-tables', '-fno-asynchronous-unwind-tables', '-static-libstdc++']
c_ld = 'lld'
cpp_ld = 'lld'
strip = 'NDKDIR/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android-strip'
# Android doesn't come with a pkg-config, but we need one for meson to be happy not
# finding all the optional deps it looks for. Use system pkg-config pointing at a
# directory we get to populate with any .pc files we want to add for Android
pkgconfig = ['env', 'PKG_CONFIG_LIBDIR=NDKDIR/pkgconfig', '/usr/bin/pkg-config']
[host_machine]
system = 'linux'
cpu_family = 'aarch64'
cpu = 'armv8'
endian = 'little'
Now you need to download a binary of libdrm compiled for Arm64. It’s available at https://archlinuxarm.org/packages/aarch64/libdrm, just click the Download button on the right. Open the .tar.xz archive using your archive manager. Inside there’s a folder called usr that contains three other folders. You must extract the include and lib folders on the deps folder you created. After you do so, close your archive manager. The lib folder has a folder called pkgconfig, from that folder copy the file libdrm.pc to the pkgconfig folder that you created before deps.
Edit the libdrm pc file after you transfer it and change its first line so that it points to deps. For example in my case it's
Code:
prefix=/home/username/Turnip/android-ndk-r25-beta1/deps
And last, you need a clone of the MESA repository. To clone the repo you need to use the terminal so open a terminal at the folder you want the mesa folder to be downloaded onto or cd there otherwise the mesa folder will be placed at the root of your home folder. To clone you use the bellow command:
Code:
git clone https://gitlab.freedesktop.org/mesa/mesa.git
and cd inside by doing
Code:
cd mesa
Then generate the build files using
Code:
meson build-android-aarch64 --cross-file android-aarch64 -Dbuildtype=release -Dplatforms=android -Dplatform-sdk-version=31 -Dandroid-stub=true -Dgallium-drivers= -Dvulkan-drivers=freedreno -Dfreedreno-kgsl=true -Db_lto=true
And compile with
Code:
ninja -C build-android-aarch64
When this is done you can find our compiled driver binary at build-android-aarch64/src/freedreno/vulkan/ inside the mesa folder named libvulkan_freedreno.so.
Now you must find the name of the binary that our phone has. The easiest way to do this is to open a terminal emulator on your phone like termux or do adb shell and run
Code:
ls /system/vendor/lib64/hw|grep vulkan
In my case the driver is called vulkan.adreno.so.
Now open a terminal on the folder where libvulkan_freedreno.so and use patchelf to patch it with the name of the driver on your phone, for example in my case I’d do
Code:
patchelf --set-soname vulkan.adreno.so libvulkan_freedreno.so
and then rename libvulkan_freedreno.so to the name the driver on your phone has.
You now need to create a magisk package containing Turnip. Simply download my existing package from https://cdn.discordapp.com/attachments/930104429309460533/942122346960027698/mesa_lto.zip and replace /system/vendor/lib64/hw/vulkan.adreno.so with the Turnip binary you compiled, patched and renamed. Now you can flash it on Magisk and reboot your phone. If you have other Magisk packages that are Vulkan drivers please disable them before rebooting. If you want compile again at a later time cd inside the mesa repo you had cloned and do a git pull before running meson and compiling. You may also have to delete the build-android-aarch64 folder.

Some of you wanted to compile Turnip on Termux so here's a tutorial.
You are going to need an arm64 phone and Termux from https://f-droid.org/en/packages/com.termux/. If you have Termux from PlayStore delete it since it no longer works and it uses a different signature so it can't be updated either.
Once you install Termux go to your phone's app settings and give it storage permissions manually then launch it.
You must run some pkg commands, answer Y if it asks you to.
First update the repositories and upgrade the packages using
Code:
pkg update
Next you must install some dependencies
Code:
pkg install binutils bison flex git ninja patchelf python wget zip
The pip version Termux provides isn't always the latest so it must be updated too using
Code:
/data/data/com.termux/files/usr/bin/python3 -m pip install --upgrade pip
You will use pip3 to install the rest of the dependencies
Code:
pip3 install mako meson
Since you aren't cross compiling you need to create the path that hosts the native file
Code:
mkdir -p ~/.local/share/meson/native
and then download the native file for meson using
Code:
curl https://pastebin.com/raw/zdVCZASL>~/.local/share/meson/native/mesa
This file is made for android-ndk-r23b so if a new version gets released use nano to edit it and replace all occurencies of android-ndk-r23b.
You need to download the latest Termux-NDK
(at the moment of writing this the latest is android-ndk-r23b if that changes obviously replace the commands of the guide with the new name and the url bellow)
Code:
wget https://github.com/Lzhiyong/termux-ndk/releases/download/android-ndk/android-ndk-r23b-aarch64.zip
then extract it
Code:
unzip android-ndk-r23b-aarch64.zip
and remove the archive since it isn't needed anymore
Code:
rm android-ndk-r23b-aarch64.zip
Then you need to download libdrm for arm64 from the alarm project's repositories. Simply go to https://archlinuxarm.org/packages/aarch64/libdrm, hold the Download button and copy the url. At the moment the latest one is the one below so change the commands depending on the latest version.
Code:
wget http://mirror.archlinuxarm.org/aarch64/extra/libdrm-2.4.109-1-aarch64.pkg.tar.xz
Then you need to extract it
Code:
tar -xf libdrm-2.4.109-1-aarch64.pkg.tar.xz -C android-ndk-r23b
You then delete the archive since it's no longer of use
Code:
rm libdrm-2.4.109-1-aarch64.pkg.tar.xz
Now you must change the prefix of the libdrm pc file to point to our local pkgconfig
Code:
sed -i 's#prefix=#&/data/data/com.termux/files/home/android-ndk-r23b#g' ~/android-ndk-r23b/usr/lib/pkgconfig/libdrm.pc
You may now clone the mesa repository
Code:
git clone https://gitlab.freedesktop.org/mesa/mesa.git
and get inside it
Code:
cd ~/mesa
Configure the build environment using the meson command below
Code:
meson build-android-aarch64 --native-file mesa -Dbuildtype=release -Dplatforms=android -Dplatform-sdk-version=31 -Dandroid-stub=true -Dgallium-drivers= -Dvulkan-drivers=freedreno -Dfreedreno-kgsl=true -Dcpp_rtti=false -Db_lto=true
and then compile
Code:
ninja -C build-android-aarch64
Linking might take some time but once it's finished go back to Termux' home directory using
Code:
cd ~
Now download the template for the Magisk Driver package
Code:
wget https://cdn.discordapp.com/attachments/894694753684320296/943268696426684456/mesa_lto.zip
and extract it
Code:
unzip mesa_lto.zip -d mesa_lto
then cd inside
Code:
cd mesa_lto
and copy the blob you compiled
Code:
cp ~/mesa/build-android-aarch64/src/freedreno/vulkan/libvulkan_freedreno.so ./system/vendor/lib64/hw/
If you are building for another phone you have to run termux on that other phone and get the name of the vulkan library using
Code:
ls /system/vendor/lib64/hw/|grep vulkan
and then run patchelf and rename the blob.
If not, you can just run these commands that will fetch the name of your phone's library and perform elf name patching
Code:
patchelf --set-soname $(ls /system/vendor/lib64/hw/|grep vulkan) system/vendor/lib64/hw/libvulkan_freedreno.so
and renaming
Code:
mv system/vendor/lib64/hw/libvulkan_freedreno.so system/vendor/lib64/hw/$(ls /system/vendor/lib64/hw/|grep vulkan)
Finally zip the package
Code:
zip -r ../mesa_lto.zip *
and go back to Termux' home directory
Code:
cd ..
Delete the extracted folder, it's not needed anymore
Code:
rm -rf mesa_lto
Push the Magisk package to your phone's home folder
Code:
cp mesa_lto.zip /storage/emulated/0
Close Termux
Code:
exit
Flash with Magisk and reboot.
If you have other Magisk driver packages, disable them.
If you want to compile again you don't have to reclone, just cd into the mesa directory and do
Code:
git pull
You may also have to delete the build-android-aarch64 folder.

samantas5855 said:
Linux's driver stack is awesome, there's no need for introduction. the MESA devs have given us some of the best drivers out there for AMD and Intel GPUs on Desktop Computers and Laptops. MESA also has drivers for mobile chipset GPUs like Panfrost for Mali or Freedreno for Adreno. In today's driver we'll compile (optional) and install Freedreno's Vulkan driver called Turnip on our phones. Sadly we can't use any of the other drivers like the OpenGL/OpenGL ES ones since we cannot boot a mainline kernel (You can run old OpenGL games using ZINK on Termux tho but that's something for another day). Most if not all 3d games use Vulkan tho and that's what we mostly care about. I didn't take any metrics but performance feels better on Freedreno.
I tested this on latest Arrow Os with stock kernel and compiled on Arch Linux x86.
My caps with Freedreno:https://vulkan.gpuinfo.org/displayreport.php?id=12275
My caps with the proprietary driver:https://vulkan.gpuinfo.org/displayreport.php?id=11146
You're gonna need:
Magisk
A pc to compile (Linux or use WSL2)
The guide I followed was this one: https://docs.mesa3d.org/android.html
Building:
First things first, we gotta get our dependencies sorted out. I'm on Arch Linux so the command that follows is for Arch
Code:
sudo pacman -Syu meson git patchelf
We're also gonna need android studio in order to download the NDK, you can also do it manually if you want.
Then we're gonna get the NDK, launch android studio, open a project (if you don't have create an empty one), then go to Tools>SDK Manager. Click the SDK Tools tab, untick Hide Obsolete Packages on the bottom, and get NDK Obsolete. Copy the Android SDK Location from the top, close Android Studio and open this path on your file manager. Enter the ndk-bundle folder and copy its path, this is your NDKDIR for later. Create a folder inside called pkgconfig.
Since we're compiling on an x86, we're gonna need libdrm for arm64, one source to get it was https://archlinuxarm.org/packages/arm/libdrm, it doesn't matter if you use Arch or not, just click the Download link on the right. We have to extract this somewhere and point the compiler to it, I created a folder called deps in the ndk-bundle directory (next to pkgconfig). In there we extract the folders include and lib (for example the path is
Code:
/home/spiros/Android/Sdk/ndk-bundle/deps/lib/
) found on the folder usr of the tar.gz we downloaded. After we extract them, in the lib folder there's a pkgconfig folder, we copy the file called libdrm.pc to the pkgconfig we created on the previous step and delete this folder.
We go to the folder pkgconfig on the root of ndk-bundle and edit libdrm.pc (the file we copied on the previous step). We only wanna change the first line from /usr to the path of the folder we extracted libdrm, in my case . We save and close the file.
Now we need to create a configuration file for meson. Create the file
Code:
~/.local/share/meson/cross/android-aarch64
, where ~ is your home folder. If these folders don't exist create them.
The contents of the file are these:
Code:
[binaries]
ar = 'NDKDIR/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android-ar'
c = ['ccache', 'NDKDIR/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android29-clang']
cpp = ['ccache', 'NDKDIR/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android29-clang++', '-fno-exceptions', '-fno-unwind-tables', '-fno-asynchronous-unwind-tables', '-static-libstdc++']
c_ld = 'lld'
cpp_ld = 'lld'
strip = 'NDKDIR/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android-strip'
# Android doesn't come with a pkg-config, but we need one for meson to be happy not
# finding all the optional deps it looks for. Use system pkg-config pointing at a
# directory we get to populate with any .pc files we want to add for Android
pkgconfig = ['env', 'PKG_CONFIG_LIBDIR=NDKDIR/pkgconfig', '/usr/bin/pkg-config']
[host_machine]
system = 'linux'
cpu_family = 'arm'
cpu = 'armv8'
endian = 'little'
Just search and replace NDKDIR with the path of your ndk-bundle.
Now we have to clone the Mesa project.
On a terminal
Code:
git clone https://gitlab.freedesktop.org/mesa/mesa.git
then
Code:
cd mesa
to enter inside.
Now we have to compile it, the commands we'll use for it are
Code:
meson build-android-aarch64 \
--cross-file android-aarch64 \
-Dplatforms=android \
-Dplatform-sdk-version=30 \
-Dandroid-stub=true \
-Dgallium-drivers= \
-Dvulkan-drivers=freedreno \
-Dfreedreno-kgsl=true
(optionally you can add performance flags to this one like -O3 and -flto=full at your own risk)
and
Code:
ninja -C build-android-aarch64
If it doesn't compile successfully please comment, if it does but says llvm no it's safe to ignore this.
Considering we are already on mesa's folder, the driver we compiled will be at
Code:
build-android-aarch64/src/freedreno/vulkan/libvulkan_freedreno.so
Mesa's guide tells us that "libvulkan wants the SONAME to match" but not how so to do that first we need to know the SONAME of our current driver, so on our Android device we navigate to /vendor/lib64/hw and in there is our current vulkan driver, in my case the name of this driver is
Code:
vulkan.adreno.so
so on my pc using patchelf I'll patch libvulkan_freedreno.so with the following command (replace the path if you aren't inside mesa's folder for some reason)
Code:
patchelf --set-soname vulkan.adreno.so build-android-aarch64/src/freedreno/vulkan/libvulkan_freedreno.so
and rename libvulkan_freedreno.so to the one that your phone had, vulkan.adreno.so for me.
Once we do that we need to make a magisk package, the reason we do this is because /vendor needs to be resized for our driver to fit. So download this zip file, https://cdn.discordapp.com/attachments/669901591662559232/879822129313497108/gam.zip extract it, and place the driver (vulkan.adreno.so on my case) on system/vendor/lib64/hw/. Once you do that zip the files again and transfer the zip to your phone.
On your phone, first you'll have to edit your build.prop, it's on /system/build.prop. I used BuildProp Editor from PlayStore by JRummy Apps. Search for
Code:
debug.hwui.renderer
and set its value to
Code:
skiagl
If it doesn't exist, add it and then set it's value to skiagl. We do this in order to be 100% sure that Vulkan isn't used to render the UI in case something goes wrong.
Now you can flash the zip on Magisk and upon restarting you should be on Freedreno!
For those of you that don't wanna compile, if you make sure that on /vendor/lib64/hw you have a file called vulkan.adreno.so (otherwise you have to patch it with patchelf and rename it as stated above) and are on android 11 you can flash the zip I compiled yesterday on your on risk.
File upload and sharing. Large file transfers. Free online cloud storage.
Visit this link to download: mesa.zip
files.fm
No modifications were done, source can be found at https://gitlab.freedesktop.org/mesa/mesa, commit id 2201f5a58c07866130a67602875d13b1824708e0
Click to expand...
Click to collapse
hello, I was trying to follow ur instructions, Im stuck at
Bash:
ninja -C build-android-aarch64
The error is:
Code:
ld.lld: error: /home/user/Android/Sdk/ndk-bundle/deps/lib/libdrm.so is incompatible with aarch64linux
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
I'm using ubuntu, not arch linux

avatarwan13 said:
hello, I was trying to follow ur instructions, Im stuck at
Bash:
ninja -C build-android-aarch64
The error is:
Code:
ld.lld: error: /home/user/Android/Sdk/ndk-bundle/deps/lib/libdrm.so is incompatible with aarch64linux
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
I'm using ubuntu, not arch linux
Click to expand...
Click to collapse
I got the same error.
The link in the post for the libdrm was for arm
The link for arm64 libdrm was:
libdrm (aarch64) | Packages | Arch Linux ARM
archlinuxarm.org
I replaced the lib and include files again, and it successfully compiled.
I did the patchelf commands
I replaced the vulkan file in the vendor partition
It did not work when I rebooted, so I changed the permissions of the freedreno vulkan driver to 644.
When I rebooted, the freedreno vulkan driver was now working.
Edit:
The file "aarch64-linux-android-ar" in the new versions of the ndk bundles was renamed to "llvm-ar". I was able to compile using a newer version of ndk instead of the deprecated one.

How can do it without PC I have only android device.

astronomy2021 said:
How can do it without PC I have only android device.
Click to expand...
Click to collapse
Lol good luck

astronomy2021 said:
How can do it without PC I have only android device.
Click to expand...
Click to collapse
I have tried to compile on an android device using termux ubuntu chroot (not proot). I tried using the Linaro clang 13 toolchain for aarch64.
When I tried compiling in termux with the clang 13 toolchain for aarch64, I keep on getting this error:
"error: expected function body after function declarator"
When I compile using ndk toolchain on computer, I do not get this error.
I think it still might be possable to compile using android device.

Apparently it doesn't build release by default, I changed the meson command to do so. Should be faster now
CHECK_123 said:
I got the same error.
The link in the post for the libdrm was for arm
The link for arm64 libdrm was:
libdrm (aarch64) | Packages | Arch Linux ARM
archlinuxarm.org
I replaced the lib and include files again, and it successfully compiled.
I did the patchelf commands
I replaced the vulkan file in the vendor partition
It did not work when I rebooted, so I changed the permissions of the freedreno vulkan driver to 644.
When I rebooted, the freedreno vulkan driver was now working.
Edit:
The file "aarch64-linux-android-ar" in the new versions of the ndk bundles was renamed to "llvm-ar". I was able to compile using a newer version of ndk instead of the deprecated one.
Click to expand...
Click to collapse
Big thanks, I linked the arm32 binary by mistake

Driver is approx. x2 slower than the proprietary one... Damn
P.S. Also i cant compile it by myself, Meson is crying about C-compilers...
SPENT 7 HOURS ON FIXING THIS... DID NOTHING.
meson.build:21:0: ERROR: Unknown compiler(s): ['cc', 'gcc', 'clang', 'pgcc', 'icc']
The follow exceptions were encountered:
Running "cc --version" gave "[Errno 2] No such file or directory: 'cc'"
Running "gcc --version" gave "[Errno 2] No such file or directory: 'gcc'"
Running "clang --version" gave "[Errno 2] No such file or directory: 'clang'"
Running "pgcc --version" gave "[Errno 2] No such file or directory: 'pgcc'"
Running "icc --version" gave "[Errno 2] No such file or directory: 'icc'"
Freakin help

_RusJJ_ said:
Driver is approx. x2 slower than the proprietary one... Damn
P.S. Also i cant compile it by myself, Meson is crying about C-compilers...
SPENT 7 HOURS ON FIXING THIS... DID NOTHING.
meson.build:21:0: ERROR: Unknown compiler(s): ['cc', 'gcc', 'clang', 'pgcc', 'icc']
The follow exceptions were encountered:
Running "cc --version" gave "[Errno 2] No such file or directory: 'cc'"
Running "gcc --version" gave "[Errno 2] No such file or directory: 'gcc'"
Running "clang --version" gave "[Errno 2] No such file or directory: 'clang'"
Running "pgcc --version" gave "[Errno 2] No such file or directory: 'pgcc'"
Running "icc --version" gave "[Errno 2] No such file or directory: 'icc'"
Freakin help
Click to expand...
Click to collapse
You say its 2x slower, how did you compare

samantas5855 said:
You say its 2x slower, how did you compare
Click to expand...
Click to collapse
AetherSX2, 3DMark

_RusJJ_ said:
AetherSX2, 3DMark
Click to expand...
Click to collapse
3DMark is a wrong way to compare; since turnip doesn't have a shader cache yet it will always score worse there until it gets one.
As for aethersx2, I think the dev is interested in bundling turnip with the emu.
Did you use my latest magisk zip with vulkan 1.2?

samantas5855 said:
Did you use my latest magisk zip with vulkan 1.2?
Click to expand...
Click to collapse
Of course

_RusJJ_ said:
Of course
Click to expand...
Click to collapse
Regarding your issues with compiling, what Linux distro are you on?

samantas5855 said:
Regarding your issues with compiling, what Linux distro are you on?
Click to expand...
Click to collapse
Im using WSL. Should be a Ubuntu 20.4

_RusJJ_ said:
Im using WSL. Should be a Ubuntu 20.4
Click to expand...
Click to collapse
Do it properly on a proper linux distro, prefferably arch

Hi I tested your compiled Mesa Turnip Freedreno drivers on Xiaomi Mi 10T 925Mhz/940MHz GPU OC.
Snapdragon 865 with Cortex-A77 and Cortex-A55.
These performance metric qualify to Poco F3 as well.
AetherSX2 with latest v1276 in Vulkan
Dolphin Emulator latest development build v5.0-16009
We can clearly see that Freedreno Turnip Mesa drivers have loss -10-20% of frame rate in this emulation. I don't know why maybe be of lack of Shader cache or other things.
Think like EGG Ns emulator running on Yuzu code won't start because needs Shader caching to work.
Adreno drivers OpenGL v530 possible to update OpenGL v604 or OpenGL v611 which comes with massive boost +10%-15% Vulkan performance.
Tested Game Star Wars: Episode III – Revenge of the Sith Video game for AetherSX2 for PS2 and Metroid prime for GameCube.
Freedreno Turnip Mesa drivers build above Vulkan 1.2.199
AetherSX2 3200x2235 5X native Resolution of PS2.
Freedreno Turnip Mesa drivers LTO 03 VK 1.2.199
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
OpenGL ES 3.2 [email protected] ([email protected], I3f7239a212, 1620400307) (Date:05/07/21)
Dolphin Emulator 3840x3168 aka 4K 6X GameCube native Resolution
Freedreno Turnip Mesa drivers LTO 03 VK 1.2.199
OpenGL ES 3.2 [email protected] ([email protected], I3f7239a212, 1620400307) (Date:05/07/21)

I am not able to compile it shows below error
--
[67/477] Compiling C++ object src/util/libmesa_util.a.p/u_qsort.cpp.o
FAILED: src/util/libmesa_util.a.p/u_qsort.cpp.o
ccache /local/mnt/workspace/sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android29-clang++ -fuse-ld=lld -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -static-libstdc++ -Isrc/util/libmesa_util.a.p -Isrc/util -I../src/util -Iinclude -I../include -I../include/android_stub -Isrc -I../src -Isrc/mapi -I../src/mapi -I../src/mesa -I../src/gallium/include -I../src/gallium/auxiliary -I/usr/include -fvisibility=hidden -flto -Xclang -fcolor-diagnostics -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++14 -O3 -g -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS '-DPACKAGE_VERSION="22.1.0-devel"' '-DPACKAGE_BUGREPORT="https://gitlab.freedesktop.org/mesa/mesa/-/issues"' -DHAVE_ANDROID_PLATFORM -DUSE_ELF_TLS -DENABLE_ST_OMX_BELLAGIO=0 -DENABLE_ST_OMX_TIZONIA=0 -DEGL_NO_X11 -DANDROID -DANDROID_API_LEVEL=28 -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64 -DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL -DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_UNREACHABLE -D_GNU_SOURCE -DUSE_ARM_ASM -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_TIMESPEC_GET -DHAVE_FLOCK -DHAVE_STRTOK_R -DHAVE_GETRANDOM -DHAVE_POSIX_MEMALIGN -DHAVE_STRTOD_L -DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR -DHAVE_ZLIB -DHAVE_COMPRESSION -DHAVE_PTHREAD -DHAVE_LIBDRM -DMESA_EXECMEM -DVK_USE_PLATFORM_ANDROID_KHR -Qunused-arguments -fPIC -pthread -MD -MQ src/util/libmesa_util.a.p/u_qsort.cpp.o -MF src/util/libmesa_util.a.p/u_qsort.cpp.o.d -o src/util/libmesa_util.a.p/u_qsort.cpp.o -c ../src/util/u_qsort.cpp
In file included from ../src/util/u_qsort.cpp:25:
In file included from /local/mnt/workspace/sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/../sysroot/usr/include/c++/v1/thread:87:
In file included from /local/mnt/workspace/sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/../sysroot/usr/include/c++/v1/__functional_base:15:
/local/mnt/workspace/sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/../sysroot/usr/include/c++/v1/typeinfo:215:14: error: cast from pointer to smaller type 'std::__type_info_implementations::__non_unique_arm_rtti_bit_impl::__type_name_t' (aka 'unsigned int') loses information
return reinterpret_cast<__type_name_t>(__v);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/local/mnt/workspace/sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/../sysroot/usr/include/c++/v1/typeinfo:221:16: error: reinterpret_cast from 'std::__type_info_implementations::__non_unique_arm_rtti_bit_impl::__type_name_t' (aka 'unsigned int') to 'size_t' (aka 'unsigned long') is not allowed
return reinterpret_cast<size_t>(__v);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/util/u_qsort.cpp:25:
In file included from /local/mnt/workspace/sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/../sysroot/usr/include/c++/v1/thread:94:
In file included from /local/mnt/workspace/sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/../sysroot/usr/include/c++/v1/__mutex_base:16:
In file included from /local/mnt/workspace/sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/../sysroot/usr/include/c++/v1/__threading_support:27:
/usr/include/pthread.h:681:22: error: 'regparm' is not valid on this platform
__attribute__ ((__regparm__ (1)));
^ ~
/usr/include/pthread.h:693:19: error: 'regparm' is not valid on this platform
__attribute__ ((__regparm__ (1)));
^ ~
/usr/include/pthread.h:716:22: error: 'regparm' is not valid on this platform
__attribute__ ((__regparm__ (1)));
^ ~
/usr/include/pthread.h:729:19: error: 'regparm' is not valid on this platform
__attribute__ ((__regparm__ (1)));
^ ~
/usr/include/pthread.h:734:22: error: 'regparm' is not valid on this platform
__attribute__ ((__regparm__ (1))) __attribute__ ((__noreturn__))
^ ~
7 errors generated.

dkpandya said:
I am not able to compile it shows below error
--
[67/477] Compiling C++ object src/util/libmesa_util.a.p/u_qsort.cpp.o
FAILED: src/util/libmesa_util.a.p/u_qsort.cpp.o
ccache /local/mnt/workspace/sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android29-clang++ -fuse-ld=lld -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -static-libstdc++ -Isrc/util/libmesa_util.a.p -Isrc/util -I../src/util -Iinclude -I../include -I../include/android_stub -Isrc -I../src -Isrc/mapi -I../src/mapi -I../src/mesa -I../src/gallium/include -I../src/gallium/auxiliary -I/usr/include -fvisibility=hidden -flto -Xclang -fcolor-diagnostics -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++14 -O3 -g -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS '-DPACKAGE_VERSION="22.1.0-devel"' '-DPACKAGE_BUGREPORT="https://gitlab.freedesktop.org/mesa/mesa/-/issues"' -DHAVE_ANDROID_PLATFORM -DUSE_ELF_TLS -DENABLE_ST_OMX_BELLAGIO=0 -DENABLE_ST_OMX_TIZONIA=0 -DEGL_NO_X11 -DANDROID -DANDROID_API_LEVEL=28 -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64 -DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL -DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_UNREACHABLE -D_GNU_SOURCE -DUSE_ARM_ASM -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_TIMESPEC_GET -DHAVE_FLOCK -DHAVE_STRTOK_R -DHAVE_GETRANDOM -DHAVE_POSIX_MEMALIGN -DHAVE_STRTOD_L -DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR -DHAVE_ZLIB -DHAVE_COMPRESSION -DHAVE_PTHREAD -DHAVE_LIBDRM -DMESA_EXECMEM -DVK_USE_PLATFORM_ANDROID_KHR -Qunused-arguments -fPIC -pthread -MD -MQ src/util/libmesa_util.a.p/u_qsort.cpp.o -MF src/util/libmesa_util.a.p/u_qsort.cpp.o.d -o src/util/libmesa_util.a.p/u_qsort.cpp.o -c ../src/util/u_qsort.cpp
In file included from ../src/util/u_qsort.cpp:25:
In file included from /local/mnt/workspace/sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/../sysroot/usr/include/c++/v1/thread:87:
In file included from /local/mnt/workspace/sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/../sysroot/usr/include/c++/v1/__functional_base:15:
/local/mnt/workspace/sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/../sysroot/usr/include/c++/v1/typeinfo:215:14: error: cast from pointer to smaller type 'std::__type_info_implementations::__non_unique_arm_rtti_bit_impl::__type_name_t' (aka 'unsigned int') loses information
return reinterpret_cast<__type_name_t>(__v);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/local/mnt/workspace/sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/../sysroot/usr/include/c++/v1/typeinfo:221:16: error: reinterpret_cast from 'std::__type_info_implementations::__non_unique_arm_rtti_bit_impl::__type_name_t' (aka 'unsigned int') to 'size_t' (aka 'unsigned long') is not allowed
return reinterpret_cast<size_t>(__v);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/util/u_qsort.cpp:25:
In file included from /local/mnt/workspace/sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/../sysroot/usr/include/c++/v1/thread:94:
In file included from /local/mnt/workspace/sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/../sysroot/usr/include/c++/v1/__mutex_base:16:
In file included from /local/mnt/workspace/sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/../sysroot/usr/include/c++/v1/__threading_support:27:
/usr/include/pthread.h:681:22: error: 'regparm' is not valid on this platform
__attribute__ ((__regparm__ (1)));
^ ~
/usr/include/pthread.h:693:19: error: 'regparm' is not valid on this platform
__attribute__ ((__regparm__ (1)));
^ ~
/usr/include/pthread.h:716:22: error: 'regparm' is not valid on this platform
__attribute__ ((__regparm__ (1)));
^ ~
/usr/include/pthread.h:729:19: error: 'regparm' is not valid on this platform
__attribute__ ((__regparm__ (1)));
^ ~
/usr/include/pthread.h:734:22: error: 'regparm' is not valid on this platform
__attribute__ ((__regparm__ (1))) __attribute__ ((__noreturn__))
^ ~
7 errors generated.
Click to expand...
Click to collapse
Did you try module above ?

astronomy2021 said:
Did you try module above ?
Click to expand...
Click to collapse
yes but i was seeing some crashes so thought of trying latest