Related
Hello everyone, I know this is a long shot but: is anyone interested in porting Android to this excellent eBook Reader?
Device description is here: http://www.bookeen.com/en/cybook/odyssey
It is basically a Nook Touch Simple/Sony PRS T1 like device that features a very fast e-Ink display (amazingly fast for an e-Ink) and should support some tablet like use (browsing the web, reading a RSS feed) quite well. You can see here and here what HSIS (High Speed Ink System) can do.
Stock version is using a Linux 2.6.31 based OS (doesn't specify what flavor)
From the little I know the main problems with porting a Android whould be:
- possible locked bootloader on the Cybook Odyssey -> no way to know without the device
- supported chipset -> an ARM A8 based chipset is listed
- display drivers -> maybe those from regular pearl e-Ink can be used?
- wi-fi drivers -> again, depends on the chipset
I'm out of my league (php, web stuff) here but I plan to buy the device next month if there's hope for it
Ideas?
Hi!
I would point out, before getting your hopes up on the porting, the fact that you asked just one day after the launch of the device, makes one think that you're thoughts are audaciously early. So unless some xda-developers are Bokeen insiders and, ahem, unbound by their job to work on this matter, either waiting or is the thing to do. Or, ahem, , learning how to port?
The chances I see for this port to happen are small (but than again still possible). Perhaps we could see if the linux running it might offer more flexibility and run apps directly (?). Porting would would have it's obvious advantages ... an Android with it's screen technology superior to any current eInk readers, except the Mirasol powered ones perhaps (those are limited to Korea for now) would we awesome.
csioucs said:
Hi!
I would point out, before getting your hopes up on the porting, the fact that you asked just one day after the launch of the device, makes one think that you're thoughts are audaciously early. So unless some xda-developers are Bokeen insiders and, ahem, unbound by their job to work on this matter, either waiting or is the thing to do. Or, ahem, , learning how to port?
The chances I see for this port to happen are small (but than again still possible). Perhaps we could see if the linux running it might offer more flexibility and run apps directly (?). Porting would would have it's obvious advantages ... an Android with it's screen technology superior to any current eInk readers, except the Mirasol powered ones perhaps (those are limited to Korea for now) would we awesome.
Click to expand...
Click to collapse
Is there any news on debugging and or development possibilities on that platform? I have seen the gpl'ed linux source released at bookeen's site.
I have yet not found any pictures of a disassembled device and do not know if customized firmware updates are possible.
Would very much appreciate any news on that topic!
NonsenseInc said:
Is there any news on debugging and or development possibilities on that platform? I have seen the gpl'ed linux source released at bookeen's site.
I have yet not found any pictures of a disassembled device and do not know if customized firmware updates are possible.
Would very much appreciate any news on that topic!
Click to expand...
Click to collapse
I would also be interested in customized firmware for cybook odyssey. thanks
Any news on this anybody?
Anyone still watching this? I'd like to try to do it, but it's over my head, skill wise...
Sent from my GT-I9300 using Tapatalk
thirstythirsty said:
Anyone still watching this? I'd like to try to do it, but it's over my head, skill wise...
Sent from my GT-I9300 using Tapatalk
Click to expand...
Click to collapse
I know that internally some version of android ran on the device, but it's really not worth to do this. Android is absolutely not suited for such device and screen.
To install personalised linux/software, first crack the update format, then the device will be open to you...
I have a Galaxy S2 which seems to share the same chipset as the GT 7+.
I've just ordered a tab7+ and as there is a massive amount of roms available for the S2, including ICS. Would the binaries for the S2 help make an ICS rom for the GT7+?
Binaries? No - completely different screen, very different peripherals, and no Honeycomb for the Tab 7. Even when both have ICS, they will be very different builds.
Kernel source? Due to being 2.6.36.x, the Honeycomb source base for your kernels has differences from the S2 codebase - so a lot of stuff can't be directly applied, but a competent developer (you have one with garyd9) can apply the "concepts" in many cases.
Unfortunately, Samsung screwed up the wifi driver in the 7 Plus. It's binary-only (no source code) and it seems to have bugs.
Entropy512 said:
Kernel source? Due to being 2.6.36.x, the Honeycomb source base for your kernels has differences from the S2 codebase - so a lot of stuff can't be directly applied, but a competent developer (you have one with garyd9) can apply the "concepts" in many cases.
Click to expand...
Click to collapse
I don't think there are any kernel mods I'd want to bring over from that device. As far as what the OP called "ROMs", I have no idea what they are referring to. There doesn't seem to be any read-only memory in the tablet.
If he meant "firmware", then I have to admit that I'd prefer not to do that kind of thing. There are many different kinds of developers in the world... some get off working at the lowest possible level (kernels, etc) and others prefer higher level things. I'm the former, and it would take the latter to do firmware development.
Gary
So, a "number" of OEMs are using Qualcomm SOCs for their Android Wear devices.
So my guess would be that Qualcomm TOQ is a "reference platform" for Android Wear.
Perhaps there may be ROMs released.... or leaked given that OEMs surely have them already.
No source code for now....
I'm guessing the kernel will be the more or less usual Android variant of the Linux kernel, perhaps with fewer drivers/features. And it's ARM of course.
How similar to standard Android on the higher level ?
I'm still pretty new to smart-watches. I haven't looked at the preview SDK yet.
EDIT: Uses an STM micro, too weak I'd guess to run Android (Wear variant).
EDIT: Looking now, and wondering if the code will even be open sourced ? Google may want to have more control this time around. Google, and the HW OEMs, might even put in roadblocks to custom ROMs even if the source is open, including the usual device locking of course.
http://developer.android.com/wear/preview/start.html :
Caution: Do not install apps on the Android Wear emulator. The system does not support traditional Android apps and the result of running such apps is unpredictable.
Click to expand...
Click to collapse
LOL. Time to try some of my apps and see what happens.
EDIT2: My app UI works !, although the UI is very squished. Looks almost like normal Android (from the app/dev point of view, Launcher or whatever UI is very different). I'm sure a whole bunch of APIs don't work and some will never work.
hm they use their cpus, why not the displays?
mirasol displays seem to be the perfekt ones
http://www.qualcomm.com/mirasol/technology
I really doubt that the toq can run google wear. It is using a 200mhz non snapdragon soc.
yerand said:
I really doubt that the toq can run google wear. It is using a 200mhz non snapdragon soc.
Click to expand...
Click to collapse
Is there a teardown of it somewhere ?
I really think the android wear platform is going to be locked down. I even doubt google will allow oem customization beyond maybe some skinning. Wearables is too fragile of a market to allow the amount of freedom we have on android phones/tablets. So, that means it'll probably have specific hardware requirements and such that prevent it from running on devices that weren't intended to run it. Even if it were remotely possible it wouldn't work very well. Look at other porting projects like Windows phone to android devices and sense for non-htc devices.
I'm leaning towards Google treating "Android Wear" the same as "Android Phone/Tablet".
Google has never hesitated to be open with the "basic" code to run Nexus devices. Open source is good for them.
That's the low level stuff that they build upon and REALLY protect with closed source and licensing requirements: Google Play, GMail, etc.
It's in their interest for everybody to be build the compatible low level.
I don't think Google has committed on the matter publicly yet, funny.
mikereidis said:
Is there a teardown of it somewhere ?
Click to expand...
Click to collapse
I was looking up a part number after tearing down one and found theTech Insights report: http://www.techinsights.com/uploade...ts/Wearable-Wellness_Survey_Sample_Report.pdf
Fencesitter said:
I was looking up a part number after tearing down one and found theTech Insights report: http://www.techinsights.com/uploade...ts/Wearable-Wellness_Survey_Sample_Report.pdf
Click to expand...
Click to collapse
Thanks ! I thought there was only one teardown and it cost $1250 to see.
So, STMicroelectronics STM32F207IGH6 ARM Cortex-M3 32-Bit Microcontroller...
Not a Qualcomm SOC/CPU. And only 16 MB of RAM ???
I don't think this will ever run Wear.
I guess it's just an early prototype, of Mirasol among other things.
mikereidis said:
Thanks ! I thought there was only one teardown and it cost $1250 to see.
Click to expand...
Click to collapse
Which company was that?
Let me say for the purposes of CYA that I found the Tech Insights link merely by searching for the term "wcn2243 data sheet" Which is one on of the smaller chips on the Toq.
Fencesitter said:
Which company was that?
Let me say for the purposes of CYA that I found the Tech Insights link merely by searching for the term "wcn2243 data sheet" Which is one on of the smaller chips on the Toq.
Click to expand...
Click to collapse
Same company, more detailed report, including some die photos. Advertised for $1250 here: http://www.techinsights.com/reports...market-reports/Report-Profile/?ReportKey=9830
You linked to a legitimate sample report, linked from this page: http://www.techinsights.com/teardown.com/teardown-sample-reports/
I looked at the firmware for the 1st Sony smartwatch and could see several of the hardware components and some proprietary RTOS. Sony supposedly "opened" the watch, but it's just a toy OS last I looked. They weren't releasing anywhere near enough code to replicate stock.
Anyway, the TOQ parts list seems somewhat reasonably similar; there's probably just a few common designs out there. But things may be changing if the new watches will run an actual variant of Android; ARM based micro-controllers being replaced with I guess more powerful "SOCs", not that it's too easy to distinguish a SOC from a micro...
...Now I'm wondering what's in the Chromecast I just got, LOL... Google is going more deeply embedded now.
Hello,
I bought several smartphone in the past until now and I always want to use them as long I can.
So Android obsolescence comes quite quickly once a smartphone arrives on the market (around 2 or 3 years after). We lose security patches, capability to use upper android version.... So each time I try to use custom ROM based on AOSP or Lineage / CM BUT I lose the capability to make decent photo with the Camera.
Currently it is unacceptable because I have to immortalize best moments of my life (childs, family ...).
The questions are simple : Do you know Android smartphone manufacturer or specific models with open / published camera drivers / framework that can be used on AOSP / Lineage OS?
I have the same question, if a manufacturer publish camera drivers that be used on upper Android version (EX: published for Marshmallow but useable on Oreo).
Thanks
There isn't one. This is the difference between open source and closed sourced drivers. The cameras and drivers are not even made by the device oem.
Updates these days are not that bad. You get a flagship and it will easily last 5 years. Even if 2 of them are only with security updates.
Hello zelendel,
Thank you for this reply.
In consequence all smarphone suffer of the same miseries. There is no way to get a Lineage with the same camera quality than stock experience due to closed source?! :crying:
Pretty much yes. I have not found a single device that doesn't suffer. It's one of the things you give up when you swap over to aosp base. Just like when using Linux. You lose anything special the oem did.
Hi everyone.
Every year millions of phones and tablets are produced. Because hardware makers don't worry about updating them, those devices are often dumped. However, lots of them are very capable machines.
As I've read these forums for years, I've seen a lot of work from a lot of people trying to bring those forgotten devices to life again by making unofficial ROMs with tons of customization, new features, and great efforts like LineageOS and PostmarketOS. However, those lack the resources to bring an updated OS for the majority of those binned and obsolete phones.
If I'm not wrong, the biggest issue about replacing the original OS on those devices are the bootloaders and drivers/blobs for the large amount of different hardware configurations. There are multiple workarounds, shims, ports that solve those problems for one or other device.
It might be quite naive, but i'd like to ask a question I've been thinking about lately. AFAIK, if I have the blobs/drivers for a camera, wifi, bluetooth, GPS or other "peripheral" for a devices' original ROM running Android 4.4, I can make it work on AOSP 4.4. I know this might be crazy, but:
As long as I have the blobs for a certain chipset and display/touch, why can't we use a VM running a nano version of AOSP that matches the devices' original ROM that bridges the device IO to the main ROM?
As an example, imagine wifi. I could network bridge AOSP 9 to a VM running AOSP 4, which would then have the drivers so network would work. The same for bluetooth or camera or GPS, maybe? Is this absolutely unfeasible?
Thank you for your time!
wasserprojekt said:
Hi everyone.
Every year millions of phones and tablets are produced. Because hardware makers don't worry about updating them, those devices are often dumped. However, lots of them are very capable machines.
As I've read these forums for years, I've seen a lot of work from a lot of people trying to bring those forgotten devices to life again by making unofficial ROMs with tons of customization, new features, and great efforts like LineageOS and PostmarketOS. However, those lack the resources to bring an updated OS for the majority of those binned and obsolete phones.
If I'm not wrong, the biggest issue about replacing the original OS on those devices are the bootloaders and drivers/blobs for the large amount of different hardware configurations. There are multiple workarounds, shims, ports that solve those problems for one or other device.
It might be quite naive, but i'd like to ask a question I've been thinking about lately. AFAIK, if I have the blobs/drivers for a camera, wifi, bluetooth, GPS or other "peripheral" for a devices' original ROM running Android 4.4, I can make it work on AOSP 4.4. I know this might be crazy, but:
As long as I have the blobs for a certain chipset and display/touch, why can't we use a VM running a nano version of AOSP that matches the devices' original ROM that bridges the device IO to the main ROM?
As an example, imagine wifi. I could network bridge AOSP 9 to a VM running AOSP 4, which would then have the drivers so network would work. The same for bluetooth or camera or GPS, maybe? Is this absolutely unfeasible?
Thank you for your time!
Click to expand...
Click to collapse
That's sort of what project treble is.
Project Treble
The Android 8.0 release includes Project Treble, a major re-architect of the Android OS framework designed to make it easier, faster, and less costly for manufacturers to update devices to a new version of Android. Treble is for all new devices launching with Android 8.0 and beyond.
forum.xda-developers.com
I was reading about it and it seems like treble is not very seccessful. I imagine Google isn't very interested on this, as they want phones to be sold every year. Anyway, I was asking about this specific method of making phones and tablets compatible with today's OS or, who knows, even linux.
wasserprojekt said:
I was reading about it and it seems like treble is not very seccessful. I imagine Google isn't very interested on this, as they want phones to be sold every year. Anyway, I was asking about this specific method of making phones and tablets compatible with today's OS or, who knows, even linux.
Click to expand...
Click to collapse
Yes and the only way it might work is trebel. Because treble handles lot of the problems involved with booting newer androids on older systems.
You can run linux on older Androids or even Windows XP.
How to install a Linux desktop on your Android device
Get even more from your Android device by running a desktop OS! Lots of options including Debian (no root), Ubuntu, and Kali Linux.
www.androidauthority.com
Running Windows XP on Android
No rooting or custom modifications needed, we’re going to do this with stock Android and a few free (but high-quality) apps.
centerorbit.medium.com
Also, it's not that the OS gets deprecated, it's that the applications like Google Play services which become heavier as years go by.
Degoogled-Android on my Android ICS phone worked fine till it's screen got busted. With Google Play services, it was impossible to install any app since its paltry 400MB storage was extended/
Thanks for your answers!
Running other OSes via VNC is just meant to use the devices as mere thin clients, and that was not the objective.
The Project Treble will never be as widespread as it should be, because Google is obviously not interested in making phones last longer (they want more devices to be sold). Of course I was not talking about devices 10 years old, more about 5yrs. They have specs good enough to run contemporary Android and most of non-entertainment apps.
The obstacles to being able to do this are artificial. The problem is there are no drivers and project Treble does not address this in any meaningful way. Manufacturers aren't interested in this too because they want to sell more chips. So the only way it came to my mind it could work was by running a very light VM with an older Android for which the components' drivers were available. Of course main components would still have to be compatible with newer Android, such as the SOC. But things such as wi-fi, camera... could be bridged from a VM, I believe.
Not sure, but I'd guess the low-level interface would have to be outside the VM.
That is, to be able to run the VM you'd have to have some drivers already in place. I'm also not sure everything can be virtualized. For example, desktop VMs couldn't so easily passthru PCIe or USB to VMs, at least in the past.
There's some EU push to make fixing and servicing some non-phone devices easier, and to mandate labeling phones (and other devices) with repairability scores. Maybe eventually they could mandate, under certain conditions, the logical separation of hardware and software?
Well, after a long time, for those who where curious about this thread: the project Halium is exactly what was in my mind. If I'm not wrong, it basically consists in a minimal Android rom running on a Virtual Machine which then interfaces with any Linux distro, effectively giving the phone the ability to run a (more or less) updated version of Linux kernel and, therefore, many Linux distros. https://docs.halium.org/en/latest/project/Scope.html
hkjo said:
Not sure, but I'd guess the low-level interface would have to be outside the VM.
That is, to be able to run the VM you'd have to have some drivers already in place. I'm also not sure everything can be virtualized. For example, desktop VMs couldn't so easily passthru PCIe or USB to VMs, at least in the past.
There's some EU push to make fixing and servicing some non-phone devices easier, and to mandate labeling phones (and other devices) with repairability scores. Maybe eventually they could mandate, under certain conditions, the logical separation of hardware and software?
Click to expand...
Click to collapse
You are right, and I believe Halium just works on phones which are minimally supported by Linux kernel drivers (like basic SoCs). But all those other hardware parts, like GPS, Wi-Fi, Camera... can be brought to life this way, I think.
Thanks for your insight!