Related
I've got a question... Any plans to implement the new Android-friendly Bluez stack recently rolled out? Seems it would fit with your open-source goals pretty nicely, while also providing enhanced functionality over the status quo...
Sometime last year there were several reports of a successful PulseAudio port as well. As I recall, it offered performance and feature enhancements, though the final word I've seen on the port was a sort of an open-source compromise because the port still required interaction with the closed-source HAL.
Anyway, it seems to me that successful inlines of the above projects might even be incorporated at least in part upstream, thereby setting you apart in your contributions, your feature set, and helping to offload some of the work for both sides.
Also, I want those things.
-Mike
mikeserv said:
I've got a question... Any plans to implement the new Android-friendly Bluez stack recently rolled out? Seems it would fit with your open-source goals pretty nicely, while also providing enhanced functionality over the status quo...
Sometime last year there were several reports of a successful PulseAudio port as well. As I recall, it offered performance and feature enhancements, though the final word I've seen on the port was a sort of an open-source compromise because the port still required interaction with the closed-source HAL.
Anyway, it seems to me that successful inlines of the above projects might even be incorporated at least in part upstream, thereby setting you apart in your contributions, your feature set, and helping to offload some of the work for both sides.
Also, I want those things.
-Mike
Click to expand...
Click to collapse
Well, the existing Android bluetooth stack is also open source, so the question would be what this "new" BlueZ stack (which isn't new, Android used BlueZ for years and switched away with 4.1 or 4.2, can't remember...) offers.
For audio - We have open HALs for a lot of devices, and for those devices we don't have an open HAL for, pulseaudio won't really help.
Entropy512 said:
Well, the existing Android bluetooth stack is also open source, so the question would be what this "new" BlueZ stack (which isn't new, Android used BlueZ for years and switched away with 4.1 or 4.2, can't remember...) offers.
For audio - We have open HALs for a lot of devices, and for those devices we don't have an open HAL for, pulseaudio won't really help.
Click to expand...
Click to collapse
But the existing Bluetooth stack is Android specific, whereas Bluez is a standard Linux component. It's also just recently made itself more Android friendly and (arguably) provides a better documented, more standardized interface.The same can be said of PulseAudio versus Android's sound daemon; implementing either or both would provide for more ease of interoperability between Android and other Linux devices, diminish Android fragmentation, and relieve some of the strain imposed by redundant development. What's more, I think both of these goals are probably largely achievable, but I was just asking.
Also, I want those things.
-Mike
mikeserv said:
But the existing Bluetooth stack is Android specific, whereas Bluez is a standard Linux component. It's also just recently made itself more Android friendly and (arguably) provides a better documented, more standardized interface.The same can be said of PulseAudio versus Android's sound daemon; implementing either or both would provide for more ease of interoperability between Android and other Linux devices, diminish Android fragmentation, and relieve some of the strain imposed by redundant development. What's more, I think both of these goals are probably largely achievable, but I was just asking.
Also, I want those things.
-Mike
Click to expand...
Click to collapse
Well, BlueZ was the default Android stack for quite some time - it was dropped for whatever reason. So not sure why they need to make it more "android friendly" when it was part of Android for a few years.
As to PulseAudio - it's a consistent bane of my existence on the desktop, and is probably overkill for mobile.
Of course, if you want to take a crack at integrating them and actually find that they do have tangible benefits, give it a try!
Entropy512 said:
Well, BlueZ was the default Android stack for quite some time - it was dropped for whatever reason. So not sure why they need to make it more "android friendly" when it was part of Android for a few years.
As to PulseAudio - it's a consistent bane of my existence on the desktop, and is probably overkill for mobile.
Of course, if you want to take a crack at integrating them and actually find that they do have tangible benefits, give it a try!
Click to expand...
Click to collapse
Wow. Strong words. You consider PulseAudio an existential bane, huh? Can I ask what sound daemon you use instead? I suppose it's possible you do without. Though it seems OSS is entirely deprecated, ALSA can still provide minimal functionality without a user-space management daemon if necessary, but without some extensive and, at least to me, seemingly esoteric initial configurations, good luck handling even a lasting volume adjustment without root access (or be in the "sound' group, I suppose), and should you have occasion to simultaneously offer two applications sound privileges... Sorry, grinding my teeth again.
Anyway, I didn't much like PA at first either, but I wanna say my first encounter with it was Ubuntu 7.10 or so, or thereabouts. I've since adopted the greener pastures offerred by several other distributions, less brown anyway, but PulseAudio is a fairly static component of my sound system as configured by default by distro maintainers no matter where I wander. Even on systems I build up myself from very little, when PulseAudio is included it tends to be one the things I have to consider least as trouble goes. The plugin support is very extensive these days as well.
When PulseAudio is combined with Bluez for instance, it can emulate almost all of the headset profiles, to include a telecommunications headset, and can easily record from this stream or any other because every one of PA's sources can be easily multiplexed. It's fun, and very powerful. PA can do on cheap or even no dedicated hardware at all what Airplay only aspires to. And these days, it even makes it easy. It's a true sound server, and while it can be utilized simply enough with Android satellite clients if you set it to emulate Airplay, to serve a multi/unicast, and/or to emulate the DLNA protocol, even this impressive scope of functionality is much diminished when compared to two PA servers working in concert.
Other desktop alternatives do exist, of course. There's Jack, designed to provide low-latency, realtime audio rendering, but these days it seems it too seems to operate best, and is most often configured to do so by default, in conjunction with a PA daemon. And MPD of course, which I confess I have much interest in, but very little other incentive otherwise to actually try for myself. I don't actually known what it's capable of. Perhaps you do? I wonder, is it just, as is eponymously implied, a music player daemon? Or can it actually be extended to do the kinds of things I've come to expect of PA as hinted at above? I really should find out.
Anyway, if you haven't had a look at this, it might interest you: http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-fight/
The author takes care to provide many impressive benchmarking results as proof of the worth of his efforts. If that sparks your interest, you'll find the Android port homepage here: http://www.freedesktop.org/wiki/Software/PulseAudio/Ports/Android/.
And try to remember that PulseAudio is a more mature and proven project than is Android itself, much less SoundFlinger, and each of these three could be said to have experienced some rather rocky starts.
As for the Bluez project being recently dropped from Android and its even more recent Android-focused development, I believe these things are likely just as related as they appear to be. I would have to dig deeper than scanning a few kernel changelogs to be sure, but as I understand it for about a year or two, Bluez has been undergoing a codebase overhaul. I expect that in such a scenario the Linux kernel's default Bluetooth stack would have to focus initial efforts on the Linux kernel's core x86 support, and especially providing ARM support would prove difficult due to its lack of a default firmware interface and handling the myriad hardware access mechanisms might just have been too much at the time. Again, these are my assumptions, but what has definitely happened recently is a concerted effort at full Android support. If my assumptions are correct, then probably the Bluez project just got caught up is all. In any case, the functionality Bluez provides, especially where networking transparency is concerned, is definitely superior. Find out for yourself if you'd like to know.
Surely I'll find out for myself soon, as I guess i'll be diving in after all. Never built Android from source before, which doesn't make much sense as I've had nothing but Android devices since my G1, every one of which, up to and including the Dream, was rooted and flashed with at least a replacement recovery pretty much on day one. I guess better late than never, though.
Back soon, I expect! Best wishes!
-Mike
I still use it because I really don't want to spend all the time ripping it out and replacing it with something else on my Ubuntu machines, but it consistently fails to operate properly on nearly every machine I have. It's way too complex and the end result is that it breaks all the time.
That said, because of my experiences with it, I will never personally put any effort into putting it into more places. It is in too many already.
*edit of this mistakenly resulted in double-post below*
Entropy512 said:
I still use it because I really don't want to spend all the time ripping it out and replacing it with something else on my Ubuntu machines, but it consistently fails to operate properly on nearly every machine I have. It's way too complex and the end result is that it breaks all the time.
That said, because of my experiences with it, I will never personally put any effort into putting it into more places. It is in too many already.
Click to expand...
Click to collapse
Maybe that's true, but if you asked me I'd probably lean the other way and say instead that Ubuntu is in too many places. Honestly, PA is really not complicated if you consider it a suite of core sound apps as opposed to a single, cohesive application. Probably my biggest gripe with Ubuntu's interfaces is that they often do the opposite, which is of course contrary to Unix principles, and in the process they tend to sort of opaque over simple and accessible modular designs.
I won't attempt to argue that PulseAudio is simple by design, as we both know I'd be certain to lose that argument, but it does offer a few lesser known interfaces you might find interesting. For instance, one of my favorite little tools is pacat. This does exactly what it sounds like; point it at one or more of PA's sources and it will concatenate their raw audio output into stdout at which point you are free to pipeline it as you would any other stream. Imagine you took pacat, perhaps also lz4, nc, and another little pipe-friendly PA tool called paplay directed at a PA sync on its system rather than a source, and combined them all into a pipeline. I hope in this you might begin to see some of PA's merits that perhaps you've missed before.
Also, there is pacmd, which is not nearly as straightforward as those others I've mentioned, but is far more capable and very well documented. It can do anything PA can do, really, and is fully scriptable.
I don't know which versions of Ubuntu you use, but those not on rolling releases may not yet have caught up to the PA update that implemented a PulseAudio-module-specific udev adaptation. Newer PA versions now pretty much auto-configure audio modules in the same way early user-space handles kernel-module loading. It's kinda cool, and almost an entirely hands-off process.
Anyway, I'm through proselytizing. I just thought I'd mention these things because they're the bits that I use when I want to do something with it.
EDIT:
Entropy512 said:
...because of my experiences with it, I will never personally put any effort into putting it into more places...
Click to expand...
Click to collapse
I looked again and noticed this. While I fully understand where you're coming from here, I thought I heard some French kid on YouTube say that this was not the sort of response that should be expected for OmniRom feature requests. He described a sort of democratically driven road map, and specifically he said that if a feature request was well enough supported by the users, then the developers would implement it even if they did not agree it should be done. Has this policy changed?
Of course I realize that youtube guy was probably talking about majority rule as opposed to a well-argued request, and that I'm only one person, but above you say you will never do this thing, without making any allowances for the possibility of a vote or poll or similar.
Like I say, I fully understand your position on this, as I, of course, do not intend to devote my own efforts to something like further Android fragmentation for instance, vote or no vote. I just wish to know what to expect here, and if maybe I missed something.
-Mike
Everyone on the project are volunteers. Time is a limited resource, and we tend to prefer working on things we enjoy since we're not getting paid for it.
There's a big difference between "I have no interest whatsoever in working on this myself" and "I hate this so much I will mercilessly -2 it without any discussion". The latter is what I've promised never to do.
If someone's going to implement a feature, I'm OK with that as long as it doesn't have significant negative impacts (which PA would likely have, but I'll give it the benefit of the doubt...), I'll even give them some tips/assistance.
However, given the pain and suffering I went through with the yamahell audio HAL, touching audio again if I don't have to is dead last on my priorities list.
Looking at your link - it seems like nearly any advantage PA might have would only be seen by commandline clients - All apps would have to be presented with something that is "audioflinger-like" which didn't offer the extra features offered to clients. Also, PA claims improved power consumption - but they actually likely do not support LPA or tunnel mode.
To me it looks like PA offers a huge integration effort for little to no actual benefit.
Also, that article was written in January 2012 - I can tell you for certain that Google made MAJOR changes to the audio setup with Jellybean in mid-2012 including the ability to select buffer configurations that are use-case-dependent - https://github.com/omnirom/android_...210153d8f19a0ca825b33f2282b9ae071c6ec#diff-11
Entropy512 said:
Everyone on the project are volunteers. Time is a limited resource, and we tend to prefer working on things we enjoy since we're not getting paid for it.
There's a big difference between "I have no interest whatsoever in working on this myself" and "I hate this so much I will mercilessly -2 it without any discussion". The latter is what I've promised never to do.
If someone's going to implement a feature, I'm OK with that as long as it doesn't have significant negative impacts (which PA would likely have, but I'll give it the benefit of the doubt...), I'll even give them some tips/assistance.
However, given the pain and suffering I went through with the yamahell audio HAL, touching audio again if I don't have to is dead last on my priorities list.
Click to expand...
Click to collapse
Wow, man! Thanks very much indeed for replying with honesty and humility. I'm very pleased that I didn't, or at least I hope I did not. Even if you had said otherwise I would have fully understood, of course, but as it is, I'm also very impressed. I like discussion. Thanks, man.
Two questions: what's yamahell? And, because you say you've worked with it, can you tell me about AudioFlinger or whatever it is and maybe why the status quo is desirable? I thought it was a problem. I'm asking these things for my own edification and because I think I'm gonna try something to do with a PA replacement.
While I agree PA may be overkill, I really don't believe pulse has to be applied monolithically, you know? It's already designed to work with modules, so maybe a subset would be sufficient. Clients only communicate with libpulse.so for the most part, for example. And for the past few months (on an upstream system) PA and Bz have been working really well together. So I'll try it, maybe, after you tell your horror stories and I can judge for myself.
-Mike
-
Entropy512 said:
Looking at your link - it seems like nearly any advantage PA might have would only be seen by commandline clients...
Click to expand...
Click to collapse
I assume you mean the first one, the blog on the initial port? Well, I believe that may have changed since then. The actual port homepage at freedesktop.org (the second link I provided) says this:
Code:
...[T]ested on Samsung/Google Galaxy Nexus as ... reference implementation... [P]ort fairly straight-forward for ... devices with ALSA support.
Various bits of functionality are available, and this is a moving target. The following are tested at the time of writing this section:
Audio playback for most apps using native Android APIs
Volume control
Switching of outputs depending on the device plugged in (headphones, headset)
To Be Done
The following pieces are either partially or not at all implemented
Audio playback API completeness: infrequently-used bits of the API (loops, markers, etc.) are not implemented
***BIG ONE*** Calls: this is work-in-progress, but needs to be cleaned and merged
Policy: initial implementations of volumes and port switching are done. There are probably a lot of bits of policy that still need to be implemented for us to have feature/bug-parity with standard Android.
Audio record API: can be implemented fairly easily like the playback API was
***NOT CLEAR ON THIS*** Audio effects API (we don't support this in PulseAudio at the moment)
Entropy512 said:
Also, PA claims improved power consumption - but they actually likely do not support LPA or tunnel mode.
Click to expand...
Click to collapse
Something tells me this is a statement I should be able to fully comprehend before getting neck deep...
Entropy512 said:
To me it looks like PA offers a huge integration effort for little to no actual benefit.
Click to expand...
Click to collapse
It doesn't look so huge to me, as much is already done, I think. But then I've to hear your horror stories so I will reserve judgement.
Entropy512 said:
Also, that article was written in January 2012 - I can tell you for certain that Google made MAJOR changes to the audio setup with Jellybean in mid-2012 including the ability to select buffer configurations that are use-case-dependent - https://github.com/omnirom/android_...210153d8f19a0ca825b33f2282b9ae071c6ec#diff-11
Click to expand...
Click to collapse
Yes, that article was written then, but the freedesktop.org homepage was created March of this year. I suspect some changes have accumulated along the way, and because PA is an actively developed high-profile application hosted and backed by RedHat, I expect that website landing page would be removed soon after it became irrelevant. I will, of course, reach out to the maintainers at that end as well for advice.
But... that's kind of the point... less redundancy, you know? Less fragmentation? No need for separate groups for thisnkind of stuff. I just thought that was inline with omni ideals. Is there another way that you know of that could as easily bring a like convergence of functionality with other Linux systems? I just wanted to effect something along those lines and I thought omni sounded like a place worth starting.
Also, I want those things.
-Mike
P.S. This is the git repo described in the .XML repo definition for the PA build-code at freedesktop.org: http://cgit.collabora.com/git/
You can see the android specific PA packages are being worked on, and very recently. Also, ALSA is seeing somewhat recent dev work as well.
EDIT: This may not even be quite as difficult as i initially assumed.You can also see at the following git repo that a commit was made to master referencing 'mako' 5 weeks ago.
http://cgit.collabora.com/git/android/platform/external/collabora/pulseaudio-android.git/
yamahell - the hell that was working with the Yamaha MC1N2 codec seen on many Galaxy S2 family devices.
Poorly documented, kernel code written by a member of a primitive tribe with no concept of zero, Samsung's blob HALs doing all sorts of unpredictable crap requiring workaorunds and hacks...
One of the things that the Android audio subsystem has (overall) great support for is hardware accelerated decoding of compressed audio. LPA and tunnel mode are both methods for doing hardware accelerated audio decoding even when the host CPU is asleep.
The closest analog to this in the PC world would really be AC3 passthrough to an external decoder - which happens to be where 90% of my hatred of PulseAudio comes from. Its usual response to AC3 passthrough switching on/off is to screw up the audio codec and do weird stuff like pass AC3 through but not set the "this is a bitstream and not raw audio" bit, or send raw audio when setting the "this is a compressed bitstream" bit.
Entropy512 said:
...no concept of zero...
Click to expand...
Click to collapse
....should I?
Entropy512 said:
One of the things that the Android audio subsystem has (overall) great support for is hardware accelerated decoding of compressed audio. LPA and tunnel mode are both methods for doing hardware accelerated audio decoding even when the host CPU is asleep.
The closest analog to this in the PC world would really be AC3 passthrough to an external decoder - which happens to be where 90% of my hatred of PulseAudio comes from. Its usual response to AC3 passthrough switching on/off is to screw up the audio codec and do weird stuff like pass AC3 through but not set the "this is a bitstream and not raw audio" bit, or send raw audio when setting the "this is a compressed bitstream" bit.
Click to expand...
Click to collapse
This makes very good sense. While I think the PA 4.0 changeligs from July or so may acknowledge this lack they also seem to indicate it's been addressed. Would you mind looking? Not positive I'm reading it right.
-Mike
I'm in the market for an eInk device to be used exclusively for non-ebook purposes. I need something with the battery life of an ereader as opposed to that of an LCD based tablet. My application does not require the flashy color, or the fast redraw of an LCD, it's simply going to be an interface for a control system of sorts. The UI will not require scrolling but be primarily page based, and no high frame rate video. The most advanced thing that might be displayed is the occasional slow update grayscale "video" (maybe a frame or two a second at the most but even that's not terribly likely). Touch is required and a lit screen would be a big plus (hence the list of devices I mentioned). I also require wifi connectivity, cellular is not important and would never be used.
I do like the idea of using a device that runs Android as it would give me a greater number of options for development. While I may stick with HTML5 and JS I also like the possibility of writing a true Android application. I'm not interested in Android Play or any of the other Gapps, though I suppose I could sideload them if I feel the need. I will most likely be running a very simple custom launcher so that the device operates more like a purpose built embedded platform rather than a general purpose Android tablet.
My question is what device would the experts here at XDA recommend I use? The Kindle has the benefit of the 800 pound gorilla that is Amazon but it doesn't run Android natively. Nook has the benefit of a decent sized company behind it, the fact that it runs Android, the downside is I'm not entirely clear on how long B&N will stand behind their eInk devices. Kobo is the little guy in the corner, I know next to nothing about the company, the build quality of the device, or the future of the eInk devices, but like the Nook it appears to run some version of Android.
In truth, it's not really all that important that the device I choose be offered forever. This is a personal project, nothing that's going to market. What's more important is hackability, Android, and at least the possibility for newer custom Android ROMs to be installed.
Thank you for your help.
--adam
P.S. If this is the incorrect forum for this I apologize.
I think a Nook and a native Android app will be fine for control purposes.
I'd avoid the whole HTML5 stuff.
It's easier to get lean, mean, responsive if you stay away from browsers.
There is already enough interchangeability among Android devices.
E-Ink options
True grayscale video of any quality would be a stretch as you'd likely be dealing with refresh flashing between frames at even 1fps. Every hack I've seen for improving refresh behavior involves switching to 1-bit color depth. Some solutions preserve the appearance of grayscale through halftoning like a newspaper photo at the expense of image resolution.
One thing's for certain about the Nook Touch series, you'll never get anything newer than android 2.1 on it. A number of closed binary drivers need to be replaced for truly custom firmwares and you'd be limited on RAM anyhow. You will not be able to expect B&N to stand behind the product line in the future. Note that the most recent 4gb NSTglowlight lacks an SD slot and is thus more difficult to root. That said, I'm very pleased with my Glowlight as a bare-bones Android device.
The Kobo Aura HD tablet would at least get you Android 2.3 and is rootable. I'm not certain how strong its developer community might be. One advantage over the Nook seems to be more even distribution of light across the display surface but I can't confirm from hands-on experience.
If you're comfortable with Linux, you might want to consider the Onyx Boox. There's at least a few scraps of information on the manufacturer's site about developing custom Qt apps for the Boox platform. Onyx has announced new tablets using Android but they don't seem to be available in the wild yet.
PocketBook out of Europe supposedly makes all sorts of e-ink Linux tablets, little, big, and waterproof; I'll be damned if I could tell you how to buy them though. Any evidence of purchasable shipped product I can find in English regards old models and dates from a couple of years ago.
Personally, I'm hoping the Earl GPS/walkie talkie Android tablet makes it out of vaporware.
dayofthedaleks said:
Note that the most recent 4gb NSTglowlight lacks an SD slot and is thus more difficult to root.
Click to expand...
Click to collapse
Not so. Now that the development on USB booting has been done, it's trivial.
See: http://forum.xda-developers.com/showpost.php?p=51742352&postcount=373
Renate NST said:
Not so. Now that the development on USB booting has been done, it's trivial.
See: http://forum.xda-developers.com/showpost.php?p=51742352&postcount=373
Click to expand...
Click to collapse
I stand corrected!
dayofthedaleks said:
I stand corrected!
Click to expand...
Click to collapse
Consider the Onyx Boox T68. Similar specs to Kobo Aura HD, and it runs Android 4.04. A bit more expensive, but maybe what you're looking for.
Sent from my T68Lynx using XDA Premium 4 mobile app
I echo the t68 comment. I got mine from Amazon a few weeks ago and it even shipped with prime shipping and was only $200. Totally worth it as an EReader. IDK of it would work for your purposes. But it comes with the play store and I haven't had any issues with it installing any app I've thrown at it.
Sent from my SM-N900T using XDA Free mobile app
This might help people eyeing the Z4 Tablet, but are unsure of what positives and negatives there are. Of course, this is highly subjective, but this is my list. It's influenced by my personal competing choices which were the Samsung Galaxy Tab S2 and the Google Pixel C. I'm happy I chose the Sony Xperia Z4 Tablet.
Pros:
Fast SoC (Qualcomm Snapdragon 810)
This is Qualcomm's 2015 flagship SoC and from what I've experienced it's really fast. Android flies. It also runs 64-bit, which it should anyway, but for example Samsung's Tab S2 doesn't. I don't know about the graphical performance as I don't really play games.
'Compatible' SoC (Qualcomm Snapdragon 810)
This opens up the way for optimized-for-specific-SoC apps (like RSBrowser, which is Snapdragon-optimized and significantly faster than stock Chrome/Chromium) and CyanogenMod support, that need documentation/drivers. For example, Samsung's (faster) Exynos SoC's are a black box for developers, which makes things like this very hard and has the result of devs abandoning it.
Big internal storage (32GB)
32GB is plenty of storage for apps and a reasonable amount of media. But that can be stored on the microSD.
microSD capability (up to 128GB)
This is a major benefit for a media consumption device like this, which many devices don't have.
Good multitasking
I could have mentioned 3GB RAM, but that doesn't tell the whole story. Multitasking on the Z4 is pretty darn good. It swtiches quickly and is generally very snappy. My Samsung Galaxy S6 with 3GB RAM has pretty bad RAM management in comparison. I'm still trying to find a custom kernel for it that keeps the phone snappy after 2 days.
Huge screen solution, high ppi on a big screen
2560x1600, 299ppi. On a big 10.1 inch screen. This is wonderful.
16:10 aspect ratio screen
Which is good for widescreen content like movies and dSLR photo's. 16:10 also beats 16:9 for me because of the added screen height.
Screen has natural, accurate colors
Very subjective, but compared to several other screens I've found this one to be superior.
Front facing stereo speakers
A rare thing among Android devices. Good design choice.
Lightweight (~390gr), thin
It's pleasantly light to hold.
NFC, notification LED, GPS, vibration motor
These features are often overlooked, but are important to me. I use NFC for LastPass, the (multicolor!) LED with LightFlow to see what exactly is asking my attention when in standby, vibration to still be notified when I want the tablet to be silent and GPS for the occasional navigation need or social app check-in.
Qualcomm Quick Charge 2.0
Another nice bonus, which isn't mentioned much. Quick Charge makes a major difference to charging speed. Needs a compatible charger though.
Big battery (6000mAh)
Can't yet say battery life is amazing, because I'm using it a lot and crank the screen brightness up quite high so don't know what to expect. Reviewers seem to agree it's great though.
Bootloader can be unlocked (so the road is open for rooting)
No waiting for an exploit if you're OK with going this route. Just follow Sony's instructions and you'll have root in no time.
Marshmallow announced
Should come January '16 I heard, but these things always get delayed :| At least it's coming.
AOSP commitment by Sony
Sony's Open Device Program is nice and all, but their sources are a bit troublesome and don't seem to produce functional ROMs. Still, Sony's stance on it might bode well for future things.
Water-/dustproof
I don't care much myself, but it's a nice bonus. At least it takes some worries away (dropping liquids on it, no fear for dust particles between the screen and the glass).
Keyboard dock option
Nice for when you want to use a physical keyboard that is fully compatible and is also attachable. I use a 3rd party BT keyboard, but I'm constantly fighting with fixing incompatible button mapping stuff.
Important root-specific things that work
These things are not guaranteed to work or be available on any rooted device, and are pretty major in adding possibilities, so I consider them pros to be working on the Z4T:
Xposed Framework
For most people anyway (Some are having issues). This is a thing to be happy about, because if it didn't, chances are it wouldn't be fixed anytime soon because of the small user/dev base. Xposed opens up many possibilities which really enhance a device. To me it's a selling point.
Native KCAL support
Another Qualcomm exclusive. I believe this is actually fully present on the stock ROM, but not fully controllable (limited to RGB in the Settings menu). KCAL support enables you to tweak various image parameters, like RGB, saturation and contrast with a tool like Color Control or Kernel Adiutor. It's pretty great and you don't see it often.
Cons:
SoC might overheat in extreme circumstances
Haven't had any problems myself, and I stress the tablet pretty hard, but I've read some reports about issues. At least of a guy bringing the tablet to the beach. It's mostly just people saying it's fine, even with heavy usage.
Speakers are lacking in bass
No surprise, but it's still a letdown.
Bad low-light camera performance, no flash
Picture quality in low light is disturbingly bad. Having no flash makes this unusable in those situations. Not a big deal for me personally, I don't take pics with a tablet.
Screen isn't that bright
Compared to several others, the screen isn't that bright and needs to be cranked up pretty much, even indoors. Outdoors, this is a problem. The big screen reflectiveness doesn't help either. Indoors it fine, it just that the needed high brightness level eats battery.
Screen lacks deep blacks
This is compared to (S)AMOLED, specifically. Those screen blacks are amazing and darker colors are also good for battery on those screens. IPS screens just don't have that. Using dark themes won't help battery life on the Z4T, it may even be worse with them.
Stock charger isn't Quick Charge 2.0
Come on, Sony.
No hardware navigation buttons
This is a real PITA for me because this requires Android's soft keys / navigation bar which take up valuable screen space. This is especially problematic in landscape mode on this 16:10 ratio in which you'll want every screen height you can get. Fortunately, this can be overcome by tools like GMD Full Screen Immersive Mode (with full screen keyboard typing restrictions so you'll have to switch back to type :S) combined with All in One Gestures, both of which don't reqquire root. Better yet is a build.prop edit that declares to Android the tablet has hardware buttons, removing the soft keys entirely, while keeping the ability to type anywhere. I navigate using All in One Gestures, because GMD GestureControl sometimes stops working. Which isn't very nice when you don't have navigation keys
No user-land root exploit (yet)
Because of this, you'll need to unlock the bootloader to gain root access. Which will destroy your TA partition, which will in turn remove Sony-proprietary functions. Which I personally don't use and don't see much use for anyway. Also, unlocked bootloader can't be undone without Sony noticing, so as a non-EU citizen you'll possibly have warranty issues.
Small user/dev community
Not many people own a Z4 Tablet (bad availability in the US and it's expensive) and because of this, there's next to no development for it. Luckily, we have @AndroPlus who's made a custom kernel and ported TWRP (which unfortunately has a bug that keeps us from restoring the system partition from a backup). @DHGE worked on root, which made it possible in the end I think. Still, custom ROMs would be nice. Also, if you run into device-specific problems, there's not many others that can help, because you're either the only one or one of very few who have that problem.
It's expensive
The price is very high and a bit hard to justify.
What I miss:
Wireless charging
This is sooo convenient. It also spares the precious MicroUSB port, which is used for charging, data-transfer, USB-OTG and adb/fastboot. If it breaks, you're done.
Removable battery
Batteries do not have eternal life, so eventually it will be completely dead. Which will render the tablet dead as well.
Any thoughts, questions, additions or critique is welcome.
jelbo said:
[*]Small user/dev community
Not many people own a Z4 Tablet (bad availability in the US and it's expensive) and because of this, there's next to no development for it. Luckily, we have @AndroPlus who's made a custom kernel and ported TWRP (which unfortunately had a bug that keeps us from restoring the system partition from a backup). @DHGE worked on root, which made it possible in the end I think. Still, custom ROMs would be nice. Also, if you run into device-specific problems, there's not many others that can help, because you're either the only one or one of very few that have that problem.
.
Click to expand...
Click to collapse
Hello jelbo. Let's discuss about it. First of all, our tablet is not alone with some sort of problem. z3+ and z5 devices are the same story. I don't really understand how can we have aosp sources but not to have its rom. So what the problem, some building problem, or is it true that aosp roms works without working sensors? People give different feedback. Did you try some aosp rom? I just want to cook aosp rom in ubuntu.
alex009988 said:
Hello jelbo. Let's discuss about it. First of all, our tablet is not alone with some sort of problem. z3+ and z5 devices are the same story.
Click to expand...
Click to collapse
Yes, they're similar. Which actually makes me think about a positive point as development for those devices can also benefit Z4T owners. For example @[NUT]'s efforts may eventually reach us, or when an Xperia user-land exploit is found, it will likely be shared among different devices.
I don't really understand how can we have aosp sources but not to have its rom. So what the problem, some building problem, or is it true that aosp roms works without working sensors? People give different feedback. Did you try some aosp rom? I just want to cook aosp rom in ubuntu.
Click to expand...
Click to collapse
I'm not too sure about the reasons, but what I've seen is that 1) the Sony sources are/have been a bit buggy/messy 2) not many people compile ROMs from it (I've only seen 2 XDA users and the FXP Team).
I haven't yet dared to flash any AOSP build because I've been too busy on getting stock rooted to my liking and troubleshooting my Xposed issues and I don't want to interrupt that. It seems to be quite easy to flash ROMs though, it's either a TWRP flashable .zip, Flashtool flashable .tft or fastboot flashable .bin files.
I'm also curious about the mixed reports about 'sensor stuff not working' and 'everything works fine' on Sony-sourced AOSP builds, but so far no-one has answered my or your questions about it. Seems we'll have too find out ourselves at some point Best leave that part of questions and discussion in their respective threads to keep things organized.
Nice summary, thanks for the effort; its clear and concise.
jelbo said:
it's either a TWRP flashable .zip,
Click to expand...
Click to collapse
I think free xperia team jeer at us cause twrp has a serious bug and it can't flash any roms for the time being whereas we can see exactly .zips at their site.
Interesting, had they even tested themselves what they uploaded
jelbo said:
Yes, they're similar. Which actually makes me think about a positive point as development for those devices can also benefit Z4T owners. For example @[NUT]'s efforts may eventually reach us, or when an Xperia user-land exploit is found, it will likely be shared among different devices.
Click to expand...
Click to collapse
I've put XZDualRecovery on 'feature freeze' for 2.8 well over a year ago, because it needs some work to keep it working on the ever changing Android eco-system. As a consequence, I also stopped adding devices to the supported devices list. For XZDR 2.9 things will change and I will start adding devices again, remember that I am just on my own, from time to time I have a helper but they generally drop out after a while and I'm on my own again after that... I have a busy real life and a very busy job, which consumes most of my energy, leaving only little amounts of it for use on the XZDR development unfortunately... and I have big plans with it which I'd rather deploy sooner then later.
As security features increase, so do the difficulties to keep XZDR working properly... For the Z3+/Z4/Z5/M4 Aqua it is dm-verity, which throws a tantrum once the system partition is modified, which in turn causes a reboot (and with that a bootloop). This behavior has hampered the Stock Based custom ROM development and made it generally impossible to root the device...
A backup-ta with a built-in root exploit (similar to the XZDR installer) to allow a backup of the TA partition would kick-start the development for these models. People don't mind unlocking their devices but do mind losing their warranty on a 500-700 euro device... so most of them wait for the possibility to backup their TA partition.
Oh, and to actually participate in this topic:
I have to say the Z4 tablet takes my fancy and tics just about all the boxes of things I like about tablets... I own a Xperia Tablet Z, well, the misses has it now and I can 'occasionally' touch it :silly: and I have been looking for a new tablet to actually use myself
I don't have the funds to purchase a TabZ4, but I would really like to have one with the keyboard dock
[NUT] said:
Oh, and to actually participate in this topic:
I have to say the Z4 tablet takes my fancy and tics just about all the boxes of things I like about tablets... I own a Xperia Tablet Z, well, the misses has it now and I can 'occasionally' touch it :silly: and I have been looking for a new tablet to actually use myself
I don't have the funds to purchase a TabZ4, but I would really like to have one with the keyboard dock
Click to expand...
Click to collapse
Hello. Thanks for participating our thread. Tab Z4 is a great device with cool hardware, but it is less developed in comparison with Samsung to my regret. All we want for this moment are a fix of bug for twrp, problem with mounting the system, and some customs roms. And the very big dream is cyanogenmod of course
@jelbo, where in NL do you live? Did you root your TabZ4 yet?
---------- Post added at 02:28 PM ---------- Previous post was at 02:26 PM ----------
alex009988 said:
Hello. Thanks for participating our thread. Tab Z4 is a great device with cool hardware, but it is less developed in comparison with Samsung to my regret. All we want for this moment are a fix of bug for twrp, problem with mounting the system, and some customs roms. And the very big dream is cyanogenmod of course
Click to expand...
Click to collapse
Well, I am assuming that custom ROM's will come as soon as there is a viable way to flash them
I wonder why @AndroPlus wasn't able to fix the TWRP mount issues yet...
alex009988 said:
Hello. Thanks for participating our thread. Tab Z4 is a great device with cool hardware, but it is less developed in comparison with Samsung to my regret. All we want for this moment are a fix of bug for twrp, problem with mounting the system, and some customs roms. And the very big dream is cyanogenmod of course
Click to expand...
Click to collapse
I'm pretty confident CM will support the 'karin' at some point. Many other Sony phones/tablets are officially supported.
[NUT] said:
@jelbo, where in NL do you live? Did you root your TabZ4 yet?
Click to expand...
Click to collapse
I'll tell you in a PM Yeah, I've unlocked my bootloader and rooted it. I couldn't restrain myself anymore It's so much better now. Just some littles gripes left that'll be fixed sooner or later.
Well, I am assuming that custom ROM's will come as soon as there is a viable way to flash them
I wonder why @AndroPlus wasn't able to fix the TWRP mount issues yet...
Click to expand...
Click to collapse
Time restraints, who knows? He did post a v11 version of the kernel some days ago though @dl12345 who greatly helped him getting TWRP to work, may be able to fix it, but he hasn't been around. You can follow some technical details about it in the AndroPlusKernel thread.
It's just /system/ that cannot be restored though. Which is bad, but you can get out of a bad situation pretty quickly with restoring /data/ and using Helium/Titanium Backup, I think. Unless you really fried the ROM and need your /system/ back, then you can only go the flashtool route now
jelbo said:
I'm pretty confident CM will support the 'karin' at some point. Many other Sony phones/tablets are officially supported.
I'll tell you in a PM Yeah, I've unlocked my bootloader and rooted it. I couldn't restrain myself anymore It's so much better now. Just some littles gripes left that'll be fixed sooner or later.
Time restraints, who knows? He did post a v11 version of the kernel some days ago though @dl12345 who greatly helped him getting TWRP to work, may be able to fix it, but he hasn't been around. You can follow some technical details about it in the AndroPlusKernel thread.
It's just /system/ that cannot be restored though. Which is bad, but you can get out of a bad situation pretty quickly with restoring /data/ and using Helium/Titanium Backup, I think. Unless you really fried the ROM and need your /system/ back, then you can only go the flashtool route now
Click to expand...
Click to collapse
* [NUT] pokes @AndroPlus to join this conversation.
Due to lack of time on my side to read the entire topic, what exactly fails when restoring system?
@jelbo, do you have his kernel installed (a.k.a. have you unlocked your bootloader)?
[NUT] said:
* [NUT] pokes @AndroPlus to join this conversation.
Due to lack of time on my side to read the entire topic, what exactly fails when restoring system?
@jelbo, do you have his kernel installed (a.k.a. have you unlocked your bootloader)?
Click to expand...
Click to collapse
Yes and yes. Basically anyone here who's rooted their tablet is running AndoPlusKernel and have manually unlocked their bootloader.
jelbo said:
Yes and yes. Basically anyone here who's rooted their tablet is running AndoPlusKernel and have manually unlocked their bootloader.
Click to expand...
Click to collapse
I see, that un-complicates testing a lot
Gotta say... amazing tablet all together and the first device that i havent seen the mighty snapdragon handwarmer throttle from heat in. I kept roasting it for about 3 hours with simpleplanes and PC minecraft (boardwalk app) and it didnt lose any performance just got a bit hot on the back middle. I find the battery life to be good enough for a day of being on and off watching youtube and occasional gaming but i do keep screen brightness on auto at all times and features such as BT NFC and GPS off. Also a app that i think the tablet should have from factory: OGYoutube, you can have floating resizeable youtube above other apps or play in background or with screen off and download in mp4 or mp3.
I'd picked up a Z4T about 4 months ago to replace two different devices, my aging and finally dead cell phone (I hung on to my old Samsung S3 for way too long), and my laptop, which is a still functional but extraordinarily heavy beast of a 17" macbook - about 6 years old on its own as well. What can I say, they were still working so why buy new?
I have to say I'm very glad I made the purchase. I picked up a SBH52 handset to make phone calls more convenient, and splurged on the sony docking kb for the added ruggedness of using it as a "case" - which it does like a champ. Calls are nice and clear, and I've had pretty much no troubles - aside from some occasional static when using the handset (which I owe to the handset itself being a bit flaky). Even with an unlocked BL, remote play on my PS4 still works, only the Bravia screen mirroring to my TV is kaput. It serves very well as a laptop for those like me that need something lightweight for overnight trips, let with a big enough screen to be able to remote desktop troubleshoot back to the main office.
Would this replace every computer I own? Obviously not. I still own a high end desktop for videos, games, and intense word processing (the sony kb is just a bit small if you were attempting to write a novel for example); and my PS4 for console games; but for light end use and for traveling, it's almost the perfect laptop replacement. And as a combo cellphone laptop? I couldn't ask for better. My overall data usage has also dropped, because I'm using far more wireless on this device (I want to make sure it's connected for the stability if nothing else), but I can always drop out to a cell connection if no wireless is available - or if I don't feel like paying the stupid prices at the hotel the convention is being held at.
Now for the Cons:
I've really only got two, one of which was mentioned here. The damn thing is not cheap. Since I live in the states, the LTE version is not available directly. You need to pick up an international version from amazon or another reputable source. Hence the reason I have a kb with extra non-english symbols on it. Not that I mind, but it confuses some people when they look at it. When I picked mine up, the tablet kb and handset ran about $900 US all together. so not something you want to accidentally brick, or drop, or leave behind in a restaurant....
The second one is convenience. Given that it is a tablet - and a fairly large one, most people aren't going to go the phone replacement route like I did. You can't exactly just slip it into your pants pocket. And since the handset is BT, you can't exactly leave the tablet in the car and just use the handset inside most restaurants either (unless you park really close to the building). I'll often leave mine at home if all I do is run to the store for a dozen eggs or something, just because it's easier not to pack it up. But then half an hour of being unconnected and out of touch doesn't bother me - it might bother some though.
So there you have it, a much less technical review, from yet another satisfied user.
begalund said:
I'd picked up a Z4T about 4 months ago to replace two different devices, my aging and finally dead cell phone (I hung on to my old Samsung S3 for way too long), and my laptop, which is a still functional but extraordinarily heavy beast of a 17" macbook - about 6 years old on its own as well. What can I say, they were still working so why buy new?
I have to say I'm very glad I made the purchase. I picked up a SBH52 handset to make phone calls more convenient, and splurged on the sony docking kb for the added ruggedness of using it as a "case" - which it does like a champ. Calls are nice and clear, and I've had pretty much no troubles - aside from some occasional static when using the handset (which I owe to the handset itself being a bit flaky). Even with an unlocked BL, remote play on my PS4 still works, only the Bravia screen mirroring to my TV is kaput. It serves very well as a laptop for those like me that need something lightweight for overnight trips, let with a big enough screen to be able to remote desktop troubleshoot back to the main office.
Would this replace every computer I own? Obviously not. I still own a high end desktop for videos, games, and intense word processing (the sony kb is just a bit small if you were attempting to write a novel for example); and my PS4 for console games; but for light end use and for traveling, it's almost the perfect laptop replacement. And as a combo cellphone laptop? I couldn't ask for better. My overall data usage has also dropped, because I'm using far more wireless on this device (I want to make sure it's connected for the stability if nothing else), but I can always drop out to a cell connection if no wireless is available - or if I don't feel like paying the stupid prices at the hotel the convention is being held at.
Now for the Cons:
I've really only got two, one of which was mentioned here. The damn thing is not cheap. Since I live in the states, the LTE version is not available directly. You need to pick up an international version from amazon or another reputable source. Hence the reason I have a kb with extra non-english symbols on it. Not that I mind, but it confuses some people when they look at it. When I picked mine up, the tablet kb and handset ran about $900 US all together. so not something you want to accidentally brick, or drop, or leave behind in a restaurant....
The second one is convenience. Given that it is a tablet - and a fairly large one, most people aren't going to go the phone replacement route like I did. You can't exactly just slip it into your pants pocket. And since the handset is BT, you can't exactly leave the tablet in the car and just use the handset inside most restaurants either (unless you park really close to the building). I'll often leave mine at home if all I do is run to the store for a dozen eggs or something, just because it's easier not to pack it up. But then half an hour of being unconnected and out of touch doesn't bother me - it might bother some though.
So there you have it, a much less technical review, from yet another satisfied user.
Click to expand...
Click to collapse
Thanks for sharing
So I am coming to this device from the Nvidia Shield Tablet and I love the device thus far for all of the positive reasons mentioned. Also with respect to screen brightness listed as a con my own experience is that it is much better than what I was coming from.
The battery life is truly great with this device and my needs are small when it comes to the development area. I simply need it to be rooted because I prefer to remove all of googles garbage that I don't use and rooting and bootloader unlock was very simple.
All in all I am really liking this device, had it about 10 days now. I have the LTE version but only because I may use it at some point.
Overall very pleased with the device so far.
ThePhoneGeek said:
So I am coming to this device from the Nvidia Shield Tablet and I love the device thus far for all of the positive reasons mentioned. Also with respect to screen brightness listed as a con my own experience is that it is much better than what I was coming from.
The battery life is truly great with this device and my needs are small when it comes to the development area. I simply need it to be rooted because I prefer to remove all of googles garbage that I don't use and rooting and bootloader unlock was very simple.
All in all I am really liking this device, had it about 10 days now. I have the LTE version but only because I may use it at some point.
Overall very pleased with the device so far.
Click to expand...
Click to collapse
I was seriously considering the Shield because of the dev scene and the price. What made you switch?
jelbo said:
I was seriously considering the Shield because of the dev scene and the price. What made you switch?
Click to expand...
Click to collapse
The device itself just isn't very efficient on battery and I needed something with a slightly larger screen. It does ok but it's really designed more as a gaming device IMO which wasn't what I needed. Also the specs are a bit outdated now.
I noticed in the op that he said being a non eu customer when unlocking bootloader they will notice. Im an eu user, does this mean that they wont notice if I try claim warranty after bootloader unlock? I havent unlocked yet but I was getting slow WiFi and disconnections. I really want root but im not sure about this WiFi issue I set the WiFi to turn off at sleep and it seems better also the issues are caused less im concerned what would you guys do? ive sent it off to Sony once already they said nothing was wrong with wifi. Can someone help me decide? Much appreciated, many thanks.
First off, let me make clear that this post is written purely from a developer perspective. As a user, I love the Pixel C despite its shortcomings, use it all the time (even if mostly just for web browsing, at the moment at least).
But as an Android developer (both OS and apps), the device makes it really hard to love it.
The Pixel C is, hardware-wise, and firmware-wise, a ChromeOS device. Not maybe, not used to be, but fact. It starts with using coreboot+depthcharge as the bootloader that only on the very top of everything boots Android, and goes over to the ChromeOS EC (Embedded Controller).
And it is this embedded controller, combined with the Tegra X1 chipset, that I have the most gripes with.
What is the EC? The EC is, somewhat contrary to its naming, not a "dumb" controller, but actually a fully-fledged system inside the Pixel C. It has its own CPU (a Cortex A7) and its own operating system (which is much much smaller than the OS the device actually runs, in this case Android).
The EC does basic things like partially controlling the boot sequence, and having direct control over auxilliary hardware like the device's sensors. That means that the OS has to rely on communication with the EC to make use of the sensors, and that is exactly how it is implemented in the Pixel C.
So what is my trouble now, finally, you might be wondering at this point.
Maybe some of you have noticed that over the course of the past weeks I tried to develop Double Tap to Wake for the Pixel C.
My initial approach was the same as on other devices: make sure the touchscreen still receives power and handles events, even if the screen is turned off. Then listen for gestures (like a double tap), and if a gesture is recognized, activate the device.
This didn't work out, because the Tegra X1 chipset is extremely strict when it comes to power management. Similar to the EC, you don't have direct access to the PMU (Power Management Unit), but rather need to go through the Tegra's PMC (Power Management Control).
Basically, while I've succeeded in keeping the touch screen awake after the device is suspended, it amounts to nothing since the Tegra can only be awoken by specific events when in LP0 state (Low Power 0). These events are already pre-determined by the firmware and can be hooked into through the DTB (Device Tree Blob) which contains hooks and information for the various kernel subsystems.
It does so for the PMC as well, but since the events are already hardcoded, there is no way to wake the device from suspend on a touchscreen event in a useful way, or at least not with the Linux kernel 3.18 used in the Pixel C.
So double tap to wake works, until the system goes into LP0 suspend, which happens very quickly after you turn off the screen if everything works well (no wakelocks or wake interrupts).
I gave up on that, and decided to implement double tap to wake through the mechanism the Pixel C already makes use of, as we all know: if you double tap on the back, OR the front, the Lightbar will show you the battery level.
It turns out that this feature is controlled by the EC, but since there is only access to the sensors via the EC, it is the EC and only the EC that can propagate the event to the host system, and possibly wake it up from suspend in case of a double tap.
I had, again, everything working: I've created a small framework overlay APK so you can enable wake settings in Android Settings, modified power.dragon and sensors.dragon (two Android modules that interact with various subsystems in order to control the devices state, and to read sensors, respectively).
Double Tap to Wake using the sensor worked!
Until... the system goes into LP0 again. It was very frustrating, and became even more so once I read the EC source code and realized that the event simply isn't hooked up into the host system on purpose, in order to enable the Lightbar tap functionality.
Now, I'm not saying that this all is deliberately created in such a way as to make development hard for the device. But none the less, it is.
In order to make this work (I don't see much of a chance for DT2W using the screen), I will have to compile my own modified EC firmware, flash it onto the Pixel C, hoping I didn't make some grave mistake that will blow my Pixel C up in smoke, something that I wouldn't have to do on a usual Android device.
As you can see, all this is becoming a little convoluted, hairy, and dangerous. It's akin to getting the mostly undocumented sourcecode for your Laptop's EFI BIOS, compiling it yourself, and then flashing it into your Laptop, hoping you compiled from the right version of the source code, you did everything right while flashing the new firmware, etc.
The next problem is whether this, flashing your own EC firmware, is even possible at all things given. The Pixel C has, like all ChromeOS devices (I'm staying with my point here), a Write-Protect mechanism. In the Pixel's case it's not a screw, but it is the front camera flex.
Only with the Write-Protect disabled you have full access to the device on a similar level which you would have on a normal Android device after unlocking the bootloader. But, in order to access it on the Pixel, you need to take off the screen. You'd have to heat-gun the front until the adhesive comes off, pry off the screen with bezel, disable the Write-Protect, and then somehow reassemble the Pixel.
I bet at this point many will agree that it's all a bit extreme just in order to get a feature like Double Tap to Wake working.
Still, I will be trying. But not today. And probably not tomorrow.
Over and out.
Great rant and information. I have been following your efforts and wanted to thank you. I can now understand the frustrations why it is more difficult than other devices. Thank you again.
Man... This is depressing. Here I was hoping this device was only a Pixel by name alone, and that it would function like any other Nexus device. That's a real bummer, as I was SO close to replacing my aging Nexus 10 with this. But, alas, maybe it just wasn't meant to be. I would've been willing to drop $600 on this, but not anymore. Unless they can magically flash PURE Android on this, and get rid of all the junk that ties it to ChromeOS, I'll probably pass. Or, maybe I'll pick one up after they start discounting it, realizing what a failure it was rushing it to market. It's a shame that other OEMs put a bunch of crappy UI skins on their tablets...
charesa39 said:
Man... This is depressing. Here I was hoping this device was only a Pixel by name alone, and that it would function like any other Nexus device. That's a real bummer, as I was SO close to replacing my aging Nexus 10 with this. But, alas, maybe it just wasn't meant to be. I would've been willing to drop $600 on this, but not anymore. Unless they can magically flash PURE Android on this, and get rid of all the junk that ties it to ChromeOS, I'll probably pass. Or, maybe I'll pick one up after they start discounting it, realizing what a failure it was rushing it to market. It's a shame that other OEMs put a bunch of crappy UI skins on their tablets...
Click to expand...
Click to collapse
I bought the Pixel C to replace my N10. The Pixel C is a great device ; however, it has some known issues right now (touch screen & wifi). They are working on software solutions for them. Cheep5k8 has done some great development work so far - root with custom kernel. There is also an unofficial TWRP available as well. I still would recommend the Pixel C, but would suggest that you wait until the major issues are resolved. You can also follow the development threads to see progress. There are some great developers working with the device, so we will eventually get some custom options even if they are limited in some aspects.
Wow I knew some software was left over from the Chrome OS but I didn't expect all of that!
God damn Google wth
charesa39 said:
Unless they can magically flash PURE Android on this, and get rid of all the junk that ties it to ChromeOS
Click to expand...
Click to collapse
This is not going to happen. It would require very elaborate and extensive work on the firmware to make it appear like a true Android device, something that is not necessary for the device's first line of sale, and is sure as rain not going to happen just for the aftermarket. To be honest, they've already done a pretty good job at masquerading it as an Android device in the very short time frame they had, and it's still way problematic.
Still, I feel, and I'm not really sure why, that we can fix at least some things wrong with this device, but it's so damn messy. I mean, why would you leave the Write-Protect enabled on a device that effectively runs Android, especially if it's impossible for normal users, and thus developers, to disable it. Who's going to take the screen apart just to have some features added? Probably only the most die-hard of developers, and sure as hell no casual users who just want to flash a ROM. Some input from the Nexus team would have been really appreciated here.
I'm gonna try my best, but the past few weeks have been extremely frustrating. I just kinda want to enjoy the device for now, and that's just not possible once you start developing on an OS level beyond minor modifications to the kernel, so I'm taking a break, taking the device as it is (which is easier than I thought it would be, perhaps because in theory it is such a wonderful device), and focus on other things for the moment.
hey cheep5k8, nice work on the pixel c so far. you should be proud of your efforts in bringing what you have to users of this device. Do you have any thoughts on why google did not, or could not, make the pixel c a chromiumOS device?
Personally, and I don't have extensive data to back everything up (Ars did a more thorough research, but then again, I went deep into the code and ChromeOS gerrit, etc.), this is my opinion:
I think until early mid-year 2015 the Pixel C was still running ChromeOS in Google's labs, and it was well planned to ship it that way. Somewhen around late summer, the device was adapted to masquerade as an Android device. I call it that because it still really isn't a real Android device. The kernel source is hosted on chromiumos git, and the kernel is as much a ChromeOS kernel as it is an Android one.
But why the change? We can mostly just speculate. I didn't find any direct evidence in git or gerrit, and I doubt the developers really had much of a choice in that. I'm also sure the reason wasn't a technical one; the Pixel C would well be able to run ChromeOS as is. Maybe someone will even try to port it.
It was most likely a business decision. Maybe because the attempts to make ChromeOS operate touch only were not successful from a UX perspective. The device was already being developed on with prototype boards in 2014. At that time, though, it was mostly the bringup, so no real UI yet (as far as I could gather from git and gerrit). But still, you don't develop an OS/interface for a device only to conduct UX tests almost before release, only to just scrap it, so this doesn't seem to be likely.
No, I think this was a decision related to the future of Android, ChromeOS or both. Maybe they didn't want to bring ChromeOS touch to devices in order to promote Android in that position. Maybe they thought that in order to better sell the device, a less experimental, and already better known OS would be more beneficial. But this was definitely a product management decision; the developers really don't have that much of a say into what the final product, in terms of being a product, should look like.
A last question I have been pondering, somewhat as a conspiracy theory, whether this has something to do with Sundar Pichai becoming Google CEO. Not to forget, he was (or still is?) head of ChromeOS development before becoming Google CEO. It's possible, but depends on the details. He was announced new CEO on 10th auf August 2015. IMO that would have been still enough time to convert the Pixel C to run Android (the changes are not really too vast). I think it would be doable in 2 to 3 months, with a large enough team, which Google certainly has. Maybe the fallback to Android had already been planned for longer, maybe for different reasons than the final decision, and maybe some Android-relevant/compatible code was already there. That would have shortened the timeframe, in which to convert the device to Android, by a good amount, and would have made a date of mid-August for starting the move to Android realistic.
EDIT: But then, Pichai announced the Pixel C, already running Android, on September 29th. Would a conversion of the device from ChromeOS to Android be doable in just 1.5 months timeframe? Possibly, but it would definitely be rushed. Though AOSP is pretty easy to handle and run on a device if you have the right drivers; this would have meant nvidia providing on their part. Coding a small layer for the EC to accommodate Android...... Maybe this is what happened? Who knows.
What really happened, precisely, is, at this time, anyone's guess. Anyone's but Google's.
there have been a couple stories written mid last year that google wanted to phase out chromeOS and someway merge it with android, then late last year stories that no, that is really not the case google is gonna continue to develop both OS's. assuming that the merge thing was really going on inside google maybe that had something to do with the pixel c mess. about the write protect screw, one thing i had been thinking about is to figure out how to build a small trap door of sorts in the back cover at the point of the screw while at the same time clearing the adhesive to make the remove/replace easier. then, do an exchange plus maybe $100 [to cover mod/shipping]. but before i even attempt to do one device as a prototype i need to see the ifixit or similar teardown to get an idea, after seeing the affected insides, if something like that is even doable. but in theory someone would send in their stock unit and get back the mod device which would have quick easy access to the wp screw, assuming at this point it is something that can be done.
Aka the tablet doesn't know what it should be?
The rush to change it to Android could also show us why it's such a buggy mess. they already said they were gonna launch it at Xmas so I wouldn't be surprised to hear that ti didn't get a proper QA acessment and was just pushed out when they got Android "stable" enough.
The fact it's taken this long for even a statement from Google about the issues is ridiculous and why is it taking so long to fix?
Roxas598 said:
Aka the tablet doesn't know what it should be?
The rush to change it to Android could also show us why it's such a buggy mess. they already said they were gonna launch it at Xmas so I wouldn't be surprised to hear that ti didn't get a proper QA acessment and was just pushed out when they got Android "stable" enough.
The fact it's taken this long for even a statement from Google about the issues is ridiculous and why is it taking so long to fix?
Click to expand...
Click to collapse
I've actually helped a volunteer at Google to debug the WiFi issue, since they knew of me and knew my device is rooted, so I was able to perform diagnostic tests from the side of the device.
It seems to be very difficult to fix simply because it was, so far, not clear what exactly the reason for the WiFi issues is. It doesn't really seem like (only) a hardware issue with lost reception. The WiFi interface also massively drops packets/needs data retransmits, something is going wrong but it's not clear if that happens at the hardware level, the firmware level, or the kernel level.
I also tried to diagnose and possibly fix the WiFi issue myself; so far, no luck.
cheep5k8 said:
I've actually helped a volunteer at Google to debug the WiFi issue, since they knew of me and knew my device is rooted, so I was able to perform diagnostic tests from the side of the device.
It seems to be very difficult to fix simply because it was, so far, not clear what exactly the reason for the WiFi issues is. It doesn't really seem like (only) a hardware issue with lost reception. The WiFi interface also massively drops packets/needs data retransmits, something is going wrong but it's not clear if that happens at the hardware level, the firmware level, or the kernel level.
I also tried to diagnose and possibly fix the WiFi issue myself; so far, no luck.
Click to expand...
Click to collapse
The WiFi issue is a strange one but I'm on my 2nd pixel and never had an issue with either of them for the WiFi and get max speed 2 floors away :S granted I'm using 5Ghz so not sure if that why. The only major issue is with the touchscreen (and sometimes lag) did you have a look at these at all?
With that WiFi issue people have do you reckon that is what's holding the update back so long? They seem certain the software is what's causing the screen to not respond.
Roxas598 said:
The WiFi issue is a strange one but I'm on my 2nd pixel and never had an issue with either of them for the WiFi and get max speed 2 floors away :S granted I'm using 5Ghz so not sure if that why. The only major issue is with the touchscreen (and sometimes lag) did you have a look at these at all?
With that WiFi issue people have do you reckon that is what's holding the update back so long?
Click to expand...
Click to collapse
I think that it is very difficult to fix, yes.
As for the touchscreen, my Xceed kernel has some patches for the touchscreen included from the chromiumos git which were not yet released as an OTA (I think), so maybe that would be worth a try.
cheep5k8 said:
I think that it is very difficult to fix, yes.
As for the touchscreen, my Xceed kernel has some patches for the touchscreen included from the chromiumos git which were not yet released as an OTA (I think), so maybe that would be worth a try.
Click to expand...
Click to collapse
I would give your kernel a go but I don't really want to mess around with the pixel C too much
As a whole i've kinda slowed down with doing anything to my Android stuff now.
I don't think those fixes have been sent out in the OTA but perhaps they were in the other factory image? I think chainfire said he flashed it and his touchscreen problems have yet to come back.
Roxas598 said:
I would give your kernel a go but I don't really want to mess around with the pixel C too much
As a whole i've kinda slowed down with doing anything to my Android stuff now.
I don't think those fixes have been sent out in the OTA but perhaps they were in the other factory image? I think chainfire said he flashed it and his touchscreen problems have yet to come back.
Click to expand...
Click to collapse
Possible. IIRC they were only recently commited, but somehow still might be in the new factory image.
cheep5k8 said:
Possible. IIRC they were only recently commited, but somehow still might be in the new factory image.
Click to expand...
Click to collapse
well if the new update isn't released soon I may just suck it up and start trying out things to help.
Thinking about it since fixes were pushed to the Chromoniumgit is this tablet always gonna contain stuff from ChromeOS?
Roxas598 said:
well if the new update isn't released soon I may just suck it up and start trying out things to help.
Thinking about it since fixes were pushed to the Chromoniumgit is this tablet always gonna contain stuff from ChromeOS?
Click to expand...
Click to collapse
It can't not be a ChromeOS device. The entire board, basic hardware and firmware setup is built like a Chromebook. It has the Chrome EC, it starts up (boots) like a Chromebook, etc. This can't be realistically changed.
The "only" things really different from a Chromebook are:
- It is a touch-only device (there's the Chromebook Flip but it at least also has a keyboard)
- The storage partition layout has been partially changed so that Android can deal with it
and
- Instead of, at the very end of the boot sequence, booting ChromeOS, it boots Android. But actually, this is the least spectacular and least intricate part about the Pixel C's nature (even though of course a complex matter from a pure Android point of view). Both ChromeOS and Android use a Linux kernel. I'm not even entirely sure whether the Pixel C kernel contains any greater Android-specific adaptations that make it different from a ChromeOS kernel, aside from having a slightly different build configuration. When the Android kernel finally boots (from inside a ChromeOS boot image, may I remind you), it just expects to find a specific partition layout, which is there, and not the biggest problem to arrange. And after that, it just needs the right drivers, and it runs.
So, yes, the Pixel C is very much a ChromeOS device.. a Chromebook without keyboard, if you will, even if there are some people adamantly claiming the opposite. It just happens to run Android.
cheep5k8 said:
I've actually helped a volunteer at Google to debug the WiFi issue, since they knew of me and knew my device is rooted, so I was able to perform diagnostic tests from the side of the device.
It seems to be very difficult to fix simply because it was, so far, not clear what exactly the reason for the WiFi issues is. It doesn't really seem like (only) a hardware issue with lost reception. The WiFi interface also massively drops packets/needs data retransmits, something is going wrong but it's not clear if that happens at the hardware level, the firmware level, or the kernel level.
I also tried to diagnose and possibly fix the WiFi issue myself; so far, no luck.
Click to expand...
Click to collapse
Thank you for this post, information, and your efforts! It really sounds like this is a Frankenstein device. I returned mine because I didn't have confidence the google devs would be able to fix the poor wifi (especially wireless N) any time soon as they were requesting debugging reports from users here:
https://productforums.google.com/fo...ce=footer#!msg/nexus/CM9tv3pjTfQ/QY0xGoTMAgAJ
There were simply too many problems. I had wifi and touchscreen issues on both units I tried. Again, thanks for the info and effort. I keep reading about this device with hope it all gets fixed but that seems like it might be a while.
cheep5k8 said:
It can't not be a ChromeOS device. The entire board, basic hardware and firmware setup is built like a Chromebook. It has the Chrome EC, it starts up (boots) like a Chromebook, etc. This can't be realistically changed.
The "only" things really different from a Chromebook are:
- It is a touch-only device (there's the Chromebook Flip but it at least also has a keyboard)
- The storage partition layout has been partially changed so that Android can deal with it
and
- Instead of, at the very end of the boot sequence, booting ChromeOS, it boots Android. But actually, this is the least spectacular and least intricate part about the Pixel C's nature (even though of course a complex matter from a pure Android point of view). Both ChromeOS and Android use a Linux kernel. I'm not even entirely sure whether the Pixel C kernel contains any greater Android-specific adaptations that make it different from a ChromeOS kernel, aside from having a slightly different build configuration. When the Android kernel finally boots (from inside a ChromeOS boot image, may I remind you), it just expects to find a specific partition layout, which is there, and not the biggest problem to arrange. And after that, it just needs the right drivers, and it runs.
So, yes, the Pixel C is very much a ChromeOS device.. a Chromebook without keyboard, if you will, even if there are some people adamantly claiming the opposite. It just happens to run Android.
Click to expand...
Click to collapse
Yep I totally understand now. Man what a Frankenstein tablet but as long as they fix the issues with touch and some lagging here and there I'll be totally happy with it (as long as multi window is in N)
But since its a ChromeOS device could say Google release a flashable Chrome OS for it that would work? For people who have the keyboard anyway. Not saying they would but I'd much prefer Chrome OS tbh
Roxas598 said:
Yep I totally understand now. Man what a Frankenstein tablet but as long as they fix the issues with touch and some lagging here and there I'll be totally happy with it (as long as multi window is in N)
But since its a ChromeOS device could say Google release a flashable Chrome OS for it that would work? For people who have the keyboard anyway. Not saying they would but I'd much prefer Chrome OS tbh
Click to expand...
Click to collapse
Yes, they theoretically could very much do so.
We all love the Nook but it's getting kind of old in the tooth.
Ok, the Glow4 (7.8") finally upped its game to 1 GB RAM, but that was kind of necessary.
It also added Bluetooth, something that could have been done cheaply and easily to earlier models.
Although I'm no fan of using the latest and greatest Android version, 4.4.2 is getting a bit old.
I understand that this is a tough business where every little part on the BOM (bill of materials) will hurt you.
Still, using single core processor is so yesterday. A Raspberry Pi Zero has quad core for $10-15.
To my mind a 6" 300 DPI reader is about optimal for flowing text reading.
For frequent or work PDF reading I'd want a 10" 300 DPI reader instead of high power reading glasses.
The 8" reader seems to fall uncomfortably in the middle.
The Kobos are Linux based, not Android.
Onyx has some decent choices in their (confusedly similar) product palette.
The older stuff has Android 4.4, the newer stuff Android 9.0
They have quad core and even octa core.
The "Poke 2" looks pretty nice for a 6", but why did they have to add the silver styling?
https://onyxboox.com/boox_poke2
(Oh, well, some sandpaper and a can of black spray paint would fix that.)
As I am in love with the Aard dictionary, my NST has been simply wonderful. But I understand Kobo no longer support an SD card. Where to now?
Same boat. I just got rid of my GLP BNRV510. Hated the light grey, small dictionary font. Also reading PDF seemed to convert those documents to oversized images. My NSTw/GL was awesome. I was going to upgrade to the new NGLP7.8 but the specs and issues with overheating are a turn off. Also I have read reviews stating that you can't side load books anymore? This may also apply to the GLP BNRV510 with the latest firmware update too. Which eReader now?
The Glow2 (BNRV510) is my main read.
If I have to read a PDF, I read it in landscape at two "chunks" a page.
I wouldn't think that B&N would try to lock down sideloads and I don't anticipate it would be hard to defeat.
I hope not but I understand the arguments for your question. To be honest NST as it was not my first choice (first choice was some Sony model) but I love it now. Last time I checked Kobo Aura looked nice but that was long ago and I do not know how things look now on the market.
Recently I was scrubbing my head around this issue. How I see the problem with NST? Well B&N locked out anything and everything humanly possible to prevent users doing something they did not wanted them to do. Devs unlock most of the obstacles out of protest or because of challenge ahead. As it runs ancient version of Android apps are scarce and disappearing fast. Writing an app dedicated for NST might be an act of love toward hardware base made by dedicated fanatic but we can assume there are not to many such individuals around today as Rennate said Nook is old.
So without further ado there are few roads as I see that could be taken if NST is to continue ahead.
1. Upgrades to Android version as far and much its hardware allows and using slightly more up to date apps for it (like CM11 approach running from SD card allows).
2. As Android is just an overlay on Linux leave it as is for B&N sake and good sleep but make some dual boot solution that will actually allow us to boot Linux (something in the line of Ubuntu for devices but not exactly so because as far as I remember that work only for versions of Android above 4) as that could give user maximum possible ability to customize it for his/her use.
3. Just say bye to B&N and build new NST OS from scratch be it Linux or another version of Android as that might be easier due to a clean slate/paper ahead and being less bound to a obstacles made by B&N.
4. It might be possible to create also dual profile on the current NST OS but given its restrictions that might not be of some great use - (B&N profile and user profile). What other forum members think about it?
P.S. I did not want to create separate thread about this and this thread seemed to fit in the general idea of talk about it. I hope Rennate wont mind.
Nah, I don't mind.
I use the same reader app on my Glow2 and everything else, including my $70 Walmart Onn 8" tablet.
Even a cheap-o (single CPU) tablet has 2G vs the Glow2's 0.5G
For better or worse, people like the Android ecosystem as a way to make apps.
Of course, Google & Co are working on making everything ginormous and expensive.
(And adding even more pointless animations.)
It's always a question of how much work you want to put in to fight annoying things.
Renate NST said:
Nah, I don't mind.
I use the same reader app on my Glow2 and everything else, including my $70 Walmart Onn 8" tablet.
Even a cheap-o (single CPU) tablet has 2G vs the Glow2's 0.5G
For better or worse, people like the Android ecosystem as a way to make apps.
Of course, Google & Co are working on making everything ginormous and expensive.
(And adding even more pointless animations.)
It's always a question of how much work you want to put in to fight annoying things.
Click to expand...
Click to collapse
I am glad that you do not mind and find this discussion still within topic you started.
As always you hit problem in the head with much less words then me. I have always wondered what are the limits of hardware requirements needed (minimum) for some tasks/programs to run reliably. And we see that people test those boundaries each day.
You are correct that Android had given people app making opportunities. Sadly recent trend is to take away that from us on old devices as this one. I agree that "awww look its so shiny and buzzing" might look nice but regarding information value its pretty much crap (no way to put it politely sorry). Information is what the people using books/ebooks find to have some merit and it is in the form of text, graph, still picture mostly. I accept that sometimes video can be better tool for presenting certain information but general trend is not in that direction. Information in any shape and form I will accept gladly. Sad truth is that today we have to duck and fight against flash advertising and eye candy web UI of very little value and dubious quality.
I have some doubts what would be the most likely way to continue that is why I made that post. If it was my thread I would make a poll but even here I am willing to hear what is your opinion? Amongst four options I wrote up what would you most likely choose as a way forward? Also if possible please explain why.
1) I think doing an upgrade of Android version on an older device is a bunch of work and hardly justified.
2) I'm not a fan of dual boot. I like to keep things simple. Especially on my main reading device where I just want to pick it up and read.
Android "Linux" has quite a few different things than normal Linux. If you want Linux, get a Kobo.
3) Porting something new to the NST is a lot of work. See #1
4) I don't see the necessity of dividing profiles. I also don't understand what you're looking for.
Ok, I'm a fan of the NST, but it's had its day. The Glows have better resolution and backlight.
You get your choice of capacitive (Glow2) or IR (Glow3) touch screen.
The Android 4.4.2 on the Glows is not so bad yet. (The NST Android 2.1 makes life difficult.)
I think more memory, Bluetooth and a better processor would be on my wish list (in order).
Yes, the Glow4 has Bluetooth.
With enough effort you can fix any little technical thing in life that annoys you.
(I just spend this morning grinding and filing down a piece on my brand new guitar because I couldn't stand the design.)
It's a question of time and also how many people your effort would help.
I think an Onyx Boox is in my future, but I wish they didn't have so many silly models.
It's funny, I still use my original Nook Simple Touch, but a few times a year I find myself curious and looking to see if there's a perfect e-reader out yet for me to upgrade to. In the end it always just seems like nothing is really so much better that I really want to buy it, though.
In particular, page refreshes and overall responsiveness, which are the main things I'd like to be better, still just haven't improved enough on affordable e-readers, in my opinion. A backlight would be kinda cool, but hardly seems like a big deal since personally I'm still pretty used to reading real books, which obviously don't have built in lighting either. I guess a higher density screen might be nice, but I can't say I really notice it on my NST. Newer Android? Maybe, though I've really always been able to find an app that does what I need and works on the NST even with Android 2.1, so I'm not sure what the advantage would be.
I'm a pretty light user of my Nook, though, I guess. Most of the time I'm just reading epubs or sometimes pdfs (scientific papers, which are usually published as double columns, so they work just fine on the NST screen), plus the occasional word games or round of picross here and there. Someday I'm sure I'll upgrade to a new reader, but I think it's gonna be a while at the rate the technology has been improving.
You have stated all valid points here. I understand them and agree to most. Maybe I should explain in more details my points.
I use NST as is. Still restrictions imposed on user by B&N are frustrating sometimes. I mentioned upgrading Android on the device only because its own base is abandoning 2.1 and cutting of access to application made for this version. I have nothing against sideloading apps but if the source to such apps is going to dry out it might be a time for a change. Theoretically with slight upgrade of Linux kernel on it upgrade to gingerbread/honeycomb looks doable. Is it worth the effort is a valid question and that is exactly what I am asking for opinion here.
I am mostly using an OS from that Redmond firm. Although I want to learn and use Linux more I am certainly not looking into using it on e-reader despite it is possible to do on Kobo. Point of dual boot would be to leave B&N stuff as is and do on Linux what you like. At least on Linux you would not be that easily cutoff from apps you want/need. Again looks doable but I am not sure if it is recommendable. Reason for me to considering this is that more and more I read about trying to write/rewrite an apps for this device. Even I have started something similar to porting Linux program to Android and being frustrated by next to nill progress so far started to wonder am I doing it backward and should I run Linux on NST and program in the environment it was written for.
I am surprised Renate is not for whole new OS because the way I see the things she is already halfway there with all the apps she wrote for NST. . I know OS is another matter but let's face it it was half baked product to begin with. I mean Phone.apk really? On a device without sound support! And that app control volume? Man B&N really had shoestring budget for software developer and had us use port of some phone OS instead writing dedicated stuff.
I find multiple profile least advised on such low power device but I could see its merit here and there. I have a cousin which would be happy if she had kids profile on its phone as that would prevent paying triple digit roaming charges. NST most likely do not have the power to pull of multiple profiles although in theory something like that could be made even for Eclare in some crumbly way.
NST have resolution just above low printing and we love it. If some device could achieve 300dpi and have larger screen A4 size preferably with A5 being minimum that would be awesome. There are few device on market Remarkable and Sony with 10 and 13.3 inch screen but they cost still an arm and a leg. Although they shifted concept more toward notebook/sketchbook I have no problem with that but e-book support is next to nothing PDF only if I remember well. I am old and I like to use "pen" on "paper". I will look about other device mentioned. Aura H2O did caught my eye once to be honest.
Now I hope you can see my points more clearly. I find this discussion fruitful. Even if we do nothing we at least have fresh input from others to tickle little gray cells.
As far as upgrades go, upgrading to anything less than Lollipop (5.0) is pretty pointless.
That's already five years old as it is.
As bloat is a given, you're always going to need more memory and a faster processor.
If you want to learn about Linux a Raspberry Pi is certainly an economical solution.
For ~$15 you can get a Raspberry Pi ZeroW.
Android *nix deviates a lot from Linux but mostly in system and startup issues.
You can cross-compile C programs on your Windows box using the the Android NDK and run them in the command line on your Nook.
You won't have direct access to the screen unless you want to write to /dev/graphics/fb0 yourself.
If you don't want the Android layer running at that time you can just turn it on and off with "stop" and "start".
You might try to get into writing regular Java (or Kotlin, but don't get me going on that) applications.
There is something to be said for having your own app that runs on both your phone and your Nook.
There's a lot of convenience in having whatever you're looking for on whatever device you have at the moment.
I always though that backlights were pointless, but I've learned to love them.
If you have copier paper a lot of it is 92% reflective.
The white in eInk is a lot grayer than that.
I always keep my backlight on, but only to the point that it makes up for the gray tint to make it white.
Looking at it you really don't get the impression that it is glowing.
I have stumbled on web page of a project to port some 4+ Android version on NST which pretty much surprised me. Can not remember was it ICS or JB and hell Kitkat would be awesome for device that old. I believe that for that they must abandon B&N stuff almost completely unless they somehow ported it back from Glow versions? And counting in size expected I bet that they reformatted partitions on the device to make it happen. Now will that stick together or fall apart spontaneously is another question. I remember that on xda that somewhere was a thread about disabling OTA from B&N that could brake such upgrade but since they no longer support NST we should not worry about this. I wonder why did you said Lollipop as minimum choice? Do you consider it as minimum acceptable Android version or maximum that NST could possibly run?
As far as Linux go nah I will just play with old laptop instead. Although I caught myself looking to buy present for nephews in electronic realm. Arduino or Pie? aye there is the rub...
I didn't program anything reasonable for a long time. Therefore I am more than rusty in that field. Although I believesome Python or lua script I could manage if enough effort is put on my side.Julia look to me as a programming language that shows some promise to the future from old man perspective. Certainly none of those are useful to porting anything to Android and NST. For the moment I cut my appetite back and will look into how I can backup NST and make virtual image out of it to run it in Virtual box. There I hope to try to learn how things work on Android an play/apply changes in the sand boxed environment. If I break something no harm done just delete virtual drive and start again. I don't want to brick my only NST. Maybe I should buy used one for latter to as I see lot of UK used one have hit the market after B&N closed in UK.
I hate Java from reasons unwilling to disclose or as you said let's not start about that. Idea behind it is fine. Sadly it is lot to be desired on the implementation side. I totally understand that Java might give some benefits especially if we count in the already existing base of programs written on Java. Have a friend who learn and use Java but I personally never manage to overcome my personal detest of it.
Regarding backlight... I never saw Glow. Is there true backlight in like shining through panel? Or did they made something in line of those book lights for real books? I think that could work for capacitive screen but not so much so for IR like NST have. That should not glow much I think and could be regulated in illumination and colour.
The NST has 256M RAM, the Glow2/3 has 512M, the Glow4 has 1G, my $40 phone has 2G.
The $60 Kobo I have has only 256M, but it just runs Linux.
I couldn't be bothered to update my NST even if you handed me an image on a platter.
ebay has the Glow4 (open box) for $130.
I wouldn't even try to update that to a newer version, too much work.
Since this thread started the Boox Poke3 6" reader has come out.
It has Android 10, 8 CPUs, 2G RAM, Bluetooth and lists for $190.
That's a heck of a lot more of a device than the Glow3 for $120.
It also doesn't have the ugly styling of the Poke2.
https://www.boox.com/poke3/
Hmm, currently not in the US warehouse.
I'm a big fan of Arduino and RPi, but it gets complicated.
An adult friend bought an Arduino, hooked up an LCD and a thermometer, loaded the sketch.
It worked. They got bored. End of the story.
I don't know what the solution is. You make it too easy, they get bored. You make it too hard, they get frustrated.
I'm not a fan of the whole Arduino infrastructure and the Processing language. I prefer just AVR8. But I am "old skool".
I use RPi a lot, but I've only seen the desktop version about once.
I use headless and also digital signage without X Windows or desktop.
The Glow2 has single color edge lit backlight, The Glow3/4 uses dual color (blending) edge lit backlight.
If you hold them sighting down the face of the screen at a very low angle you can tell there are discreet LEDs.
(It's nothing you could ever see in normal usage.)
I checked Boox first time you mentioned it. Impressive progress I must say. Paradox is that as I understand newer Android versions are more optimized to be run even on underpowered devices but I agree that NST is both old and underpowered. Still even you mentioned that Kobo has same low memory but still running successfully Linux only environment. That speaks a lot in Linux favor regarding resource management and use. Yes there are slim chances someone cook something up for NST and even then people will just buy new device that is several times better. You wouldn't believe but B&N readers are hard to find here. I had to ask a friend to bring me the one from Middle East because it was available there so go figure.
Thanks for the opinion about Arduino vs RPi. I think you might be right. Kids nowadays will be interested to program more than to assemble something and experiment. Its a shame because I think they could learn more about physics by fiddling with Arduino.
Thanks for explaining me or rather confirming how light on Glow device is made. I am curious how they sorted out possible interference of lighting with IR touchscreen but I guess they somehow used non overlapping LEDs for those two separate things or passthrough IR only filters on IR detector side. In theory even some simple software calibration could work for that but I am also an "old skool" and wouldn't choose that as my way had I have gotten the task to build something of this kind. I might rig me some "lights" for old fashioned hardcopy books. Not that I can't buy it online but I want to engage my fingers a little.
If you haven't played with it yet, the Touch-1.0.apk (in the sig) works on the NST and will show you how/where the beams of IR go.
It can be helpful to see where dirt or distortion of the bezel is making it difficult for touches to be registered correctly.
Since the party seems to be going into a topic of what next best e-reader should be maybe we could exchange opinions about certain things available as in are they necessary or good enough at this moment. For example Boox is offering a model that can show ebooks as black and white or I presume as 4 color "print". As B&W it present it as 300dpi which is on par with printed books and man can not ask for more in my opinion. Alas when it present 4 color "print" it is meager 100dpi that could mean even NST just blows it out of scene. So my vote on color e-reader is still no. If it ever reach 150dpi it will become a thing to consider but right now it is still under acceptable performance from mine point of view.
Do you consider making notes on a device important? I am asking because I have mentioned ReMarkable and Sony DPT (which is gone now). Sony again made good device only to withdraw from the market at the end. While I understand that in the e-reader case as Amazon blow them out securing the better library this time I am afraid it is Sony's own fault. There exist few rebranded models of hardware Sony used with seemingly better software Fujitsu Quadreno and Mooink Pro. Mooink support PDF, epub, docs and text and offers a software for file conversion and DRM management. There are few annoying things. Almost none have microSD card option now. It is replaced with cloud storage or printing. And I personally like having pen but I find being robbed when they sell it separately and with replaceable tips because they made those to wear out. Cost is way to high despite larger screen.
I'm not clear on what you mean with "4 color".
The only thing that I can see on the website is a way to save your scribbles to an external file where you can set the color saved (but not viewed) on the device.
If you've ever seen a store white/red/black eInk shelf label update you'll know that that's only useful for things that change once a day.
I don't look too closely at the reader software itself since I'll probably just use my own.
I hate the sort of pictograph selection of small, medium, large font.
What if I want 5% larger than medium?
There's always a bit of conflict between SD card and waterproof.
I figure 32 GB fixed storage is large enough for me.
There's always a big tossup what is the correct mix of devices, phone, ereader, tablet, tablet with pen, tablet with keyboard, laptop, desktop?
I've never owned a personal laptop, never seen the sense (for me).
Rarely do I use a tablet or a phone with a BT keyboard when I want to do some sort of bulk inputting or fleshing out an idea or transcribing lyrics.
I kind of like digitizers, but never found a way that the utility exceeds the space they take.
Onyx Boox Poke 2 Color is for example device able to reproduce color. Yet is it worth buying?
Yes I understand your choice to use custom reader software. File support seems to have always been a problem and it just went worse from there.
Yes waterproof device shouldn't have SD card. I have mean more in a sense of having the ability to root, backup and thinker with the device.
SJT75 said:
Onyx Boox Poke 2 Color is for example device able to reproduce color.
Click to expand...
Click to collapse
The product selection of Onyx or Boox or Onyx Boox has always confused the heck out of me.
Currently on https://www.boox.com/allproducts/ there is no indication of anything color.
Moreover, the "About Us" speaks of "We focus on E Ink ( ePaper) devices only. "
But I do remember seeing something previously on the website that spoke of color.