Puzzled with all the buzzwords and your head is spinning?
Still want to learn a little about the strange world of Chefs and cooking?
Even are tempted to ask some questions but have not dared yet with all the geeks around here?
Here is a little nutshell-guide for you to lift you up:
The windows mobile operating system is composed of several parts (and this in several regards not always aligning) and it is helpful to understand the basic architecture to evaluate your problem against that.
This is not a detailed guide, it will not link to any sophisticated tools and it will not solve your problems right away. I just try to supply a little nutshell approach (simplifying some things - don't flame me for this if you know better) to put things in the right order.
After reading (and understanding) you are hopefully enabled to search for the right answers in the vast pool of wisdom around the web. You should also be able to tell apart the tales from the facts (on some level at least) and - if you need - ask the right questions and not immediately be ignored as a noob.
You see below a map that allows you to locate the various terms to the right places.
I will then elaborate a little on each of these in hierarchical order.
Code:
ROM file (usually packed into an update service pack containing also the update SW)
Parts:
- IPL
- SPL
- OS
partitions:
- USPL
- XIP
- Generic(MS) and OEM parts -> XIP porting
- packages (*.dsm + *.rgu)
- files and modules
- IMGFS
- Generic(MS) and OEM parts -> the usual ROM Cooking is here
- packages (*.dsm + *.rgu)
- files and modules
- languages
- T9
- *.mui.*
- *.provxml + lang_db
- ExtROM
- GSM/Radio
- Boot-Splash
ROM parts and Partitions:
Let us first look at the flash memory of the device. This is handled from the SPL (secondary program loader) during boot (passing control to the OS) and flashing where the different parts that are present in a ROM file will be written to the places of flash memory of the device.
The well known parts of a flash ROM are:
the IPL (Initial Program loader),
the SPL (secondary Program Loader) - a powerful on-board pre-OS program that is the gate-keeper for all further actions
the OS (Operating System),
the Radio (GSM),
the initial boot-splash
and others like ExtROM which is just a FAT partition for storing post-first-boot configuration and installation programs - depending on the device.
There are some more parts in the device memory for security reasons that hold the IMEI, SIM-Lock data and possibly other data that can be used for forensic analysis.
Shipped (vendor or operator original) ROMs usually contain ALL parts of a ROM so that you do not depend on a previous ROM to get a usable device.
Interesting for cooking is only the OS part of the ROM.
This holds ALL parts that make the difference between the windows mobile OS versions. Some cooks have added their own splash screens as ROM parts (additional to the ones that are displayed when to OS boots later), for some ROM flashing it is also required to replace the SPL (temporary or permanently) allowing the flash of non-signed ROMs or at least make it believe that you are allowed to do that (Super-CID).
Sometimes it is useful to step up to the latest Radio version to exploit features that this offers.
But again: Cooking is only about the "OS" part of the ROM! Only the OS part is usually replaced by flashing new cooked ROMs.
This OS part is structured into "partitions". So you can look at the OS part as something like a hard-disk in your PC that can also have partitions with different file-systems serving different purposes. For the OS part of the ROM the sequence of partitions is the
ULDR (look that up yourself) which is usually not needed and can often be removed or minimized,
then the XIP (historically "eXecute In Place")
then the IMGFS (Image file-system)
and some additional partition, e.g. for the ExtROM.
XIP and IMGFS make up the Windows Mobile OS and are subject to "cooking".
XIP and IMGFS:
In the boot process the SPL passes control to the nk.exe (Native Kernel) in the XIP and it will load the early drivers and services that allow to reach a certain minimal OS service level to access the IMGFS for further boot.
The IMGFS itself holds all the rest of files and modules to start the OS to that level where the user can use it.
OEM and the rest:
The HW of most mobile devices is special in one or the other way. Dedicated drivers are needed to abstract the HW dependent parts to a level that the Operating system can interface with them in a standardized way. All these are summarized under "OEM parts" (Original Equipment Manufacturer) while all other parts are from Microsoft and are supplied in a generic way.
You can suspect that all OEM parts have to be compiled taking the HW specifics into account, while the generic parts can be taken as is (binary) and both will be assembled to a final ROM production.
This separation of OEM and "the rest" makes "cooking" and "porting" possible at all. If this architecture was not designed by Microsoft, then there was no cooking in the kitchen
OEM parts stay usually unchanged through all cooking and porting activities, so that also means that a WM5 device will keep all the OEM parts even if the OS version is WM6.5. OEM parts are in both, the XIP (nk.exe and some OEM modules) and the IMGFS. You will especially not gain any advantage of the enhanced memory allocation scheme if your device does not have a native 6.5 kernel (nk.exe).
OEM may also add applications to their devices that exploit special HW options of the device (e.g. the camera application) or that are the result of an effort to make their devices unique (like HTC's Homescreen).
Kitchen separate on top-level into SYS and OEM folders but the allocation of packages (see own chapter) to either one or the other is not uniform. Some add the OEM drivers (i.e. the true HW dependent parts) in the SYS folder, others (newer) kitchen put them also under the OEM top-level.
Packages and ROM Protection:
To keep the various parts of a ROM well organized, Microsoft has created an environment that allows to produce ROMs in an easy way. This is not accessible to us ROM hackers, but the remains of the packaging tools in the ready assembled original ROMs have inspired many hackers and chefs to utilise the same methods.
They created tools to de-compose original ROMs and also to use the same methods for creating new ROMs. Over time these tools have become very sophisticated and may even offer more options than original MS tools (I guess). As all this is a shared activity with many contributors, it is important (in my view) to keep sharing what you discover.
In original ROMs you find many files like <some-strange-number-letter-combo>.rgu and also <*>.dsm. These are the remains of the packaging process that has created the ROM. They are NOT needed on the device itself! However have those files allowed to understand the process of building a ROM.
These <some-strange-number-letter-combo> elements are called GUID (Globally Unique Identifier) and are identifying packages. The DSM (Device Side Manifest) file identifies all components of a package (their name, status, properties, size, build properties and much more) while the RGU (Registry Update?) file identifies the changes that are made to the standard registry hive for that package.
So ultimately one method of ROM "protection" that some kitchen offer and that some chefs are using is to remove all the *.dsm and *.rgu files before they build the IMGFS. The resulting ROMs still have all files that are needed for the ROM to run, but they cannot be decomposed to packages (the .dsm files are missing) again and during re-build the *.rgu files are missing to update a standard hive file (e.g. of a new base ROM from MS).
Files and Modules:
Logically the smallest parts are files, which is common to all operating systems. There is one specialty however in the WM-OS and this is so called "modules".
They are basically memory-fix located executable files which can be loaded faster than normal executable files. As their memory location is fixed in the production process, all those modules must not overlap their memory. The process of realigning a new set of modules to the available memory locations is called "re-location" or "re-allocation". Tools like mreloc, G'reloc, wmreloc, extreloc or within OSBuilder take care about this in the production process.
You recognize modules that they are folders in the kitchen with the name of the module and some files inside that make up their content. These modules later "look like" files in the \windows folder of your device but they are still modules which are just hidden from your visibility by the filesystem presenting the data to you.
Even worse for easy understanding is that you seem to be able to "overwrite" such files on your device later, but you do not actually overwrite them. You create a file with the same name in the FATFS that is linked to the IMGFS where the ROM is stored. The copied file takes precedence over the original one in ROM. This works for many files in ROM, but NOT for those who are loaded before the FATFS is active (e.g. after cold-boot the FATFS is empty or during early boot-phase when the XIP partition is loaded).
Languages in a ROM:
While it was usual in older times to have multi-language ROMs, this habit seems to vanish with newer devices and several vendors produce country specific ROMs only. However does Windows Mobile offer all options to have many languages present in a ROM. The places that need adjustment are multi-fold, however only some need real attention usually.
Luckily the country specific details of time/date/number/currency and alike are stored in a common database and are present in all devices no matter which user interface they have (afaik the nls file). Also the naming of the settings options (e.g. "Short Date Format") are present in all languages already. There is no need to adjust this usually.
The text entry system (T9 or its successors) is handled by a dedicated package and new languages can be added quite easily. The languages here are independent of the language settings for the UI, so you can have a device with only WWE (World Wide English) on the GUI but still have your local language supported e.g. for sending text messages. Mind that usually all language databases must be of the same (matching the T9 executables) version to work properly. You cannot pick an arbitrary language file from another T9 enabled device.
The programs or dll that are constructed to support multiple languages have in many cases <program/dll-name>.mui.<nnnn>.* files where the "mui" indicates "multilingual user interface" and the <nnnn> the relevant 4 digit number of your language (0409 is US English, 0407 is German and so on..). Usually there are dedicated packages in a ROM that supply all necessary changes to the registry so that this language is supported when you switch to it in the regional settings.
Applications that a chef has added to a ROM may need separate methods to add a language, most are not having an automated approach or are only supporting their own native language. You could still work on the binary file directly, either in a structured approach by de-composing the executable into its resources (e.g. with resource hacker) and add/change strings there or even directly hex-editing the file itself. Mind that you MUST NOT insert or delete any byte - you must OVERWRITE existing strings only. You also have to take care that on a smartphone with certificate security switched on you must remove the existing certificate (if any) and re-sign the file again.
The settings themselves are a special system of menus (*.cpl.xml) on a smartphone that manipulate registry data or other values of the device. For that purpose the settings are using the already existing "Service Provisioning" method that can as well be used via WAP or with other means.
To make that provisioning in some way a little user-friendly, there is a process to define names and options for changing such data - finally they are stored in a database on the device.
Now when you call the settings menu, the system reads the elements that shall be changed and also the linked information (label, limits, representation) from that database to present this on the screen.
So if you like to have more parameters in the settings menus or if you want to make your own panels for settings or tweaks, then you have to deal with adding your information to that database.
This is done with *.provxml files. These files are treated on the device (so not during cooking where the *.dsm and *.rgu files are used) and they are handled on different occasions (first/cold boot, sometimes also on other occasions). This is also why a "first boot" of a ROM is taking much longer then subsequent boots. So if you want to find out which additional settings-options are in your ROM, parse all *.provxml files for your country string (you remember "0409"?) and add relevant parts for the language you want to add.
This is tricky though: the files are stored in UTF-8 format without the UTF-8 header. If you save them in the wrong encoding they will not work any longer! I use the free notepad++ editor (http://notepad-plus-plus.org/) that handles them well.
The final part in this story are the settings panels themselves (usuall in the OEMMISC folder: *.cpl.xml). Also here some labels are defined in a language specific way - just add what you need per language following the obvious pattern that is given in the files already.
[*]Now that I see the above, I noticed that the smartphone homescreen is also an XML file - so also there the labels and options can be set in a language specific way. Look up the *.home.xml files if the language you want to deal with is present in these files. Usually the MS defined homescreens have very many languages already inside, so you may not need to change anything here. As mostly nobody cares about smartphones any longer and even less about old-style homescreens - this may have no need to be mentioned.
[*][added 2012 02 24]: Hardly documented (but widely used) and very useful is that the registry supplies an automatic NLS dependent branching of values. So if you have a value like HKxy\path1\path2\myvalue and you want to have two different data for it, each depending on the selection of the active interface language, then supply the value like:
HKxy\path1\path2\0409\myvalue=<English string>
Example (from SYS\Base_Lang_nn):
[HKEY_LOCAL_MACHINE\Comm\EAP\Extension\13\0409]
"FriendlyName"="Smart Card or Certificate"
HKxy\path1\path2\0407\myvalue=<German string>
Example (from SYS\Base_Lang_nn):
[HKEY_LOCAL_MACHINE\Comm\EAP\Extension\13\0407]
"FriendlyName"="Smartcard oder Sicherheitszertifikat"
Note that specialty cannot be seen when you access the registry with standard means (so via the device itself) later on anymore. You will just see the registry path of the current selected interface language. Tools that can read the created hives directly will show them.
Bottomline for dealing with languages:
know the number for your language and the one that is in a ROM
care for T9 libraries and make sure to use all of the same version
find the version matching *.mui.* files for the language to add
search all kinds of XML files (*.provxml, *.cpl.xml, *.home.xml) for the language number and make your changes
inspect the *.rgu of the language dependent packages and see if all items are set properly. Be inspired and create your own language dependent registry values.
When you move ahead in your strive to cook your own ROMs, you will notice that old style (batch file) kitchen give you control over what happens when as you are calling the dedicated tools for certain jobs directly.
Newer Kitchen have assimilated all work-flows in their own GUI, some still needing the tools that also the batch file kitchen use.
The latest breed of kitchen has most tasks built in. So you are completely left with the style that the master of that kitchen has implemented his understanding of work-flow logic. Sometimes it is hard to understand what belongs where (for a noob that you may be reading until here - it is hopeless anyway) - but as long as you understand the architecture you can have your own mind-map and put things together on your own.
If you like and have some old devices to play with, why not give it a start with any of my 3 kitchen for the good old Candy Bar smartphones which HTC had created?
WM65 (English/German) OS Builder Kitchen + ROMs for Typhoon based on Aleut's WM65 ROM
OS Builder Kitchen for Hurricane: WM6, WM6.1 and WM6.5 English + German
OS Builder Kitchen for Tornado: WM6, WM6.1 and WM6.5 English + German
You need to fix some battery stuff related to these old gems, look here:
[now without battery ] Replace Backup Battery in Tornado, Hurricane or Typhoon
mind that the cooked ROM from the kitchen above already contain the "without battery" part.
Measure and compare your battery capacity - easy, foolproof, comparable - any WM dev
If you like this tutorial and it has given you some more insight, please push the "Thanks" button at the bottom.
Nice post mate, this his all foundation in a nutshell-guide .
Thanks.
I agree, nice tut. No doubt, it will help many people!
I'be been reading all, wow, so detailed.
Nice job indeed, thank you.
Grtz,
Laurentius26
Great work. Simple and precise
added language dependent registry branches
Not many left who wish to cook anymore, so just to complete the language dependent items in my original post.
Hardly documented (but widely used) and very useful is that the registry supplies an automatic NLS dependent "branching" of values. So if you have a value like HKxy\path1\path2\myvalue and you want to have two different data for it, each depending on the selection of the active interface language, then supply the values like:
HKxy\path1\path2\0409\myvalue=<English string>
Example (from SYS\Base_Lang_nn):
[HKEY_LOCAL_MACHINE\Comm\EAP\Extension\13\0409]
"FriendlyName"="Smart Card or Certificate"
HKxy\path1\path2\0407\myvalue=<German string>
Example (from SYS\Base_Lang_nn):
[HKEY_LOCAL_MACHINE\Comm\EAP\Extension\13\0407]
"FriendlyName"="Smartcard oder Sicherheitszertifikat"
Note that specialty cannot be seen when you access the registry with standard means (so via the device itself) later on anymore. You will just see the registry path of the current selected interface language. Tools that can read the created hives directly will show them.
Hello there,
i would like to get informations about the communication of an app, as it is using a VERY big amount of bandwith. And I'm curious.. I want to understand the complete communication.
I tried mitmproxy but it seems, that it is using a hardcoded proxy internally. So i thought about a different approch:
Adding Logging to the app itself.
The App is using a stripped down version of the okhttp lib (github.com:square/okHttp), that contains (in versions 1.5.0 to 1.6.0) the Request class. The constructor seems to not be changed in the app.
github.com/square/okhttp/blob/parent-1.5.0/okhttp/src/main/java/com/squareup/okhttp/internal/http/Request.java
I would like to add logging capability to the constructor in th compiled .class . Something like
Log.d("AppTarget",url.getProtocol()+"://"+url.getHost()+":"+url.getPort()+url.getPath()+" "+method);
at the end of the constructor.
1) Is this a good idea? (Or are there better ways? )
2) How to do this? Of course: I have to edit the bytecode. But more like: how to do this.
3) I have attached a compiled version of the lib
A wonderfull day
Mimoja
Well decompiling the app, adding the logging lines and recompiling wont work i suppose, because apktool etc dont return working code.
If you have another rooted android phone by chance, you should try intercepter-ng app found here on xda, works great as mitm tool to get other wifi device's traffic
--------------------
Phone: Nexus 4
OS: rooted Lollipop LRX21T
Bootloader: unlocked
stock Recovery
Androidx86 & Forks using custom kernelsfor UEFI Windows tablets
Android 6.0 Marshmallow [Stock Download] [Source]
Android 4.4.4 KitKat [As above]
RemixOS 2.0 (Android 5.1.1) [Stock Download] [Source]
PheonixOS 1.0.3 (Android 5.1.1) [Stock Download]
Custom Kernels Included
Cube i7_Stylus
kernel device_tree
Android 6.0 MM -- post @Wootever
Android 4.4.4 KK -- post [Additional Files] @Wootever
RemixOS 2.0 -- post @asplash
PhoenixOS 1.0.3 -- post
Kernels -- located here
Hacks-Scripts-Tools
Hacks and workarounds that can be used to overcome reported issues. These will be primarily bash scripts; hopefully these can be included in the source code in some way if useful/needed.
Scripts
General scripts - use an app to launch them at boot; or make use of /etc/init.shSleep mode [effectiveness will depend on what sleep modes your device/kernel has access to (`dmesg | grep ACPI`); and will need to be modified if your screen brightness is reported elsewhere]
Code:
watch -n 60 '[ "`cat /sys/class/drm/card0/card0-eDP-1/intel_backlight/actual_brightness`" = "0" ] && echo "mem" > /sys/power/state' &
Which watches the brightness level every minute and if it's zero then puts the device into S3 sleep.
This can be modified in cases where specific modules don't comeback after sleep like the following for a rotation sensor
Code:
watch -n 60 '[ "`cat /sys/class/drm/card0/card0-eDP-1/intel_backlight/actual_brightness`" = "0" ] && setprop ro.sleep 1 && echo "mem" > /sys/power/state' &
watch -n 60 '[ "`getprop ro.sleep`" = "1" ] && [ "`cat /sys/class/drm/card0/card0-eDP-1/intel_backlight/actual_brightness`" != "0" ] && setprop ro.sleep 0 && am force-stop com.android.launcher3 && rmmod kxcjk_1013 && modprobe kxcjk_1013' &
Which restarts the kxcjk_1013 module and restarts the launcher on wakeup
Build.prop edits RemixOS
ro.remixos.box=true
changing this value to false opens up more options in settings/taskbar and is preferable on tablets
ro.remixos.no_wallpaper=true
changing this to false will let you have a wallpaper if you turn of the file based launcher in settingsRMXTool by @imadlatch is a great tool for resizing data/system.img and having a poke through the system.img while in WindowsProposition
It should be trivial to modify the ramdisk of Androidx86 ROMS to bind mount an additional .img to host the device specific modules/firmware for trying out new generic ROM releases - obviously full ROM build are preferrably but not always available.
Will need to have a look into the module packing that the build does in order to pack correctly when just compiling a kernel & modules.
XDA:DevDB Information
Androidx86 & Forks, ROM for the Android General
Contributors
HypoTurtle
ROM OS Version: KitKat; RemixOS/PhoenixOS (Lollipop); Marshmallow
Version Information
Status: Stable
Created 2016-02-12
Last Updated 2016-02-12
Reserved
INSTALLATIONThere are numerous ways these can be installed and there are numerous post reporting different methods, so please don't repeat posts detailing the same issue.
I will list tried and tested installation methods (using Grub2) and a quick rundown of what makes upa grub.cfg file
Reserved
FAQIf you have a question that hasn't been answered so far - have a look here first before posting
Thanks @HypoTurtle for making a separate thread for Android releases on the Cube i7 Stylus device! The original thread became quite messy, and it is important to have a dedicated one for Android.
First of all, I think we should really thank the great developers in this forum, @Wootever @asplash @HypoTurtle and all other members and testers for their contribution in preparing a good android image for this tablet.
I've been testing all Android releases in the main thread, and the most stable and usable one was Wootever's 4.4 release.
All other Lollipop (RemixOS and Pheonix OS) and Marshmallow releases seem to suffer from a few major problems:
1) lack of efficient stand by / sleep mode
2) high battery drain
3) no video codecs supporting hardware acceleration
I wonder if this is the case with other x86 based laptops/tablets , and whether the x86-android team are working on fixing these essential features.
Keep up the great work everyone!
@HypoTurtle
Can you please post the script in the first entry for sleep mode in the lollipop releases?
also, any new updates or releases ?
A new beta release of RemixOS has been released.
http://www.jide.com/en/remixos-for-...rce=sendgrid.com&utm_medium=email#downloadNow
Has anyone tested it?
KamaL said:
A new beta release of RemixOS has been released.
http://www.jide.com/en/remixos-for-...rce=sendgrid.com&utm_medium=email#downloadNow
Has anyone tested it?
Click to expand...
Click to collapse
Stock RemixOS Beta, runs with a reported 4.4.2 kernel with as expected wifi not working, switching to the 4.4.0 kernel/modules/firmware we are currently using will work, but I'd rather wait until when/if the kernel source is released.
EDIT. Cube i7 Stylus kernel + modules attached. These are taken from RemixOS Alpha - so it's the kernel @asplash compiled. You need a rooted system.img or unpack/repack system.img within Windows/Linux. Just copy files over / and run the sh while running to set permissions. Then switch the kernel.
Too big to attach so available here
Just a couple of screenshots, it's seems very few people have figured out how to get rotation to work, and I'm sure even fewer have found how to enable apps like Twilight, Lux or Tincore Keymapper...
I'll post procedure in a bit just making sure it doesn't irreversibly mess with anything.
HypoTurtle said:
Stock RemixOS Beta, runs with a reported 4.4.2 kernel with as expected wifi not working, switching to the 4.4.0 kernel/modules/firmware we are currently using will work, but I'd rather wait until when/if the kernel source is released.
EDIT. Cube i7 Stylus kernel + modules attached. These are taken from RemixOS Alpha - so it's the kernel @asplash compiled. You need a rooted system.img or unpack/repack system.img within Windows/Linux. Just copy files over / and run the sh while running to set permissions. Then switch the kernel.
Too big to attach so available here
Click to expand...
Click to collapse
Thanks.
Can you explain step by step how to do it?
Also, any improvements over the previous builds in terms of battery consumption and sleep mode?
Thanks
<MOD EDIT - Non-English Quote Removed.>
Bluetooth not working (same with remix os) for me and I expand data.img with RMXtools but still in android I see 3gb,is there other way to expand?and i can see only 2678MB of ram
asplash said:
essayer d'ajouter
"blacklist btusb" dans /system/etc/modules.blacklist
et redemarre
Click to expand...
Click to collapse
Thanks,bt is working now,for data.img and ram?
leo06 said:
Thanks,bt is working now,for data.img and ram?
Click to expand...
Click to collapse
<MOD EDIT> data.img
KamaL said:
Thanks.
Can you explain step by step how to do it?
Also, any improvements over the previous builds in terms of battery consumption and sleep mode?
Thanks
Click to expand...
Click to collapse
Download it and have a look it should be fairly clear simpilest way is to copy to somewhere you can mount in android (usb, sdcard etc.), then with root file browser copy over, then replace the kernel.
Alternatively use something like RMXTools to open the system.img, copy the files over then repack system, boot, fix module permissions, then switch kernel.
Jide have just released their 4.4.y sources, so going to compile (at least the wifi driver) asap unless @asplash is already setup for a compile. There is a benefit with it at least with exfat (my exfat partitioned sdcard auto mounts with 4.4.2 but not with 4.4.0).
asplash said:
avez vous essayez ceci data.img
Click to expand...
Click to collapse
Do you know why i can't see usb stick and sd card in es file explorer?
asplash said:
de quel format son t'il ? exfat? ntfs?
Click to expand...
Click to collapse
The usb i formated from inside android but still i can't see from es file explorer and sd card is ntfs,i can see both from settings
leo06 said:
The usb i formated from inside android but still i can't see from es file explorer and sd card is ntfs,i can see both from settings
Click to expand...
Click to collapse
/mnt/media_rw/****
Can we install xposed framework in Android?
leo06 said:
Bluetooth not working (same with remix os) for me and I expand data.img with RMXtools but still in android I see 3gb,is there other way to expand?and i can see only 2678MB of ram
Click to expand...
Click to collapse
I answer to myself for 3gb of ram, just realized that is x86 not x64
@asplash
Thank you for your great work on Android for the Cube.
About your latest CM13 ROM:
-Deep sleep seems to work (at last). After coming back from sleep brightness goes up and the device remains unresponsive for a while but after pressing the Windows button everything comes back to normal.
-My 128 GB NTFS formatted MicroSD card can be read from settings and from a file explorer using /mnt/media_rw, but it isn't easily accessible from many apps.
-Battery level isn't read properly, it shows 100% all the time.
-Built-in root doesn't remember a previously granted access, installing SuperSU solves the problem.
-The app GMD Gesture Control (a must have for me) doesn't recognize the touchscreen device. It worked on your Lollipop ROM.
-Only 3 Gb of RAM seem to be accessible, your Lollipop ROM aparently could see the full 4 GB.
-The device doesn't boot with the 8 Gb data.img, it gets stuck on the boot animation.
Speaking about your Lollipop ROM, it's been my Android choice for more than a month. Since its only drawback was the inability to enter deep sleep it would be lovely if you could post a new Lollipop ROM with that issue solved.
ariadnejro said:
@asplash
Thank you for your great work on Android for the Cube.
About your latest CM13 ROM:
-Deep sleep seems to work (at last). After coming back from sleep brightness goes up and the device remains unresponsive for a while but after pressing the Windows button everything comes back to normal.
-My 128 GB NTFS formatted MicroSD card can be read from settings and from a file explorer using /mnt/media_rw, but it isn't easily accessible from many apps.
-Battery level isn't read properly, it shows 100% all the time.
-Built-in root doesn't remember a previously granted access, installing SuperSU solves the problem.
-The app GMD Gesture Control (a must have for me) doesn't recognize the touchscreen device. It worked on your Lollipop ROM.
-Only 3 Gb of RAM seem to be accessible, your Lollipop ROM aparently could see the full 4 GB.
-The device doesn't boot with the 8 Gb data.img, it gets stuck on the boot animation.
Speaking about your Lollipop ROM, it's been my Android choice for more than a month. Since its only drawback was the inability to enter deep sleep it would be lovely if you could post a new Lollipop ROM with that issue solved.
Click to expand...
Click to collapse
For the battery it happens the same to me but after reboot is OK, drops by 4,5,8% and not by 1%,i mean now is 55% and after some time it shows 50%,for 3gb of ram self-test my previous post, it's 32bit Version of Android so only see 3gb,for data.img I use wootever 6gb data.img and it works
I have repo sync from Oneplus OSS https://github.com/OnePlusOSS/android/tree/oneplus/QC8996_N_7.1 branch oneplus/QC8998_N_7.1 and create full flash image.
I've change the build rules to allow the flash image able to be flash to fix error when trying to flash the image.
Changes on top of vanilla OOS repo:
1 . Add gapps as prebuilt
2. Exclude Snapdragon Launcher
3. Exclude FM Radio
4. Build rules not to include the device checking in the updater-script. This will allow the flashfiles to be flashed on the device without the need unpack and repack the image.
5. Disable Soft Navigation Button
6. Change the kernel build rule to use perf on user and userdebug variant.
7. Exclude the BT TestApp app
Working features:
Cellular - Both sim slots are working
Wifi
Bluetooth
Camera - Both front and back camera
Privacy Buttons
Fingerprint
The image however lacking the "Buttons" feature that available on the official Oxygen OS. I have been trying to find a way to integrate the option in but still unable to do it.
ROM Links: Mega
Kernel: OnePlusOSS/android_kernel_oneplus_msm8996
I would welcome any suggestion and recommendation. Thanks.
Picture from the Image flashed on my OP3T
Added some pictures