• Content count

  • Joined

  • Last visited

Community Reputation

3509 Excellent

About KonstaT

  • Rank
  • Birthday 11/02/82

Profile Information

  • Location Finland

Previous Fields

  • Your Current Device(s) Moto X, Huawei Y5, ZTE Open C
  • Your Twitter username konstatuomio

Recent Profile Visitors

11882 profile views
  1. No, it won't work on [place a name of random device here].
  2. Yeah, it's very possible that there's still various issues with telephony. There's network mode option in setting but I can't recall what the options are. Maybe you can force it to use 3G only? This device doesn't support 4G networks. IIRC there's some issues with mobile data on OnePlus One port ('fix' was to restart conmann or statefs, can't find the post atm) and it's said to be somewhat unreliable on Fairphone 2, too. If/when there's another build, it will have some ofono updates again. BTW, have you tested if wifi tethering works? I tested it with the build and it was working. Not sure if I tested it with the latest build (I'd add the info to https://wiki.merproject.org/wiki/Adaptations/libhybris and this would save me a flash). You're very brave to use this as daily driver (well, I could say the same thing about Firefox OS). I had this installed for about a week before moving on to other projects (this isn't my daily driver device, though). It didn't crash and burn which is always positive. :P Good to hear experience hasn't been too bad for you either. :)
  3. I've put any new projects on hold because of the lack of proper kernel source. Huawei still hasn't responded to the numerous emails I've sent them. Not even one of the generic 'thanks for contacting us, we'll look into this' bullsht responses companies usually send out! Also got in touch with 'Huawei and honor representative' over at XDA and he promised to forward my message. Tried to contact him again and now haven't heard back from him either. Apparently Huawei is just another Chinese company that doesn't give a sht about GPL. I thought ZTE was pretty bad and Huawei was supposed to be the more reputable one - apparently I was wrong. Sometime it could take a loooong time for ZTE to release a source code but never really had any problem with it once it was finally out. You'd have to be totally incompetent to release an incomplete source code like Huawei has done for this device. Customer support is equally non-excisting with both companies. :P I had other projects planned for this device, too (Firefox OS, Sailfish OS). Those are out of the question without a kernel source. CM13 is most likely doable with a prebuilt kernel but it gets somewhat hacky. Kernel would needs some updates for Marshmallow if you wanted to do it right (e.g. kernel need to be in line with display/media HALs). I haven't even started looking into CM13 for this device and I don't have any immediate plans to do so.
  4. I wrote a guide here how to create and change the splash screen.   
  5. How to create your own splash screen: 1. Create a 480x854 bitmap in e.g. GIMP image editor 2. Flip image vertically 3. Save as 24-bit Windows bitmap (RGB888) 4. Cut 54 bytes from the header - splash.img should be 1229760 bytes in size dd if=splash.bmp of=splash.img skip=54 bs=1 5. Place splash.img inside the flashable zip below (drag&drop with your favorite zip tool) and install the zip in TWRP recovery How to restore stock splash screen: 1. Install the zip below in TWRP recovery splash-stock-y560.zip http://www.mediafire.com/?ifcfs1qpc0ril46 md5:038563ed5f404d7589ecbb02ea8112aa
  6. New build. This is the first build with SELinux enforcing and it's always possible that I've missed few denials. If something is broken that was working in previous builds, please attach logs (logcat/dmesg) and provide steps how to reproduce your issue. I'd appreciate if someone could confirm that ambient light/proximity sensor is still working as I can't test that on my Open C. Also switched to CM's new Snap camera app which is still under development. There's at least one minor quirk. It shows both internal and external sdcards as storage options (only primary external sdcard is supported in my builds). You actually need to select internal sdcard (or not touch that option at all) for it to work. cm-13.0-20160207-UNOFFICIAL-KonstaKANG-kis3.zip http://www.mediafire.com/?nhncweeg21a65ih md5:c2ef61bfcb516f6a6685b8def5a86e36 -SELinux enforcing -switch to Snap camera app -Android security patch level: 1 February 2016 (merged)
  7. Root exploits, building a custom recovery, etc. Shouldn't be even very difficult if it's affected by the read only properties backdoor that was in the news last week. http://gadgets.ndtv.com/mobiles/news/software-bug-leaves-several-mediatek-powered-android-devices-vulnerable-to-attack-795743 Not a discussion that belongs to this thread, though.
  8. 64 Bit kernel compiling

    It's the ARMv7->ARMv8 leap (and new instructions and improvements it brings) that's more significant than something being 32-bit or 64-bit. Kernel source should be just fine. Basically you could build it for any architecture with the right toolchain to cross compile. There's no specific 64-bit kernel source. E.g. Alcatel msm8939/msm8916 devices use the same kernel source, Idol 3 5.5" builds 64-bit - Idol 3 4.7" builds 32-bit. You can compare that defconfig to the one with the same name in arm/configs and see the changes. It might help you generate an arm64 defconfig for your device, that's all. Like said, you're still missing the 64-bit device specific proprietary binary drivers for Android. Bootloader might be an even bigger issue.
  9. 64 Bit kernel compiling

    I meant that you can find a 32-bit build on pretty much any ROM (or you can build one yourself when the source code is available). It's not true that you can only port ROMs if the chipsets are the same either - it's architecture that matters. E.g. Android SDK emulator image usually gets ported to few devices when new major Android version is released (there's generic arm and x86 images available).  Well, I'm not the person you should be asking about winzip porting and I've already stated my opinion that I don't consider it worthwhile. :P
  10. 64 Bit kernel compiling

    I just can't understand your reasons. There's little to gain what comes to performance. That's totally irrelevant when your main concern is to still have all the hardware working. Bootloader might play some role in this too and it might not even be possible to boot 64-bit kernel in the first place. I'm sure there's plenty of 32-bit MIUI7 builds (and MIUI patchROM) so there's no reason why you would need to port it from Mi4i. There's not a single ROM in the world you'd need a 64-bit kernel for. Let me know if you get this done, I'd be interested to know. I'm quite sure you'd be the first in the world to do this. :)
  11. 64 Bit kernel compiling

    And why would anyone want a horrible closed source OEM skin?! That's the first thing people usually want to get rid off. And I'm sure Coolpad, Meizu and Oppo have released plenty 32-bit builds you can winzip all you want. You don't necessarily need to 'port' ROMs from YU Yureka (or whatever), you know... I'm past my winzip'ing days and I don't find this even remotely interesting. Good luck with your effort anyway.
  12. 64 Bit kernel compiling

    Vast majority of those ROMs is built from source (and more or less based on CyanogenMod) and there's nothing stopping you from building those ROMs in 32-bit. You're still missing the 64-bit proprietary blobs for this device. Do you know devices where this has been done before? I'm not aware of any. Quite a few vendors (e.g. Motorola, Alcatel) ship 32-bit builds on their msm8916/msm8939 devices. Are building the kernel standalone or as a part of a CM build? Check BoardConfig.mk on some 64-bit device (e.g. that yu tomato) and see what flags you need to change for 64-bit kernel build.
  13. 64 Bit kernel compiling

    Sorry, I don't see the point in wasting effort on this. Sure, as a proof of concept but you're not going to see any real world benefits. Running 64-bit kernel and 32-bit userspace is possible AFAIK, but I'd expect you to run into all kinds of trouble with this. 32-bit kernel doesn't prevent you from porting any ROM in the world either (=building from source - you shouldn't use 'winzip' to do it anyway). In any case, you'll still be missing 64-bit device specific proprietary binary drivers because ZTE has never released a 64-bit Android build for this device. Simply copying defconfig to another directory doesn't make it arm64 compatible. You need to change quite a few options for that (CONFIG_ARM -> CONFIG_ARM64, and so on). Might be easier to start with the generic defconfig where ZTE has made their changes (one of the msm8916_defconfig ones) and let menuconfig generate it for arm64.
  14. [Recovery] TWRP

    Are you asking me? I don't have a device so there's nothing I can do. There's a CM12.1 build available at XDA but I have no idea how usable it is as a daily driver. There was also another earlier CM build by some Russian guy who asked money for it. You needed to pay for 'premium' version if you wanted a build with basic things like wifi working. What an absolute disgrace!
  15. No, nothing you find here will work on that device. It has completely different hardware (MediaTek chipset vs. Qualcomm chipset in this one). You better stay far away from MediaTek devices if you're interested in using AOSP based ROMs (e.g. CyanogenMod, etc).

MoDaCo is part of the MoDaCo.network, © Paul O'Brien 2002-2016. MoDaCo uses IntelliTxt technology.