Hi,
I wonder why Jide hasn't included BlueZ stack as default - it supports much more devices and is more stable. Whats more weird - it is included in official Android-x86 builds, so why isn't it in Remix?
I tested my Asus T100 with Remix Phoenix and Android-x86 and only Android-x86 builds let me use Bluetooth - they also handle sleep state and sound better.
Please add BlueZ bluetooth stack
@RemixOS_Cameron @RemixOS_Jason @RemixOS_Joshua please answer my question.
Thanks,
Karol
@Ventricle - I just talked to our PM and he's told me that we have included BlueZ Bluetooth because Remix OS for PC is based on Android-x86. If your Bluetooth doesn't work with Remix OS, does it work with Android-x86? Please let me know as it'll help our PM troubleshoot your issue. Thanks!
@RemixOS_Jason thanks for the reply.
I thought you didn't include it because BlueZ's basic commands don't work; like hci or hciconfig.
And please read my whole post - I said BT works fine on Android-x86 builds (and do do hci or hciconfig commands).
Remix and Android-x86 init.sh files are pretty much the same, but the bluetooth part operates in many cases on BlueZ commands which simply don't work on Remix. That is why I think you didn't include it - or you devs didn't merge the repos correctly or they based Remix off old Android-x86 builds which don't use BlueZ.
@Ventricle - My apologies for not fully understanding your point the first time. I'll pass your comment along to our PM and give you feedback asap. Thanks!
Related
Hello,
I am porting CM11 on Xperia U(P/Go/Sola). Since the switch by Google from Bluez to Bluedroid the bluetooth was no working. Recently the Bluez team release a version for repleace Bluedroid. Currently I have a full working driver + kernel bluetooth subsystem + Bluez (v 5.12). All the Bluez command line tools are working but I can not set Android in order to recognize that there is a bluetooth device and it is working. Probably It is due to a HAL missconfiguration. Some of you have experience in this sense? Can help me? Can give me some reference about that (i.e. guides or ROMs that replace bluedroid with bluez sucessfully) ?
Hey Remix developer users.
We've reached out to the team at Termux (https://termux.com/) and we're excited to announce that we have their blessing to launch projects with them on their GitHub repository: https://github.com/termux/termux-app
We've identified the following features that would improve the Termux experience on Remix OS. They are:
1) multiple instances of Termux
2) better support on mouse: mouse select, copy, paste
3) configure bash correctly with a default .bashrc file
Naturally, since Termux is an open source project, when your commits are integrated into the Termux project after they pass testing, you'll improve the overall Termux experience for everyone.
At the end of the day, we know that developers who use Remix OS for PC have been asking for ways to contribute to the project. This is a great way for you to get involved with us, and to help improve Termux overall.
Win-win-win!
You can also help improve the Remix OS kernel, Windows & USB installer via our GitHub page (JideTechnology https://github.com/JideTechnology).
It's beautiful. You made a straordinary job, and you reinvented the use of a PC. Releasing sources will improve your and other's work. Everybody won today.
Thanks for your job !!!
/clap
Lineage CICD Project
This is my personal effort given to you, the community, which spends a lot of hours to craft a fully-functional and perfectly tuned ROM for our beloved Smartphones!
What is it?
This project aims to provide a Build system for Android Developers which will be able to build an Android ROM for a different set of Codenames given, automatically for you, ( by default ) every night. Not only built stock sources that are already available on LineageOS Github account, but feel free to build even your custom code thanks to the support of local_manifests/*.xml fully supported by this Docker.
Where can I find it
CICD
- Github: https://github.com/julianxhokaxhiu/docker-lineage-cicd
- Docker Hub: https://hub.docker.com/r/julianxhokaxhiu/docker-lineage-cicd/
OTA
- GIthub: https://github.com/julianxhokaxhiu/LineageOTA
- Docker Hub: https://hub.docker.com/r/julianxhokaxhiu/lineageota/
- XDA: https://forum.xda-developers.com/showthread.php?t=2636334
Why?
As you all remember the transition from CyanogenMod to LineageOS was not smooth. Even today we are not granted with Nightly Builds, but with Weekly, because of capacity issues on providing such an amazing plethora of supported Devices ROM ZIPs ready to be flashed.
Therefore this projects aims on providing an easy-to-use build system which may help you on providing a Ready-To-Flash ZIP at the end of each Build round.
How does it work?
This is a pre-packaged Docker system based on Debian, with all the dependencies in place to correctly build ( even in an optimized way ) any LineageOS codename ROM. A cronjob will take care to start the build script on the configured time ( by default 10:00 UTC ~= 02:00 PDT ), which then will take care to build every codename given with an environment variable to the Docker.
All you need from now on is just the Docker Engine installed on your favourite Linux distribution.
Bonus!
Of course the ZIP that will be produced needs to be transferred to the device in order to flash it. Such a boring task...what if we can automate it through OTA?
As you all know, my first big project I've ever started for XDA was the OTA Server which perfectly emulates all the required calls to make it working with ( old and deprecated now ) CyanogenMod ROMS, as well as with ( long life to ) LineageOS, right now, today!
All you need to do is to configure an Environment variable in the Docker to say where your OTA Server is located. The URL will the be added automatically for you inside the build.prop file as cm.updater.uri=$OTA_URL.
...but wait, there is more!
Since the OTA Server is written in PHP, you all know that is a headache to prepare the system to make it working. A lot of user complained in the original Thread that was difficult for them to understand how to setup it correctly, therefore a fully working autonomous Docker is there for you, ready to serve the OTA Layer for you built ROMs!
I want to use it right now!
I am pretty sure you want! The Docker has now been tested for a nearly a Month and I'm successfully installing my own builds for a couple of weeks on my devices ( really a great satisfaction! ).
If you want to run it as well, I suggest you to take a look at this Bash script that will run for you the Dockers, already talking to each other. Since the script has been studied to work on top of the "VPS Powered By Docker" project, I suggest you to take a look at it. Although nothing is preventing you to use it in your favourite way.
Requirements
See the detailed list on the project README.
What about License
All my projects are always developed with MIT license, which means feel free to do what you want with it. I don't really care if you do business with it, it was a great challenge for me reaching this autonomous entity to run, therefore I don't mind of possible outcomes of it. Although Issues are always welcome for improvements, if any found, of suggestion for a possible feature enhancements.
Future plans?
At the moment I have some ideas, which I may, or may not, be able to implement as I am not a professional Android Developer. Although some nice to have points are:
- Possibility to build ANY Android distro ( from AOSP to any fork of it )
- Possibility to have changelogs of every nightly build ( attached as *.txt and *.html format, next to the built ROM )
- Maybe a logo?
Thanks for Awesome Work
Thanks for awesome work.
Hello!
This is a development thread for the project of upgrading of the Linux kernel for the U8500 platform.
Builds provided here (at the moment of writing this message) are not considered to be used as a daily driver, by any means, - these are rather a dev preview versions.
For now, there are a several LK builds (the highest currently supported kernel version is 3.10).
Because builds here are really not stable, I'll just leave a disclaimer here.
Code:
#include <std/disclaimer.h>
/*
* I am not responsible for bricked devices, dead SD cards, thermonuclear
* war, or the current economic crisis caused by you following these
* directions. YOU are choosing to make these modificiations, and
* if you point your finger at me for messing up your device, I will
* laugh at you.
*/
Working features
RIL
Camera (front & rear) - only works in <3.8
Video (playback & recording)
Audio (playback & recording)
Wifi
Bluetooth (broken in >=3.8, needs a workaround to manually startup)
USB, ADB
Tethering (not tested)
GPS (not tested)
Sensors
Known bugs
IRQs are mishandled by some device drivers (abb_btemp, abb_fg)
proximity sensor might not work (not tested, cause it's broken on my device)
deep sleep might not work at a times
MMC driver works unreliably in >=3.8 (contiguous usage might lead in a data corruption)
networking is not fully-functional (no mobile data)*
camera is broken in 3.8
*some other features of the android kernel might not present - it's because these kernels lacks android-specific patches.
Sources
LK 3.5
LK 3.6
LK 3.7
LK 3.8
LK 3.9
LK 3.10
Downloads
http://xda.mister-freeze.eu/XDA-files/ChronoMonochrome/misc/upgrading
Installation
install chrono kernel r5.2 or higher (this is needed to pick up the necessary scripts, incl. bootscripts, etc)
reboot to recovery
install build linked in "Downloads" section
Credits
Linux kernel development community
Google
ST-Ericcson
Samsung
Team Canjica
XDA:DevDB Information
U8500 Linux kernel upgrading project, Kernel for the Samsung Galaxy Ace II
Contributors
ChronoMonochrome
Kernel Special Features:
Version Information
Status: Alpha
Created 2017-05-09
Last Updated 2017-05-10
Reserved
Porting
The porting a higher kernel version tehnique I'll describe here is not intended to be a guide for dummies. I'll assume you've already built a kernel for your device, familiar with git versioning control usage and with some porting / coding tehniques.
Firstly, you need a cleaned source for your device. By "cleaned" I mean, there are no Linux incremental patches, android changes applied, manufacture-specific patches are avoided when possible and so on - you need sources as closest to a "pure" Linux kernel as possible. Otherwise you'll have later need to deal with conflicts resolution, you'll most likely be unable to resolve and the kernel won't boot.
So, without a further forewords, the tehnique is below:
1) As was previously mentioned, a clean kernel source is required, I'll assume we are starting from LK-3.4 ( https://github.com/ChronoMonochrome/Chrono_Kernel-1/commits/ea228ee0f5e9935841aff25c62fa163cd78dc01d ) and porting a higher kernel versions. A kernel base needs to be tested for any bugs just to distinguish, which bugs were intruduced during porting from those ones that already present in a kernel base.
2) The following steps will mostly use git bisect and git merge commands in order to merge all the changes from a higher kernel versions and help to find / resolve the bugs that were introduced. I suggest copying a git kernel repo that you use for building to a somewhere else, so you can use it , e.g. for grepping a different versions source, bisecting the revisions and so on, so don't need to bother messing up in your main repo that you use for build.
3) Firstly, lets just try to merge a higher kernel version, e.g. LK 3.5 by issuing a command git merge lk-3.5. You'll likely have a lot of merge conflicts, most of which you can resolve with resetting the paths to a some revision (either a kernel base - lk 3.4, or the version you do port, or just another suitable conflict resolution). So I suggest to write those paths to a text file, like so:
Code:
arch/arm/boot
arch/arm/mach-ux500
arch/arm/plat-nomadik
drivers/mmc
include/linux/mmc
drivers/usb
include/linux/usb
drivers/mfd
include/linux/mfd
...
Write all the paths you intend to reset to the kernel base, you most likely need to re-use them later. To actually perform a resetting source, you can issue
Code:
for path in $(cat file_with_a_paths.txt | xargs)
do
git checkout COMMIT $path
done
Be sure not to put to this file anything not the device-specific! Resetting to the kernel base should be avoided when possible (never ever try resetting archictecture-specific paths, e.g. arch/arm/kernel, arch/arm/mm and so on - unless you really know that kernel will boot thereafter, instead, you have to manually resolve such conflicts). Resolve any other conflicts by resetting paths to the porting source (e.g. LK 3.5).
Note. While resetting with a paths is probably not the most accurate tehnique, but people don't live that long to use more accurate approach, e.g. performing git cherry-pick for every upstream commit and then manually resolving all the conflicts, you'll just sooner or later get bothered and will abandon it.
4) When you're done with the previous steps you can try building kernel. You'll likely have a build errors - because some part of a source got not updated (e.g. the device-specific drivers), you need manually implement the necessary by a higher kernel version changes. Firstly check if an upstream kernel contains the necessary fixes (example: https://github.com/ChronoMonochrome/Chrono_Kernel-1/commit/9fae8c449b710f502662da1cbcf26ece5a098af9 , https://github.com/ChronoMonochrome/Chrono_Kernel-1/commit/fe027c25d6db0d100937deb5248e249ec5b24ee7 ). If the driver you are porting doesn't exist in the upstream, you can also try to find a similar change and mimic it: https://github.com/ChronoMonochrome/Chrono_Kernel-1/commit/5f2e7afbf2ac3284dc62b3d96a0627c7f99ed4e9 ( ported similarly to https://github.com/ChronoMonochrome/Chrono_Kernel-1/commit/526c597 ). In the worst case scenario you will need to examine the upstream changes and apply the changes so that the drivers complies to the upstream changes: https://github.com/ChronoMonochrome/Chrono_Kernel-1/commit/ea6432d167 .
5) If everything is done properly and you're lucky enough, the compiled kernel might already bootup. If not, you'll need to find a culprint that doesn't let the device to boot up. Switch to a copy of your kernel sources, reset the source to the base kernel version (e.g. LK 3.4), issue git bisect good, then issue git bisect bad lk-3.5, git will reset to a somewhere in a middle between of LK 3.4 and LK 3.5.
6) Save your changes in the kernel repo, by assigning a some branch to it, switch to the source base, merge all the fixes you've already introduced, then merge the revision you have got in the previous step by bisecting the tree. Repeat these steps until you'll find a first bad commit.
7) If you are already on this step, the most trickiest part starts here - testing (hopefully) working kernel for bugs (if any). While logs can be useful sometimes (so you can google the failing messages and find something useful), there are also many bugs you can find only performing git bisect tehnique decribed above.
The decribed algorithm only possible thanks to having a clean kernel source. The usage of this guide is not limited only to the kernel porting, it can be used on other projects as well, this is just what I've come across to, when I've ever started porting Linux kernel versions higher than LK3.4.
Reserved
I wonder if any of this expertise couldn't look pretty cool here too.
Wooooowwwewe
Oooh
Look whose good boys have been trying to win the STE mastermind prize as of lately
https://github.com/novathor-mainline/linux
https://git.kernel.org/pub/scm/linu...inux-nomadik.git/log/?h=ux500-skomer-v5.5-rc1
mirhl said:
Oooh
Look whose good boys have been trying to win the STE mastermind prize as of lately
https://github.com/novathor-mainline/linux
https://git.kernel.org/pub/scm/linu...inux-nomadik.git/log/?h=ux500-skomer-v5.5-rc1
Click to expand...
Click to collapse
Seriously!
mirhl said:
Oooh
Look whose good boys have been trying to win the STE mastermind prize as of lately
https://github.com/novathor-mainline/linux
https://git.kernel.org/pub/scm/linu...inux-nomadik.git/log/?h=ux500-skomer-v5.5-rc1
Click to expand...
Click to collapse
Wow, that's incredible
Exynos4412 already got some mainline support, it would be very nice to have this one supported too.
Aaaaand it's done, kinda.
ST-Ericsson NovaThor U8500 - postmarketOS
wiki.postmarketos.org
device/testing/linux-postmarketos-stericsson · master · postmarketOS / pmaports · GitLab
postmarketOS package build recipes
gitlab.com
Arch Linux is an independently developed, x86-64 general-purpose GNU/Linux distribution that strives to provide the latest stable versions of most software by following a rolling-release model. The default installation is a minimal base system, configured by the user to only add what is purposely required.¹
NOTE: The Arch Linux packages are no longer updated. Consider taking a look at the postmarketOS port instead.
Introduction
With Android 5.0 (Lollipop), the ASUS MeMO Pad 7 (ME176C(X)) was updated with UEFI boot, making it possible to boot any Linux distribution on it. archlinux-me176c aims to make Arch Linux fully work on the ASUS MeMO Pad 7 (ME176C(X)). It provides additional packages and documentation for using Arch Linux on this device.
With me176c-boot, Linux can be installed in dual/multi boot configurations together with Android. Arch Linux is a minimal distribution, therefore most of the setup (partitioning, installing a desktop environment, ...) will be left up to you. However, it also allows you to customize it entirely to your liking, and configure it for any use case you can imagine.
Installation
Warning: Although the wiki article below provides many recommendations, at the end, setting up the installation will be left up to you. There is no step-by-step guide. If you have never used Arch Linux before, you may want to try it on a desktop PC or virtual machine first. You can easily brick your tablet if you don't know what you are doing!
All documentation is available in ASUS MeMO Pad 7 (ME176C(X)) - ArchWiki. As a wiki article, I encourage everyone to contribute and share their experiences with everyone else.
If you need any help or further suggestions, do not hesitate to ask in this thread!
FAQ
Can I use other Linux distributions on this tablet? Yes! However, you will need to set up more things manually. There are a few notes for this in linux-me176c: Porting - Using linux-me176c in other distributions
Source Code
Documentation: ArchWiki
Packages: archlinux-me176c (GitHub)
¹ Source: https://wiki.archlinux.org/index.php/Arch_Linux (GFDL 1.3)
XDA:DevDB Information
Arch Linux for ASUS MeMO Pad 7 (ME176C(X)), Tool/Utility for the Asus MeMO Pad 7
Contributors
lambdadroid
Source Code: https://github.com/me176c-dev/archlinux-me176c
Version Information
Status: No Longer Updated
Created 2019-04-02
Last Updated 2020-05-12
Reserved
Hi!
Seem awesome!
Do this have a full hardware accelerated graphics support?
Is this compatible with k013 ?
shim80 said:
Do this have a full hardware accelerated graphics support?
Click to expand...
Click to collapse
Yes. (It has Intel Graphics just like on normal Intel PCs, and therefore OpenGL and Vulkan support is provided by Mesa.)
shim80 said:
Is this compatible with k013 ?
Click to expand...
Click to collapse
Yes, K013 == ME176C(X).
Thanks for the answers.
Also, if wan't to go back to Android, can I do it?
shim80 said:
Also, if wan't to go back to Android, can I do it?
Click to expand...
Click to collapse
The recommended setup is to keep Arch Linux on an external SD card. Then you can have Android and Arch Linux installed at the same time ("dual boot").
@lambdadroid man when running
# pacman -Sy me176c
or trying to install base packages it says
error: me176c:signature from "lambdadroid is known trust error: failed to update me176c (invalid or corrupted database (GPG signature)
when running
$ pacman-key --finger keyid
it says pub
ed25519 2017-08-10 [sc] [expired: 2019-08-17] uid [expired]
should I try an offline instalation?
No longer updated
The binary repository has been down for a while now - I have no plans to update the Arch Linux packages again. This is mostly because I'm no longer using Arch Linux myself on the me176c / K013.
However, as a replacement a postmarketOS port with same functionality has been around for a while. Since it's much more comfortable to install (simply through Fastboot/SD card with a large number of selectable UI interfaces) I prefer it over Arch Linux at this point. I would recommend it to anyone who would like to use a more standard "Linux" distribution on me176c / K013.