KonstaT

Members
  • Content count

    3486
  • Joined

  • Last visited

Community Reputation

3507 Excellent

About KonstaT

  • Rank
    Hardcore
  • 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

11634 profile views
  1. I wrote a guide here how to create and change the splash screen.   
  2. 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
  3. 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)
  4. 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.
  5. 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.
  6. 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
  7. 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. :)
  8. 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.
  9. 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.
  10. 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.
  11. [Recovery] TWRP 2.8.7.0

    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!
  12. 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).
  13. You're missing the fact that you have a completely wrong device...
  14. I've already answered this a dozen times and you already know what the answer is!
  15. No, you need to use the exact CM12.1 build posted in the OP. No plans on making Sailfish based on KitKat though that would be possible. AFAIK Sailfish OS is also still missing UI for dual-SIM feature so it wouldn't help much even if it was working on Android side.

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