Related
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.
Github repo: https://github.com/kernel-killer/android_kernel_huawei_h30u10
All changes I made since last commit are in my private repo.
Install packages (Not sure if it's right):
Code:
sudo apt-get install build-essential
Note: Please run ./mk ckeck-env to verify your build enviroment (Newer GNU MAKE will fail but the code compiles the same with new or older version)
Build:
Code:
./mk bm_new k
Testing your new kernel:
Download both attachments (KernelSwapper and BootimgRestore).
Append headers from stock kernel to zImage (which can be found at ./out/target/product/huawei82_cwet_kk/obj/KERNEL_OBJ/arch/arm/boot/zImage)
In KernelSwapper update 'kernel' with your own generated zImage rename it to 'kernel' and replace it inside zip.
In BootimgRestore replace 'boot.img' with your current ROM's boot.img in case that something goes wrong (e.g.: Phone not booting).
Copy the two new zips into phone's memory (or SD card) and flash KernelSwapper.
===== Reserved #1 =====
Thanks for the awesome work KK. I am on CM 13 3.4.67 kernel. Can i use this or do i have to be in stock rom for testing the kernal?
Sent from my Honor 3C using Tapatalk
---------- Post added at 06:12 AM ---------- Previous post was at 06:02 AM ----------
Update : Flashed the kernel, phone booted but felt laggish while using. I am still testing, will let you know what happens
Sent from my Honor 3C using Tapatalk
karkeankit said:
Thanks for the awesome work KK. I am on CM 13 3.4.67 kernel. Can i use this or do i have to be in stock rom for testing the kernal?
Sent from my Honor 3C using Tapatalk
---------- Post added at 06:12 AM ---------- Previous post was at 06:02 AM ----------
Update : Flashed the kernel, phone booted but felt laggish while using. I am still testing, will let you know what happens
Sent from my Honor 3C using Tapatalk
Click to expand...
Click to collapse
Yes, I'm sure that the kernel has multiple bugs. The phone may feel laggish because there is enabled low-level kernel debugging over UART.
Thank you for testing...
kernel.killer said:
Yes, I'm sure that the kernel has multiple bugs. The phone may feel laggish because there is enabled low-level kernel debugging over UART.
Thank you for testing...
Click to expand...
Click to collapse
You are welcome, wishint you good luck for further development
Sent from my Honor 3C using Tapatalk
Hi, tnx for The kernel
if i Update my kernel VPN bug in CM12.1 will fix?
hamadk said:
Hi, tnx for The kernel
if i Update my kernel VPN bug in CM12.1 will fix?
Click to expand...
Click to collapse
Nope, it's ROM bug not a kernel bug plus I have released only development preview version which has enabled many debugging options and it may be quite buggy.
Thanks, but can this process led to a suitable kernel for CM13?
Does this kernel fixes the video playback problem and the recording problem?(Can't play or capture 720p videos, screen recorder works fine, just the camera.)
Sent from my Huawei Honor 3C using XDA Labs
Lumpbloom7 said:
Does this kernel fixes the video playback problem and the recording problem?(Can't play or capture 720p videos, screen recorder works fine, just the camera.)
Sent from my Huawei Honor 3C using XDA Labs
Click to expand...
Click to collapse
http://forum.xda-developers.com/showpost.php?p=67848925&postcount=8
mhxygh said:
Thanks, but can it this process led to a suitable kernel for CM13?
Click to expand...
Click to collapse
Aim of this project is to make stock kernel sources stable for KitKat ROMs (It is originally for KK) but somebody else may patch them for CM 13. I am not working on this nor I'll do.
Will you be adding extra CPU governors and IO schedulers along with kernel level wakeups for double tap waking?
I was wondering who else is developing kernel 3.10.XX for this device ?
Ms_Julia said:
I was wondering who else is developing kernel 3.10.XX for this device ?
Click to expand...
Click to collapse
Actually, nobody is working on 3.10.X kernel. And I'm rather focusing on LineageOS for now.
What is the defconf for our device in kernel source
imranpopz said:
What is the defconf for our device in kernel source
Click to expand...
Click to collapse
This should include most configs
Code:
/* Mediatek common */
./mediatek/config/common/autoconfig/kconfig/AEE
./mediatek/config/common/autoconfig/kconfig/USER
./mediatek/config/common/ProjectConfig.mk
/* MT6582 common */
./mediatek/config/mt6582/autoconfig/kconfig/platform
./mediatek/config/mt6582/ProjectConfig.mk
/* h30u10 device specific */
./mediatek/config/huawei82_cwet_kk/autoconfig/kconfig/project
./mediatek/config/huawei82_cwet_kk/ProjectConfig.mk
kernel.killer said:
This should include most configs
Code:
/* Mediatek common */
./mediatek/config/common/autoconfig/kconfig/AEE
./mediatek/config/common/autoconfig/kconfig/USER
./mediatek/config/common/ProjectConfig.mk
/* MT6582 common */
./mediatek/config/mt6582/autoconfig/kconfig/platform
./mediatek/config/mt6582/ProjectConfig.mk
/* h30u10 device specific */
./mediatek/config/huawei82_cwet_kk/autoconfig/kconfig/project
./mediatek/config/huawei82_cwet_kk/ProjectConfig.mk
Click to expand...
Click to collapse
Replace Device Name with the configuration file found at:
Source/arch/arm/configs
It's written in this way something_DeviceCodename_user_defconfig
I need for the above step.. ☝☝☝
imranpopz said:
Replace Device Name with the configuration file found at:
Source/arch/arm/configs
It's written in this way something_DeviceCodename_user_defconfig
I need for the above step.. ☝☝☝
Click to expand...
Click to collapse
Well... This is Mediatek, DO NOT expect the sources to look nice. The configs are scattered through ./mediatek subdirectories, *.mk files are parsed and configs are assembled during build. Unfortunatelly, even if you manually assemble .config you will NOT be able to build the kernel. It is full of dirty hacks (Mediatek) and just typing "make" won't work, build will break.
Build:
Code:
$ git clone https://github.com/kernel-killer/android_kernel_huawei_h30u10.git
$ cd android_kernel_huawei_h30u10
$ export ARCH=arm && export ARCH_MTK_PLATFORM=mt6582 && export TARGET_PRODUCT=huawei82_cwet_kk
$ export CROSS_COMPILE=/path-to-your-toolchain/.../bin/arm-linux-androideabi-
$ ./mk n k
Code:
$ ./mk -h
Usage: (makeMtk|mk) [options] project actions [modules]
Options:
-t, -tee : Print log information on the standard-out.
-o, -opt=bypass_argument_to_make
: Pass extra arguments to make.
-h, -help : Print this message and exit.
Projects:
one of available projects.
Actions:
listp, listproject
: List all available projects.
check-env : Check if build environment is ready.
check-dep : Check feature dependency.
n, new : Clean and perform a full build.
c, clean : Clean the immediate files(such as, objects, libraries etc.).
r, remake : Rebuild(target will be updated if any dependency updats).
mrproper : Remove all generated files + config + various backup files in Kbuild process.
bm_new : "new" + GNU make's "-k"(keep going when encounter error) feature.
bm_remake : "remake" + GNU make's "-k"(keep going when encounter error) feature.
mm : Build module through Android native command "mm"
mma : Build module through Android native command "mma"
emigen : Generate EMI setting source code.
nandgen : Generate supported NAND flash device list.
codegen : Generate trace DB(for META/Cather etc. tools used).
drvgen : Generate driver customization source.
custgen : Generate customization source.
javaoptgen : Generate the global java options.
ptgen : Generate partition setting header & scatter file.
bindergen : Generate binder related information
sign-image : Sign all the image generated.
encrypt-image : Encrypt all the image generated.
update-api : Android default build action
(be executed if system setting or anything removed from API).
check-modem : Check modem image consistency.
upadte-modem : Update modem image located in system.img.
modem-info : Show modem version
gen-relkey : Generate releasekey for application signing.
check-appres : Check unused application resource.
sdk : Build sdk package.
win_sdk : Build sdk package with a few Windows tools.
banyan_addon : Build MTK sdk addon.
banyan_addon_x86 :Build MTK sdk x86 addon.
cts : Build cts package.
bootimage : Build boot image(boot.img).
cacheimage : Build cache image(cache.img).
systemimage : Build system image(system.img).
snod : Build system image without dependency.
(that is, ONLY pack the system image, NOT checking its dependencies.)
recoveryimage : Build recovery image(recovery.img).
secroimage : Build secro image(secro.img).
factoryimage : Build factory image(factory.img).
userdataimage : Build userdata image(userdata.img).
userdataimage-nodeps
: Build userdata image without dependency.
(that is, ONLY pack the userdata image, NOT checking its dependencies.)
dump-products : Dump products related configuration(PRODUCT_PACKAGE,PRODUCT_NAME ect.)
target-files-package
: Build the target files package.
(A zip of the directories that map to the target filesystem.
This zip can be used to create an OTA package or filesystem image
as a post-build step.)
updatepackage : Build the update package.
dist : Build distribution package.
Modules:
pl, preloader : Specify to build preloader.
lk : Specify to build little kernel.
md32 : Specify to build DSP md32.
tz, trustzone : Specify to build trusted execution environment.
k, kernel : Specify to build kernel.
dr, android : Specify to build android.
NULL : Specify to build all components/modules in default.
k <module path>
: Specify to build kernel component/module with the source path.
dr <module name>
: Specify to build android component/module with module name.
Other tools:
prebuilts/misc/linux-x86/ccache/ccache -M 10G
: Set CCACHE pool size to 10GB
Example:
./mk -t e1k emigen
: Generate EMI setting source code.
./mk -o=TARGET_BUILD_VARIANT=user e1k n
: Start a user mode full build.
./mk listp : List all available projects.
./mk e1k bootimage
: Build bootimage for e1k project.
./mk e1k bm_new k
: Build kernel for e1k project.
./makeMtk e1k c,bm_remake pl k
: Clean & Build preloader and kernel for e1k project.
./makeMtk e1k n k kernel/xxx/xxx
: Build(full build) kernel component/module
under the path "kernel/xxx/xxx" for e1k project.
./makeMtk e1k r dr Gallery
: Rebuild android module named Gallery for e1k project.
./makeMtk e1k mm packages/apps/Settings
: Change Directory to packages/apps/Settings and execute "mm"
./makeMtk e1k mma packages/apps/Settings
: Change Directory to packages/apps/Settings and execute "mma"
Edit:
I fixed the sources, so menuconfig can be used.
Apply patch:
Code:
$ git am 0001-Fix-build-using-make-command.patch
Build:
Code:
$ cd kernel && export ARCH=arm && export ARCH_MTK_PLATFORM=mt6582 && export TARGET_PRODUCT=huawei82_cwet_kk
$ export CROSS_COMPILE=/path-to-your-toolchain/.../bin/arm-linux-androideabi-
$ make -C $(pwd) O=output h30u10_defconfig menuconfig
$ make -C $(pwd) O=output
Append MTK headers:
Code:
$ ../mediatek/build/tools/mkimage output/arch/arm/boot/zImage KERNEL > output/zImage
*Note: I recommend using AOSP arm-linux-androideabi-4.9 toolchain.
Getting cp: cannot stat 'out/target/product/huawei82_cwet_kk_kernel.log
Make [1]: [kernel ] error 1
Make: *** [remake] error 2
UPDATE
Initial OmniROM release for Athene out now:
omni-7.1.1-20170219-athene-HOMEMADE.zip
--- Original OP below ---
Hi guys, I have started the bringup for OmniROM on Athene:
Device
Kernel
It starts to boot up, but gets stuck in the bootanimation and restarts soon after. According to dmesg / logcat, the modem does not come up (see attached files). I compared init.rc files and blobs being used with other roms (lineage / aex), but couldn't identify the root cause for that error at this early stage:
Code:
[ 7.022888,0] Fatal error on the modem.
[ 7.022913,0] modem subsystem failure reason: fs_device_efs_rmts.c:175:Invalid shared ram address from Apps.
@rahulsnair, @Silesh.Nair (or anybody else): Can you guys please help out here, is that something you have come across in any of your bringups? Really would like to bring Omni to life on Athene.
Thanks in advance :good:
Looks like rmt_storage can't load the needed modem firmware :
Code:
09-21 03:07:13.861 342 342 D rmt_storage: GZFSG open /fsg/athene_dsds_emea.img.gz
09-21 03:07:13.861 342 342 E rmt_storage: Couldn't open /fsg/athene_dsds_emea.img.gz, trying default for product-radio
09-21 03:07:13.862 342 342 E rmt_storage: Couldn't open /fsg/athene_emea.img.gz, trying default for radio
09-21 03:07:13.862 342 342 E rmt_storage: Couldn't open /fsg/emea.img.gz, trying default
09-21 03:07:13.862 342 342 E rmt_storage: Couldn't open /fsg/0.img.gz
09-21 03:07:13.862 342 342 I rmt_storage: rmt_storage_open_cb: Unable to open /boot/modem_fsg
Check that /fsg partition is mounted (can't check that in logs cause it's not full logs) and files are there.
You can also try to "strace" rmt-storage process :
Code:
strace -fF -s 1000 rmt_storage > /sdcard/rmt_storage_strace.txt
vache said:
Looks like rmt_storage can't load the needed modem firmware :
Check that /fsg partition is mounted (can't check that in logs cause it's not full logs) and files are there.
You can also try to "strace" rmt-storage process :
Click to expand...
Click to collapse
Good point, thanks. Haven't checked the mounts on boot yet. Eventually, fstab.qcom does not get parsed.
Making some progress: There is an issue with the ramdisk of the inline-built kernel: It is not picking up the correct .rc files. I don't get where these references to "recovery" are coming from:
Code:
<13>[ 3.022567,0] init: init second stage started!
<11>[ 3.207517,0] init: waitpid failed: No child processes
<11>[ 3.209434,0] init: property_set("ro.com.google.clientidbase", "android-motorola") failed
<11>[ 3.209584,0] init: property_set("ro.config.notification_sound", "Argon.ogg") failed
<11>[ 3.209599,0] init: property_set("ro.config.alarm_alert", "Helium.ogg") failed
<11>[ 3.209710,0] init: property_set("ro.config.ringtone", "Orion.ogg") failed
<13>[ 3.209803,0] init: (Loading properties from /default.prop took 0.00s.)
<11>[ 3.210260,0] init: /init.rc: 12: invalid command 'setcon'
<11>[ 3.210326,0] init: /init.rc: 62: invalid command 'load_all_props'
<11>[ 3.210406,0] init: could not import file '/init.recovery.logd.rc' from '/init.rc'
<13>[ 3.210688,0] init: (Parsing /init.recovery.usb.rc took 0.00s.)
<13>[ 3.210735,0] init: (Parsing /init.recovery.service.rc took 0.00s.)
<11>[ 3.210812,0] init: could not import file 'init.target.recovery.rc' from '/init.recovery.qcom.rc'
<13>[ 3.210827,0] init: (Parsing /init.recovery.qcom.rc took 0.00s.)
However, having flashed a Lineage kernel, it's booting up now.
@vache: /fsg indeed was not mounted. I think there is an issue with the mkdir, will amend that now.
Unhandled fsg_file security context on the fstab /fsg entry was the root cause for not mounting /fsg. Omni kernel booting up now.
golden-guy said:
Unhandled fsg_file security context on the fstab /fsg entry was the root cause for not mounting /fsg. Omni kernel booting up now.
Click to expand...
Click to collapse
Well done
To get RIL working, you need to add android_system_qcom from Lineage in your manifest and rebuilt.
Or you can push libqsap_sdk.so manually.
vache said:
Well done
To get RIL working, you need to add android_system_qcom from Lineage in your manifest and rebuilt.
Or you can push libqsap_sdk.so manually.
Click to expand...
Click to collapse
Thanks mate, I have done that yesterday to get RIL working (radio logcat showed that rild was complaining about that missing libqsap_sdk.so lib). All fine there already.
But I am still struggling with at least three things atm: Sensors, media playback and camcorder.
Sensors: I can see them initialized, but they don't return any values. According to logcat, e.g proximity gets disabled on screen on (sic!) Which sounds weird tbh
Media playback: Acodec cannot instantiate decoders upon ringtone playback and when music is to be played via bluetooth. mp3/mpeg playback does work when played via phone' speaker though. It could be a codec issue, but it could be audio policy / routing related. We are using a custom policy, aren't we?
Camcorder - didn't look into that yet. But is very likely related to media codec issue.
Will add some logs to further explain.
EDIT: Logs are added now.
PS: Device repo updated
Will cross-check with LineageOS, but the lack of sensor data might be permission related after all. All sensors seem to be up and configured, with their /dev and /sys entries being populated. Unfortunately, there is no error to be seen in the logs, giving no indication of the root cause...
Got the sensor issue sorted. It was selinux related again - what else. :silly:
Anyhow, one issue less.
Great news. How many issues are left now? :highfive:
Seriously, i would really appreaciate it if it´ll be released and maintained sometime... :fingers-crossed:
vinylmeister said:
Great news. How many issues are left now? :highfive:
Seriously, i would really appreaciate it if it´ll be released and maintained sometime... :fingers-crossed:
Click to expand...
Click to collapse
He is courteous enough to give us status updates on what is happening and what he is currently fixing.
I dont think he would appreciate the ETA-ish question.
It will be released when he is done. Im sure he is not on this full time. Have patience.
Sent from my Moto G4 Plus using Tapatalk
vinylmeister said:
Great news. How many issues are left now? :highfive:
Seriously, i would really appreaciate it if it´ll be released and maintained sometime... :fingers-crossed:
Click to expand...
Click to collapse
+1
1chrome said:
He is courteous enough to give us status updates on what is happening and what he is currently fixing.
I dont think he would appreciate the ETA-ish question.
It will be released when he is done. Im sure he is not on this full time. Have patience.
Click to expand...
Click to collapse
Didn't you realize that the issue related sentence was just ironic? The high-five smiley should indicate that, followed by seriously...
vinylmeister said:
Didn't you realize that the issue related sentence was just ironic? The high-five smiley should indicate that, followed by seriously...
Click to expand...
Click to collapse
Sorry man my bad... smileys didn't show up on my Tapatalk!
Sent from my Moto G4 Plus using Tapatalk
Vorbis decoder and camcorder are still open.
I'd love to have a fully working Omni build up by now, but time-wise this is a best-effort activity.
It is ready when it's done.
golden-guy said:
Vorbis decoder and camcorder are still open.
I'd love to have a fully working Omni build up by now, but time-wise this is a best-effort activity.
It is ready when it's done.
Click to expand...
Click to collapse
Could you grab fresh logs after trying to record a video ? Can't find traces in current logs.
Also, did you try with different camera apps ?
vache said:
Could you grab fresh logs after trying to record a video ? Can't find traces in current logs.
Also, did you try with different camera apps ?
Click to expand...
Click to collapse
I tried with Snap and SnapDragonCamera. I wanted to do that with a fresh build. After having synched sources, mm-camera daemon keeps crashing and causing bootloops. Omni has updated their manifest to r14, also, lineage seems to have merged in fresh caf sources causing issues with qcom blobs. If I had known that earlier, I wouldn't have synched anew.
I see u uploaded to afh is it ready for testing I'm excited
joeeboogz said:
I see u uploaded to afh is it ready for testing I'm excited
Click to expand...
Click to collapse
????!!
Good catch! ?
Yes, it's up for testing now: https://www.androidfilehost.com/?fid=457095661767137952
Please note that this is an early ALPHA build: Media playback (ogg/mp4) and camcorder are still broken. But apart from that it seems to work just fine.
Code:
#include <std_disclaimer.h>
/*
* Your warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
*/
Remarks:
This thread is thought to collect issues and ideas. It has to be considered being a TESTING version.
Once everything is mature, an official build may be possible.
Installation:
If you are on stock OS, you need a custom recovery first. You can get the recommended Lineage recovery in the official installation instructions link below.
If you are coming from stock or other ROMs, you need to make a factory reset.
As always, make sure to backup before installing this ROM.
Also make sure you've got the correct firmware installed before installing LineageOS.
More detailed instructions at:
Install LineageOS on crackling
115ek's test builds (for testers only)
Downloads
Recommended Google Apps package:
none: GApps don't fit at the moment. A repartitioning is needed. Currently thinking about this...
Donate to support development:
Donate via PayPal to LineageOS
Changelog
06.12.2021
updated lineage sources
11.09.2021
fixed livedisplay
updated lineage sources
22.07.2021
initial version
reserved
It's been a while since I tried 18 and I'm tempted to look at the latest. Before I do, are there any major problems other than gapps. I appreciate it needs to be tested but I'd like to be aware if there are any major parts not working.
petexd said:
It's been a while since I tried 18 and I'm tempted to look at the latest. Before I do, are there any major problems other than gapps. I appreciate it needs to be tested but I'd like to be aware if there are any major parts not working.
Click to expand...
Click to collapse
Livedisplay is not working at the moment.
I had to remove it because it wouldn't load my photos and I didn't have time to play around with it. It's actually my only phone. It did, however, instal basic flamegapps.
I also got error 255 when tryin to restore my backup but I'm up and running now with 17.1. I'll try 18.1 again soon when I have more time to mess around with it and if I can sort out error 255
Very cool, thanks! What is the upstreaming status? That would be great as microG builds would be available automatically as well. That one I'd install right away.
ajjin0 said:
Very cool, thanks! What is the upstreaming status? That would be great as microG builds would be available automatically as well. That one I'd install right away.
Click to expand...
Click to collapse
I've got so less time at the moment. I hope I'll find some to continue the work.
New build is up. Livedisplay is working now.
Download
Wow great work.
@115ek Thank you for the new build.
I tried to compile Lineage18.1 myself, but ended up in a boot loop. I assume this is the relevant part of the log, since it repeats over and over again:
Spoiler
Code:
01-01 21:28:58.399 4357 4357 I [email protected]: LiveDisplay HAL service is starting.
01-01 21:28:58.404 4357 4357 D DISP_API: disp_api_get_num_display_modes.
01-01 21:28:58.458 4357 4357 D DISP_API: disp_api_get_num_display_modes successful getting num-of-modes = 6.
01-01 21:28:58.458 4357 4357 D DISP_API: disp_api_get_num_display_modes.
01-01 21:28:58.510 4357 4357 D DISP_API: disp_api_get_num_display_modes successful getting num-of-modes = 6.
01-01 21:28:58.512 220 220 I hwservicemanager: getTransport: Cannot find entry [email protected]::IDisplayModes/default in either framework or device manifest.
01-01 21:28:58.512 4357 4357 E HidlServiceManagement: Service [email protected]::IDisplayModes/default must be in VINTF manifest in order to register/get.
01-01 21:28:58.513 4357 4357 E [email protected]: Could not register service for LiveDisplay HAL DisplayModes Iface (-2147483648)
01-01 21:28:58.514 4357 4357 E [email protected]: LiveDisplay HAL service is shutting down.
01-01 21:28:58.521 0 0 I init : Service 'vendor.livedisplay-hal-2-0-legacymm' (pid 4357) exited with status 1
01-01 21:28:58.521 0 0 I init : Sending signal 9 to service 'vendor.livedisplay-hal-2-0-legacymm' (pid 4357) process group...
01-01 21:28:58.521 0 0 I libprocessgroup: Successfully killed process cgroup uid 1000 pid 4357 in 0ms
01-01 21:28:59.391 219 219 I servicemanager: Since 'android.hardware.power.IPower/default' could not be found, trying to start it as a lazy AIDL service
01-01 21:28:59.391 4193 4193 W ServiceManager: Waited one second for android.hardware.power.IPower/default
01-01 21:28:59.393 219 4360 W libc : Unable to set property "ctl.interface_start" to "aidl/android.hardware.power.IPower/default": error code: 0x20
01-01 21:28:59.395 0 0 E init : Control message: Could not find 'aidl/android.hardware.power.IPower/default' for ctl.interface_start from pid: 219 (/system/bin/servicemanager)
01-01 21:29:00.392 219 219 I servicemanager: Since 'android.hardware.power.IPower/default' could not be found, trying to start it as a lazy AIDL service
01-01 21:29:00.392 4193 4193 W ServiceManager: Waited one second for android.hardware.power.IPower/default
My local manifest looks like:
Code:
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<project name="115ek/android_device_wileyfox_crackling" path="device/wileyfox/crackling" remote="github" />
<project name="115ek/android_device_cyanogen_msm8916-common" path="device/cyanogen/msm8916-common" remote="github" />
<project name="115ek/proprietary_vendor_wileyfox" path="vendor/wileyfox" remote="github" />
<project name="LineageOS/android_kernel_cyanogen_msm8916" path="kernel/cyanogen/msm8916" revision="lineage-17.1" />
<project name="LineageOS/android_hardware_sony_timekeep" path="hardware/sony/timekeep" remote="github" />
</manifest>
Does your manifest look the same? Are there any additional patches I have to apply to get it working? I would highly appreciate it if you could share your steps to build LineageOS 18.1.
mmustermann717 said:
Does your manifest look the same?
Click to expand...
Click to collapse
This should be fine, yes.
mmustermann717 said:
Are there any additional patches I have to apply to get it working?
Click to expand...
Click to collapse
Yes. I still have some local changes I didn't push yet. There are two kernel patches required for enforcing SE linux which I didn't upload yet.
But permissive mode should work. You can switch to permissive for now by:
adding androidboot.selinux=permissive to https://github.com/115ek/android_de...7d4427d6896080f77946/BoardConfigCommon.mk#L94
The thing you see in the log is the broken livedisplay. I also have a local unpublished change here:
Code:
--- a/manifest.xml
+++ b/manifest.xml
@@ -184,6 +184,10 @@
<name>IDisplayColorCalibration</name>
<instance>default</instance>
</interface>
+ <interface>
+ <name>IDisplayModes</name>
+ <instance>default</instance>
+ </interface>
<interface>
<name>IPictureAdjustment</name>
<instance>default</instance>
You can try it that way. But in any case I should publish those changes. I just need to find some spare minutes to write a proper commit message and clean things up.
115ek said:
This should be fine, yes.
Yes. I still have some local changes I didn't push yet. There are two kernel patches required for enforcing SE linux which I didn't upload yet.
But permissive mode should work. You can switch to permissive for now by:
adding androidboot.selinux=permissive to https://github.com/115ek/android_de...7d4427d6896080f77946/BoardConfigCommon.mk#L94
The thing you see in the log is the broken livedisplay. I also have a local unpublished change here:
Code:
--- a/manifest.xml
+++ b/manifest.xml
@@ -184,6 +184,10 @@
<name>IDisplayColorCalibration</name>
<instance>default</instance>
</interface>
+ <interface>
+ <name>IDisplayModes</name>
+ <instance>default</instance>
+ </interface>
<interface>
<name>IPictureAdjustment</name>
<instance>default</instance>
You can try it that way. But in any case I should publish those changes. I just need to find some spare minutes to write a proper commit message and clean things up.
Click to expand...
Click to collapse
Thank you very much! That worked.
I increased the system partition, a little while ago and backups were restoring OK so I've decided to try 18.1 again.
I must say, it performs really well for the stuff I need. I also like that I can now do calendar etc backups to my sdcard. Much more sensible IMO.
Thanks 115ek. A great job.
I'd like to have a go at building but I'm not sure where to start without the explicit menu like 17.1
Thanks to 115ek for the 18.1 set up and to mmustermann717 for his local manifest. I have managed to build 18.1 after a few errors which appeared to be out of memory problems.
I fixed that and was able to complete the build.
Thanks both of you
I was too quick to brag. Im getting a boot loop. I made the changes from 115ek's response #12, so I don't know where I've gone wrong.
Can either of you tell me please?
115ek said:
This should be fine, yes.
Yes. I still have some local changes I didn't push yet. There are two kernel patches required for enforcing SE linux which I didn't upload yet.
But permissive mode should work. You can switch to permissive for now by:
adding androidboot.selinux=permissive to https://github.com/115ek/android_de...7d4427d6896080f77946/BoardConfigCommon.mk#L94
The thing you see in the log is the broken livedisplay. I also have a local unpublished change here:
Code:
--- a/manifest.xml
+++ b/manifest.xml
@@ -184,6 +184,10 @@
<name>IDisplayColorCalibration</name>
<instance>default</instance>
</interface>
+ <interface>
+ <name>IDisplayModes</name>
+ <instance>default</instance>
+ </interface>
<interface>
<name>IPictureAdjustment</name>
<instance>default</instance>
You can try it that way. But in any case I should publish those changes. I just need to find some spare minutes to write a proper commit message and clean things up.
Click to expand...
Click to collapse
I've tried all of this several times. I get a successful build but a boot loop every time.
The lineage source says successful, it doesn't actually boot so I have no idea how to find any error? Is there anything I can look for? Or can you guess?
I'd appreciate the help if you can. Thanks.
Hey
petexd said:
how to find any error?
Click to expand...
Click to collapse
The best way would be attaching some cables to get a console over UART. However, this requires some hardware knowledge and most likely some soldering. I haven't had a look into the crackling hardware yet.
Then you could use the android logcat command. Unfortunately adb has to work for that.
A third option could be "loggy", a simple script writing the logs to a defined location. Have a look here.
petexd said:
Or can you guess?
Click to expand...
Click to collapse
You could, but I'm not sure if that really helps.
petexd said:
Is there anything I can look for?
Click to expand...
Click to collapse
What does this line looks like (exactly!) in your sources? Could you post it here?
I'd try to use a known to be working boot.img - you could extract one from my latest 18.1 upload. That way you could exclude some potential problems.
115ek said:
Hey
The best way would be attaching some cables to get a console over UART. However, this requires some hardware knowledge and most likely some soldering. I haven't had a look into the crackling hardware yet.
Then you could use the android logcat command. Unfortunately adb has to work for that.
A third option could be "loggy", a simple script writing the logs to a defined location. Have a look here.
You could, but I'm not sure if that really helps.
What does this line looks like (exactly!) in your sources? Could you post it here?
I'd try to use a known to be working boot.img - you could extract one from my latest 18.1 upload. That way you could exclude some potential problems.
Click to expand...
Click to collapse
This is the line you asked about:
BOARD_KERNEL_CMDLINE := console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom ehci-hcd.park=3 androidboot.bootdevice=7824900.sdhci lpm_levels.sleep_disabled=1 loop.max_part=7 androidboot.selinux=permissive
I've tried my build with your boot.img but it still bootloops.
115ek said:
Hey
The best way would be attaching some cables to get a console over UART. However, this requires some hardware knowledge and most likely some soldering. I haven't had a look into the crackling hardware yet.
Then you could use the android logcat command. Unfortunately adb has to work for that.
A third option could be "loggy", a simple script writing the logs to a defined location. Have a look here.
You could, but I'm not sure if that really helps.
What does this line looks like (exactly!) in your sources? Could you post it here?
I'd try to use a known to be working boot.img - you could extract one from my latest 18.1 upload. That way you could exclude some potential problems.
Click to expand...
Click to collapse
I've tried again and the last 4 lines of the build are:
2021-10-18 16:11:33 - ota_from_target_files.py - INFO : done.
Warning: could not find RADIO/filesmap in <zipfile.ZipFile object at 0x7f982df1bf50>.
Warning: could not find RADIO/filesmap in <zipfile.ZipFile object at 0x7f982df1bf50>.
Compressing system.new.dat with brotli
warning radio-update: no radio image in input target_files; not flashing radio
[100% 24/24] build bacon
Package Complete: out/target/product/crackling/lineage-18.1-20211018-UNOFFICIAL-crackling.zip
#### build completed successfully
Is this OK? I thought bacon was another phone (oneplus?)
Hey
115ek said:
The best way would be attaching some cables to get a console over UART. However, this requires some hardware knowledge and most likely some soldering. I haven't had a look into the crackling hardware yet.
Then you could use the android logcat command. Unfortunately adb has to work for that.
A third option could be "loggy", a simple script writing the logs to a defined location. Have a look here.
You could, but I'm not sure if that really helps.
What does this line looks like (exactly!) in your sources? Could you post it here?
I'd try to use a known to be working boot.img - you could extract one from my latest 18.1 upload. That way you could exclude some potential problems.
Click to expand...
Click to collapse
I get this , just bfore the build completes successfully. Do you know if this has anything to do with the problem.
99% 463/464] Package OTA: out/target/product/crackling/lineage_crackling-ota-eng.pet
2021-10-19 18:02:26 - common.py - WARNING : Failed to read SYSTEM/etc/build.prop
2021-10-19 18:02:26 - common.py - WARNING : Failed to read VENDOR/etc/build.prop
2021-10-19 18:02:26 - common.py - WARNING : Failed to read VENDOR/build.prop
2021-10-19 18:02:26 - common.py - WARNING : Failed to read PRODUCT/etc/build.prop
2021-10-19 18:02:26 - common.py - WARNING : Failed to read PRODUCT/build.prop
2021-10-19 18:02:26 - common.py - WARNING : Failed to read SYSTEM_EXT/etc/build.prop
2021-10-19 18:02:26 - common.py - WARNING : Failed to read SYSTEM_EXT/build.prop
2021-10-19 18:02:26 - common.py - WARNING : Failed to read ODM/etc/build.prop
2021-10-19 18:02:26 - common.py - WARNING : Failed to read ODM/build.prop
Central project page
[EOL][SODP][ROM][AOSP][XZ2, XZ2C, XZ3] SonyAOSP 12.1 [Alpha]
The Sony Open Devices Project is always happy about volunteers (coding, testing, etc) :) Also mainlining your favorite snapdragon powered xperia device into the mainline kernel is possible and we will be glad to help you! Official site...
forum.xda-developers.com
09.02.2022
android-12.0.0_r28 (February security patchlevel)
OEMv1c support
Click to expand...
Click to collapse
14.02.2022
hotfix for the bootloop
Click to expand...
Click to collapse
30.03.2022
android-12.1.0_r1 (March security patchlevel)
Click to expand...
Click to collapse
MartinX3 said:
30.03.2022
Click to expand...
Click to collapse
a question why you don't upload photos of the user interface, and what options are available, I currently have the Xperia XZ2 Compact, and I'm thinking of changing the rom for this one based on Android 12.1
Carljaynp03 said:
a question why you don't upload photos of the user interface, and what options are available, I currently have the Xperia XZ2 Compact, and I'm thinking of changing the rom for this one based on Android 12.1
Click to expand...
Click to collapse
It's 90% aosp.
Please report any bug in the linked issue tracker.
MartinX3 said:
It's 90% aosp.
Please report any bug in the linked issue tracker.
Click to expand...
Click to collapse
any direct contact number for more information I am new in the world of custom roms, I want help, I can contribute with the work done please
Carljaynp03 said:
any direct contact number for more information I am new in the world of custom roms, I want help, I can contribute with the work done please
Click to expand...
Click to collapse
Thank you, please follow the link in the first post.
There it is also in the first post.
12.04.2022
android-12.1.0_r3 (April security patchlevel)
Click to expand...
Click to collapse
Bug....the touch does not work and it seems to reboot intermittently
Mint rhfo said:
Bug....the touch does not work and it seems to reboot intermittently
Click to expand...
Click to collapse
Bug....report?
MartinX3 said:
Bug....report?
Click to expand...
Click to collapse
Yeah! It's Bug report!
Mint rhfo said:
Yeah! It's Bug report!
Click to expand...
Click to collapse
I don't see a valid bug report according to the instructions.
Or you claim that I'm god and know everything.
But maybe I'm god, who knows.
Hello,
Android Custom Rom noob here. Just picked up a XPERIA zx2 Compact and wanted to use this guide to flash a more current Android on the phone (came with Android10).
I followed some guides and was able to unlock my bootloader and enable USB Debugging. I used adb platform tools to boot the device in fastboot mode and flashed the files as described in the instructions.
Errors encountered:
fastboot flash oem _a SW_binaries_for_Xperia_Android_12_4.19_v1c_tama.img
fastboot: error: cannot load '_a': No such file or directory
I changed the command to: fastboot flash oem_a SW_binaries_for_Xperia_Android_12_4.19_v1c_tama.img
Sadly, the device reboots after a few seconds showing the sony logo. Reboots about three times and then says corrupted image, then shuts down. What am I doing wrong?
Thanks for your help guys!
BigWoodFarmer said:
Hello,
Android Custom Rom noob here. Just picked up a XPERIA zx2 Compact and wanted to use this guide to flash a more current Android on the phone (came with Android10).
I followed some guides and was able to unlock my bootloader and enable USB Debugging. I used adb platform tools to boot the device in fastboot mode and flashed the files as described in the instructions.
Errors encountered:
fastboot flash oem _a SW_binaries_for_Xperia_Android_12_4.19_v1c_tama.img
fastboot: error: cannot load '_a': No such file or directory
I changed the command to: fastboot flash oem_a SW_binaries_for_Xperia_Android_12_4.19_v1c_tama.img
Sadly, the device reboots after a few seconds showing the sony logo. Reboots about three times and then says corrupted image, then shuts down. What am I doing wrong?
Thanks for your help guys!
Click to expand...
Click to collapse
Hey,
I'm sorry and fixed the type.
There was a wrong whitespace character in the manual.
It's `oem_a`, that's correct.
Did you flash everything and wiped the userdata before?
Because other XZ2C owners were able to post logs.
Also it is mandatory to run the latest stock firmware on both slots once before in the lifetime of your phone.
Hi,
Thank you for your fast reply. I flashed everything and wiped as described with "fastboot -w"
I am unsure what you mean by both slots, you mean Firmware and Software Content Erase? I used EMMA to flash: H8324 52.1.A.0.618 Customized_UK 1313-5469 R3C User-Live COM on the device.
Some other questions I had:
a) Do I need Magisk for root on the device?
b) can I use another Version the twrp 3.4.0.0.? If I install this to my recovery partition, I can't use it when booting since the screen seems frozen.
sry for asking some dumb questions in my last post. I was now able to install this Android 12 Version. I think the problem was, that i didn't wipe the device before the deployment.
Thanks again for all your work on this.
*EDIT*
Can you suggest a twrp version I should use? I cannot start 3.4-0-0 (2020-06-14_21-07-37) anymore using fastboot boot
**EDIT #2**
I received the following error: "there is an internal problem with your device, contact manufacturer". I will attach output of logcat -b all
BigWoodFarmer said:
sry for asking some dumb questions in my last post. I was now able to install this Android 12 Version. I think the problem was, that i didn't wipe the device before the deployment.
Thanks again for all your work on this.
*EDIT*
Can you suggest a twrp version I should use? I cannot start 3.4-0-0 (2020-06-14_21-07-37) anymore using fastboot boot
**EDIT #2**
I received the following error: "there is an internal problem with your device, contact manufacturer". I will attach output of logcat -b all
Click to expand...
Click to collapse
Nice that you achieve to flash it.
The camera is currently not implemented because of the russian invasion in the ukraine.
Code:
04-12 19:02:48.363 0 0 I init : starting service 'vendor.camera-provider-2-4'...
04-12 19:02:48.451 3114 3114 I [email protected]: [email protected] legacy service is starting.
04-12 19:02:48.452 3114 3114 D ProcessState: Binder ioctl to enable oneway spam detection failed: Invalid argument
04-12 19:02:48.453 3114 3114 D hw-ProcessState: Binder ioctl to enable oneway spam detection failed: Invalid argument
04-12 19:02:48.452 0 0 I binder : 3114:3114 ioctl 40046210 7ff5fbfc44 returned -22
04-12 19:02:48.453 0 0 I binder : 3114:3114 ioctl 40046210 7ff5fbfc24 returned -22
04-12 19:02:48.489 3114 3114 E [email protected]: Could not load camera HAL module: -2 (No such file or directory)
04-12 19:02:48.489 3114 3114 E [email protected]_64: getProviderImpl: camera provider init failed!
04-12 19:02:48.490 3114 3114 D RefBase : RefBase: Explicit destruction, weak count = 0 (in 0xb400007a624ceaa0)
04-12 19:02:48.491 3114 3114 W RefBase : CallStack::getCurrentInternal not linked, returning null
04-12 19:02:48.491 3114 3114 W RefBase : CallStack::logStackInternal not linked
04-12 19:02:48.492 3114 3114 E HidlServiceManagement: Could not find instance 'legacy/0' in library [email protected] Keeping library open.
04-12 19:02:48.493 3114 3114 E LegacySupport: Could not get passthrough implementation for [email protected]::ICameraProvider/legacy/0.
04-12 19:02:48.501 0 0 I init : Service 'vendor.camera-provider-2-4' (pid 3114) exited with status 1
04-12 19:02:48.501 0 0 I init : Sending signal 9 to service 'vendor.camera-provider-2-4' (pid 3114) process group...
04-12 19:02:48.501 0 0 I libprocessgroup: Successfully killed process cgroup uid 1047 pid 3114 in 0ms
04-12 19:02:48.504 0 0 E init : process with updatable components 'vendor.camera-provider-2-4' exited 4 times in 4 minutes
04-12 19:02:48.513 0 0 I init : processing action (sys.init.updatable_crashing=1) from (/system/etc/init/flags_health_check.rc:10)
04-12 19:02:48.514 0 0 I init : starting service 'exec 29 (/system/bin/flags_health_check UPDATABLE_CRASHING)'...
04-12 19:02:48.541 0 0 I init : SVC_EXEC service 'exec 29 (/system/bin/flags_health_check UPDATABLE_CRASHING)' pid 3115 (uid 1000 gid 1000+0 context default) started; waiting...
04-12 19:02:48.564 3115 3115 I flags_health_check: ServerConfigurableFlagsReset reset_mode value: 1
04-12 19:02:48.565 3115 3115 I flags_health_check: ServerConfigurableFlagsReset updatable crashing detected, resetting flags.
Please subscribe to
[Tama][XZ2C][AOSP12][4.19] Apollo camera provider init failed (every 5secs) · Issue #751 · sonyxperiadev/bug_tracker
Platform: Tama Device: XZ2C (apollo) Kernel version: 4.19.188-ge73c1a837c4f-dirty Android version: AOSP12 Software binaries version: 12_4.19_v1c_tama Previously working on n/a (latest official Sony...
github.com
[Tama][4.19][AOSP12] Device reboots for no clear reason any time it is not idle · Issue #755 · sonyxperiadev/bug_tracker
Platform: Tama Device: Apollo Kernel version: 4.19 Android version: AOSP12 Software binaries version: 12_4.19_v1c_tama Previously working on n/a Description The device reboots after a few minutes o...
github.com
[TAMA][12][4.19] Bootloop · Issue #748 · sonyxperiadev/bug_tracker
Platform: Tama Device: Apollo Kernel version: 4.19 Android version: 12 Software binaries version: v1c Previously working on Stock Description Bootloop and no ADB logs available. The device was flas...
github.com
and firstly this will get fixed: https://github.com/sonyxperiadev/bug_tracker/issues/770
20.05.2022
android-12.1.0_r5 (May security patchlevel)
Click to expand...
Click to collapse
Because of problems with the ftp server the new release is on google drive.
Click to expand...
Click to collapse
Hello, what changes between this rom and the stock based roms ?