Related
Honestly if i get flamed its bs but what ever.
My question is will the Dream just be ignore in the future for the basic fact that we can't update our hardware, while Google pushes out UI's like Rosie and more sophisticated one's in future. We've already noticed how much it lags with Rosie whats going to happen in 8-12 months when phones like the I7500 come to play with better hard ware and they make updates to those. Will the G1 suffer and thus be stuck on roms like CupeCake? I mean we are already seeing the limits that it can handle without to much lag.
Like any piece of hardware, it gets outdated. However as long as dev are kind enough to work on new ROMs for us, most likely there will be new additions, widgets, applications etc for us to use in the future.
I'm quite excited by the multi-core ARM-X processors coming out for mobile devices, plus more powerful GPUs (the iPhoneG S has a scaled down version of what's to come next year!) and hopefully Android can support such processors too.
For us G1 owners at the moment though you might as well enjoy it. I mean I don't believe I've owned a mobile previously where we had so much choice between ROMs and how fast development is... (*looks at Sony Ericsson with their slow P900 firmware upgrades, Nokia N95 Symbian upgrades etc*).
I think you're going to see the "base" Android experience (the Launcher, the bundled platform apps, etc) will require more or less the same level of computing power in the future as it consumes today. It's good practice to keep a consistent, maintainable standard and then build from there. So that's what you're seeing with Rosie, where 3rd parties like HTC add on these gaudy and poorly programmed interfaces. By producing these inefficient and cpu-intensive apps and interfaces, HTC can essentially nudge you to hardware upgrades.
But the core of Android, the stuff that comes out of 1600 Ampitheatre Parkway, should remain runnable on Dream for atleast a while. Google is aiming to have Android be a general purpose embedded systems operating system. In order to be flexible to all the types of devices Android can potentially run on, it has to have a relatively low baseline.
What you said. I think we'll see a longer life of the G1 than we've seen with past phones because of the degree of flexibility we have with it. Of course there are going to be things designed for better hardware that we won't be able to use, but Jashu's right. Not all hardware that comes out running android is automatically going to be better than the G1. As long as there's devs that have a G1, you'll continue to see development for it.
jashsu said:
I think you're going to see the "base" Android experience (the Launcher, the bundled platform apps, etc) will require more or less the same level of computing power in the future as it consumes today. It's good practice to keep a consistent, maintainable standard and then build from there. So that's what you're seeing with Rosie, where 3rd parties like HTC add on these gaudy and poorly programmed interfaces. By producing these inefficient and cpu-intensive apps and interfaces, HTC can essentially nudge you to hardware upgrades.
But the core of Android, the stuff that comes out of 1600 Ampitheatre Parkway, should remain runnable on Dream for atleast a while. Google is aiming to have Android be a general purpose embedded systems operating system. In order to be flexible to all the types of devices Android can potentially run on, it has to have a relatively low baseline.
Click to expand...
Click to collapse
imbonez9 said:
Honestly if i get flamed its bs but what ever.
My question is will the Dream just be ignore in the future for the basic fact that we can't update our hardware, while Google pushes out UI's like Rosie and more sophisticated one's in future. We've already noticed how much it lags with Rosie whats going to happen in 8-12 months when phones like the I7500 come to play with better hard ware and they make updates to those. Will the G1 suffer and thus be stuck on roms like CupeCake? I mean we are already seeing the limits that it can handle without to much lag.
Click to expand...
Click to collapse
Funny you should mention the i7500... it is essentially the same as the *lower spec* htc magic, i.e. the same chipset, cpu. Actually, it has *less* RAM than htc dream (128 vs 192) -- magic comes with 192 or.. 288 (depending on what the provider ordered). The main advantages are that its got more flash onboard (though it is yet to be seen if the whole flash is usable for app installation or if it is restricted to some small amount), slightly better camera with flash, and OLED capacitive touchscreen (vs TFT/LCD capacitive). In all, the lower RAM will make it perform WORSE than any of the current HTC-android devices, including the Dream.
Have a look, its not that impressive: http://www.gsmarena.com/samsung_i7500-2791.php
funny when i read this. week old news with direct impact for us and a clear message. "we will never properly support our products after sale has been made"
samsung_announces_new_high-performance_nand_memory
same old samsung. make advances on a hardware front and current users of your old nand memory solution a.k.a. Galaxy S ... hope to fade into the past with its stepbrother i8910.
Lag has to do with the filesystem used to store apps, not slow hardware.
not so sure. read carefully them admitting that older generation has issues with read and write at the same time.
"Previously the e-MMC 4.4 interface has offered designers the flexibility of partitioning storage, such as using the single-level cell (SLC) area for high speed operations and the multi-level cell (MLC) area for high density data storage. Now, the new chips (adhering to the new e-MMC 4.41 interface standard) provide a significantly upgraded user experience, with a high priority interrupt (HPI) and improved background operation features.
Embracing the new standardized features, the latest Samsung moviNAND chips enable more efficient processing of orders. If the host wants to execute an application or read data while the e-MMC device is writing data, the host can send an HPI command to the device so that the device stops previous writing to respond to the newest command. Using this feature, the host can receive the device's response without any latency.
Also, when the Samsung embedded memory is not in operation, the host can command it to utilize the free time for background operations such as garbage compaction, so that the embedded memory can reduce the write latency."
by telling us what the new chip can do it also reveals what the older one can not.
lagfixes do help somewhat (with the benchmarks and in real life for the first few days then lag starts popping out again) but im sure samsung chose rfs for a reason whatever that may be and after 2 bricks im not discounting that lagfix had no part in it. all i know now is that im on a third phone, avoiding froyo and lafixes till the torrent of brick posts wanes down. my third phone running fine after multiple flashes.
You are making assumptions. Samsung are only starting to produce 16GB chips this month. Are you saying Samsung should have delayed product launch for 3 months? I don't know what kind of tech company you are running, but you are mad if you think that delaying products for every hardware change possibly will allow your company to survive.
Also, an improvement to writing speeds doesn't mean the old ones were bad. It simply means the new ones are better.. The only real change is the possibility to interrupt writes, and we don't know how long it takes to write a block of data (maybe not enough to present any benefit except realtime operations).
I agree entirely. Improvement make things better, not the previous ones bad. If you wish to wait for such a time that gadgets will not get better before buying, then you will NEVER buy.
Galaxy S is a great phone. Its screen makes the screen of my HD2 look defective!
well the original lag fix has worked for me on two phones and it does not start coming back as long as you keep memory free.. (the fix that moves /data/data to dbdata...
you need to keep an eye on free size but i have no issue with 100 apps installed
The lag is caused by the bad choise of file system. They use RFS and thats why it lags. Henche why the lag fix moves the data to a ext2 partition. The amazing thing is why sammy didnt do this in the first place. But i guess thaysen part of the charm in droids.. you get to fix things your self. Maybe even learn some.. i was a complete linux ignorant before, but now sgs tought me at least the way around its core fine system.
Sent from my GT-I9000 using XDA App
I am not Apple fanboy, but i think that Anddroid OS has a big optimisation problem.
For example the iphone 4S had a CPU 800 Mz and it seem to be real fast. But the latest Androphone plan to use Dual CPU. Is Android OS needed more ressources than iOS?
Before make effort to get more material ressources, is n't time for google to optimise his OS ?
Symbian was an OS whitch was too optimsed and i would like to have an Android OS like that.
Someones wouldnt like what i said but it is my deep think.
+1 BRO !!!!
I really dont know why the **** iOS is that smooth, never noticed any lag on an Iphone. But you should think about that : Every Phone needs his own setup, caused of CPU, GPU and other things like ram and so on....
every iPhone got the same setup, optimized for iPhone 4 , iPhone 3GS and so one. They all got the same CPU and GPU, so they really can tweak every singe hardware.
Google just give us a source code, which every Company, Like Samsung or HTC have to port on their new device...
By the way, HTC got much better optimized Original Roms than Samsung. ( I have seen some OFW running on HTC Desire, and they are very smooth... )
lascoul said:
....
Before make effort to get more material ressources, is n't time for google to optimise his OS ?
.....
Click to expand...
Click to collapse
It is same way as MS passed: one simple question to you: how would you like to optimize the OS against HUNDREDS of available hardware combinations?
Of course, the Apple choice is easy and smooth: ONE hardware set, ONE OS.
similar was already done by Ford with model T: everyone could have it with favourite colour, as long as it was black. and now the ford position on global market is...
it's easy to optimize a software for 1 device but for 10000+ devices it's not that easy
dadyal said:
it's easy to optimize a software for 1 device but for 10000+ devices it's not that easy
Click to expand...
Click to collapse
If google doesn't optimise the OS. He may do it for his phones. take a look at the future Nexus prime it will get a dual core CPU. But don't think that is necessary if the OS is much optimise. The ipohne 4S had only a CPU at 800MHZ
spamtrash said:
It is same way as MS passed: one simple question to you: how would you like to optimize the OS against HUNDREDS of available hardware combinations?
Of course, the Apple choice is easy and smooth: ONE hardware set, ONE OS.
similar was already done by Ford with model T: everyone could have it with favourite colour, as long as it was black. and now the ford position on global market is...
Click to expand...
Click to collapse
But a think that the OS is not optimise for googles phones. Otherwise why will they use a dual core CPU in Nexus Prime?
I thought the difference in speed was because of the way they handled multitasking. It was only recently that iOS even had multitasking. But this is probably just a part of the reason why iOS is faster.
lascoul said:
If google doesn't optimise the OS. He may do it for his phones. take a look at the future Nexus prime it will get a dual core CPU. But don't think that is necessary if the OS is much optimise. The ipohne 4S had only a CPU at 800MHZ
Click to expand...
Click to collapse
iPhone 4S: 1 GHz dual-core ARM Cortex-A9 processor
They both have dual-cores.
Yea ios is optimized better. But it also doesn't have many basic features like android. Like a proper customizable homescreen with the ability to chose your launcher (no, lockscreen and an app tray are NOT an homescreen like apple has been trying to sell it), widgets, proper multitask, proper application integration, live wallpapers, lack of an external SD, etc. That makes for a lightweight system. You gain speed but lose features.
That said, granted, android needs to be generic. But as soon as a big company like samsung picks up android and starts developing to one device of their own making, this "1 OS for all devices" gap ceases to exist. Its 1 OS being optimized to a single piece hardware, and they have all they need for proper optimization.
This isn't the same as windows -> 1000 kinds of hardware. Windows comes prepared from Microsoft to run everywhere so that applies. Android doesn't come prepared to run everywhere from google. You can't simply just download and put it on your phone regardless of brand. Has an extra step of preparation from hardware developing companies like HTC or Samsung.
What i'm trying to say is, there is room for optimization. But companies don't care much because they are on a tight schedule on market competition to put out the next big thing, have hardware specs to compensate for poorly optimized coding and in the end stuff works just the same, since most people, sadly, won't notice or care that much for those extra delays/lags.
Can't speak for other brands, but Samsung proved with SGS they don't care much for good coding. The community has been, since its release, improving this phone leaps and bounds and continue to do so even though a successor has shown up.
At the end, companies don't care enough, imo.
kaynpayn said:
What i'm trying to say is, there is room for optimization. But companies don't care much because they are on a tight schedule on market competition to put out the next big thing, have hardware specs to compensate for poorly optimized coding and in the end stuff works just the same, since most people, sadly, won't notice or care that much for those extra delays/lags.
Can't speak for other brands, but Samsung proved with SGS they don't care much for good coding. The community has been, since its release, improving this phone leaps and bounds and continue to do so even though a successor has shown up.
At the end, companies don't care enough, imo.
Click to expand...
Click to collapse
i am aggre with u. The compagny must provide us much optimise Room before growing the specs of the phones.
lascoul said:
I am not Apple fanboy, but i think that Anddroid OS has a big optimisation problem.
For example the iphone 4S had a CPU 800 Mz and it seem to be real fast. But the latest Androphone plan to use Dual CPU. Is Android OS needed more ressources than iOS?
Before make effort to get more material ressources, is n't time for google to optimise his OS ?
Symbian was an OS whitch was too optimsed and i would like to have an Android OS like that.
Someones wouldnt like what i said but it is my deep think.
Click to expand...
Click to collapse
Iphones are smooth because iOS was designed to work on one device (technically, 9 devices if you count all the variants of iphones, ipads and ipods) only whereas Android has to work on hundreds of devices with different processors and hardware.
Also, iOS removes so many functionalities from the user, hence has more free ram.
disclaimernotice said:
Iphones are smooth because iOS was designed to work on one device (technically, 9 devices if you count all the variants of iphones, ipads and ipods) only whereas Android has to work on hundreds of devices with different processors and hardware.
Also, iOS removes so many functionalities from the user, hence has more free ram.
Click to expand...
Click to collapse
The job of compagnies like SAMSUNG, HTC ... isn't to optimise the OS for they devices? To say that there are more devices is not an apologizes
First step then should be: CLOSE the system. Lock it all, and after that, you can optimize system individually for each phone, completely separately. Another option is to push Samsung, HTC, LG, SE or whoever else to have SAME hardware configuration.
Then: you will loose:
- all custom ROMs, bootloaders, CWM, root, kernels;
- all customized versions of stock apk's, like phone, start screens, themes, Market etc.
- ANY ROM update will be available only after OFFICIAL release, through Kies.
Well, xda does pretty good work with optimization, while Android is kept OPEN, not locked, like iOS.
I personally prefer that it will continue this way.
---------- Post added at 06:40 PM ---------- Previous post was at 06:37 PM ----------
lascoul said:
The job of compagnies like SAMSUNG, HTC ... isn't to optimise the OS for they devices? To say that there are more devices is not an apologizes
Click to expand...
Click to collapse
??? Why are you stating that they are not doing this? But, one thing: DO NOT flash everything available here, but just stay with OFFICIALLY released ROM's, via Kies (in case of SGS).
For example: JVR, JVS, JVT ROM's are not officially released, and then any claim that the sys is not optimized is pointless.
Whilst the first post is correct regarding speed and optimisations they fail to realise that Apple have only their own hardware to work on, so they can really work it until its perfectly optimised.
Google have one device to work on, but multiple manufactures use their open source platform using different hardware, so its up to them to optimise the software for their hardware, not google.
You also failed to quote correct hardware specs for the iphone, which has dual core and I believe as much memory as the galaxy s2... So it does sound like your trying to bash android with incorrectly informed arguments.
Just to close the item, and to proof how optimised the IOS is, the recent update, iOS 5, caused vanishing of the music, files, messages, contacts, customised folders and applications for not very small group of users:
Brilliant iOS5 update, example 1
Error 3200 and 3004
3002, 3200, 3194
So, I think that the conclusion may be:
Apple has much more simple way to optimise their sys, because they have much less kind of hardware than Google.
But, Apple is not able to manage even so small amount of the hardware variations, and iPhone CAN go smoothly on its 2 cores CPU (yes, dear OP, read the specs more closely) if Apple will not mess the sys or its update... what just happened.
It's only multitasking problem.suspend and resume of iOS paid off better although you miss some features because of that but on all basic features it way better.
I always wonder why dialer and messaging apps sent out of memory,they should have been kept in memory like browser.
We shouldn't be nagging much about it as things can be done by Android are much more.
Sent from my GT-I9000 using Tapatalk
I can't predict the future of course, but it is not unlikely we will see some performance increase with ICS.
I would deem it likely that ICS will use HC's memory manager which is definitely faster than GBs, especially when used with programs that are massive memory hogs. HC's still constantly frees memory it doesn't need to free though ( == waste of cycles), so there is still room for improvement there, let's hope ICS brings it.
Likewise, UI hardware acceleration is already better in HC than it was in GB, and it is rumored to be further improved in ICS. If that is true, ICS devices will likely seem much more fluent. It doesn't actually make them faster, but it will look that way.
In the end, iOS is much more optimized than Android, but ICS should be a good step in the right direction. It will probably not bring the optimization to an iOS level, though.
kaynpayn said:
Yea ios is optimized better. But it also doesn't have many basic features like android. Like a proper customizable homescreen with the ability to chose your launcher (no, lockscreen and an app tray are NOT an homescreen like apple has been trying to sell it), widgets, proper multitask, proper application integration, live wallpapers, lack of an external SD, etc. That makes for a lightweight system. You gain speed but lose features.
That said, granted, android needs to be generic. But as soon as a big company like samsung picks up android and starts developing to one device of their own making, this "1 OS for all devices" gap ceases to exist. Its 1 OS being optimized to a single piece hardware, and they have all they need for proper optimization.
This isn't the same as windows -> 1000 kinds of hardware. Windows comes prepared from Microsoft to run everywhere so that applies. Android doesn't come prepared to run everywhere from google. You can't simply just download and put it on your phone regardless of brand. Has an extra step of preparation from hardware developing companies like HTC or Samsung.
What i'm trying to say is, there is room for optimization. But companies don't care much because they are on a tight schedule on market competition to put out the next big thing, have hardware specs to compensate for poorly optimized coding and in the end stuff works just the same, since most people, sadly, won't notice or care that much for those extra delays/lags.
Can't speak for other brands, but Samsung proved with SGS they don't care much for good coding. The community has been, since its release, improving this phone leaps and bounds and continue to do so even though a successor has shown up.
At the end, companies don't care enough, imo.
Click to expand...
Click to collapse
Disable to slight extent. I felt that Samsung have done something to the ROMs they provide for SGS. Example the old RFS filesystem, lags like hell in the past but feels good now. Im using RFS instead of EXT4. Still, I have to agree, they don't care much on good coding, new phones are coming up, why bother? The community makes it happen
Apple hires a ton of CPU architects solely for this purpose. Apple prioritizes fluency and optimization above features and openness.
Just a different strategy, no better, no worse.
Sent from my GT-I9000 using xda premium
My mate has the latest iPhone his wife had the SGSII, I had the chance to compare them both side by side last night. What can I say except the SGS is larger, faster, smoother, has more apps, more customisable, the difference is amazing. The iPhone is like
a kiddies toy compared to the SGS.
Remember that the iPhone has been going a lot longer than Android, yet Android had had voice recognition for over a year. Enough said
Sent using TCP/IP
hi there
just wanna know if it is possible or not to upgrade smartphone hardware like in desktop computer... etc ?
thx devs
With the exception of Project Ara, no. The reason for this is because, as smartphones are designed to be light on space, and extremely efficient, almost all of the components are directly soldered to the motherboard, and are so small that they're almost transparent when you look at them from the side. Therefore, until modular phones are available, this is both impossible and impractical.
Yes it actually is,but many people say its not.If you have phone like for example galaxy s 3 and yoy whant to have more ram you can find out ram fot galaxy s 4 and change it.It has the same size but im not sure is any phone service doing that.U can upgrade normal memory with SD card,if you still whant more you can buy bigger SD card.I think that noone needs SD bigger than 8gb
Sent from my SM-G355HN using XDA Premium 4 mobile app
QwerLoL said:
Yes it actually is,but many people say its not.If you have phone like for example galaxy s 3 and yoy whant to have more ram you can find out ram fot galaxy s 4 and change it.It has the same size but im not sure is any phone service doing that.
Click to expand...
Click to collapse
So tell me more, I'm a little skeptical about what you said...
Knowing that the RAM is embedded in the same chip as the CPU and GPU (SoC) (Exynos 4412 4 on SGS3 and Exynos 5410 on SGS4). You are saying that the consumer or a repair shop can remove the 4412 from a his SGS3 and replace it with a 5410? Even if both chips aren't the same architecture? Are they soldered to the motherboard?
Would love to see some references...
U can upgrade normal memory with SD card,if you still whant more you can buy bigger SD card.I think that noone needs SD bigger than 8gb
Click to expand...
Click to collapse
Yeah obviously, not really an upgrade to the phone memory itself but more like adding on some parallel memory. And not all phones can use sd cards, even some high end phones can't.
Parallel memory isnt possible to add right now,maby it ll be possible for few years but not now :/ That what i said for RAM cant really help you.I said its possible to change ram but not like in home.There are some companies making phones with material you whant (u tell them how much ram and internal nemory you whant,soo its the same phone with changed ram memory) there are some Chinese companies what are doing that i hope you can understand what i was trying to say... Andswer for your first question is No you cant change ram and int mem by your self tell me what ever you whant about hardware and ...other rooting,unbricking things...
Sent from my SM-G355HN using XDA Premium 4 mobile app
so maybe forget about project ara as this phone will not have the design like iPhones... nexus phones with that gorgeous design... etc
Software UPGRADE
_PR3DATOR_ said:
hi there
just wanna know if it is possible or not to upgrade smartphone hardware like in desktop computer... etc ?
thx devs
Click to expand...
Click to collapse
My friend i tore up over a dozen android devices in last 6 months . To my suprise no two devices are using anything compatible with another. cleaning up bloatware and excess junk files along with some system tuning and i think youll be Suprised at what these devices can actually do and perform on a 15$ single core 4.0 ics device you can listen to music while downloading more while you browse the web and screen record it all at the same time. unless your trying to do serious graphical gaming on your phone while multitasking i think your good with anything 4. and up. System Tuner Pro rom toolbox pro check it out and enjoy my friend sd read speed has been default 128kb/s on my devices (a must change) Benchmark app hey
Android device are often using SoC solutions. (SoC: System on a Chip)
That means the whole system, CPU, GPU, RAM, wireless networks, bluetooth, Storage, I/O, GPS, Sensors, etc... are all integrated into one single chip. It is that what makes smartphones so efficient in power consumption and size.
There are other support-chips around the main SoC chip, but these usually handle lesser functions such as extra storage space, USB on the Go functionality etc...
Read on: http://en.wikipedia.org/wiki/System_on_a_chip
SysGhost said:
Android device are often using SoC solutions. (SoC: System on a Chip)
That means the whole system, CPU, GPU, RAM, wireless networks, bluetooth, Storage, I/O, GPS, Sensors, etc... are all integrated into one single chip. It is that what makes smartphones so efficient in power consumption and size.
There are other support-chips around the main SoC chip, but these usually handle lesser functions such as extra storage space, USB on the Go functionality etc...
Read on: http://en.wikipedia.org/wiki/System_on_a_chip
Click to expand...
Click to collapse
HI,
so, maybe is it possible to install a more powerfull camera module on a device like Htc One S?
For exapmle a front camera (from HTC One Mini) of 2Mpx instead of 0,3mpx camera of Htc One S.
Must I port libraries and Api to make it work? Or is it impossible?
Cusciolino said:
HI,
so, maybe is it possible to install a more powerfull camera module on a device like Htc One S?
For exapmle a front camera (from HTC One Mini) of 2Mpx instead of 0,3mpx camera of Htc One S.
Must I port libraries and Api to make it work? Or is it impossible?
Click to expand...
Click to collapse
Technically it is possible. But practically "doable" I'm not so sure of.
Most android-devices happen to use a common "camera interface" for the camera hardware-module.
But the layout, form factor, connector placement etc can be very different between the various Android models out there.
One cannot simply take a camera module from one model, and fit it inside another. Just the connector itself alone can vary heavily between models, not to mention the "flat flex cable" arrangement.
These reasons alone make it very hard to fit one camera module inside another device.
But let's pretend that one can find a camera module that does fit perfectly inside the phone in question, or that one is skilled enough to perform the modifications needed:
The Linux Kernel module.
Yep. The linux kernel need something too. It's not all plug'n'play with embedded situations such as smartphones. These devices aren't built for plug'n'play in mind. They are statically built. Once compiled, it's snug as a glove. Nothing more, nothing less.
But it's not all darkness around. Luckily the linux kernel is open source. Even when it comes to Android devices.
One can simply download the linux kernel source from the manufacturers web site, and import it to the Android Development Environment that one has prepared for this.
Next thing to fetch is the source code for the new camera module. This can be quite tricky, and is a show-stopper in many cases. Manufacturers often refuse to release these sources, and Android open source world end up with a "crippled state" for the module in question. Blame the hardware manufacturers for this.
But let's pretend that one have a camera module that happen to have its kernel driver "open source". Then one only need to download these sources, and patch them in.
Once the linux kernel has been patched, and the new camera module is available in the linux kernel configuration, one only need to enable it as a "module", and compile it.
Once compiled, one will end up with a "camera_module.ko".
This particular ko-file is what one need to transfer to the Android device in question, and tell Android init to load it.
Now... it should work... but it rarely does in real life. As you mention, there might be some special API and other stuff needed for the software in order to access the camera.
Once again: read the documentation for the camera module in question, and hope that the manufacturer of the camera module have used a commonly used API, and not a proprietary one.
That is enough of me babbling on about this. This is not supposed to be "absolute facts". These lines written are more meant as a general pointer of "what to expect if one tries".
Maybe someone else, more experienced in these matters, can shed some more light on this. I could be wrong.
SysGhost said:
Technically it is possible. But practically "doable" I'm not so sure of.
Most android-devices happen to use a common "camera interface" for the camera hardware-module.
But the layout, form factor, connector placement etc can be very different between the various Android models out there.
One cannot simply take a camera module from one model, and fit it inside another. Just the connector itself alone can vary heavily between models, not to mention the "flat flex cable" arrangement.
These reasons alone make it very hard to fit one camera module inside another device.
But let's pretend that one can find a camera module that does fit perfectly inside the phone in question, or that one is skilled enough to perform the modifications needed:
The Linux Kernel module.
Yep. The linux kernel need something too. It's not all plug'n'play with embedded situations such as smartphones. These devices aren't built for plug'n'play in mind. They are statically built. Once compiled, it's snug as a glove. Nothing more, nothing less.
But it's not all darkness around. Luckily the linux kernel is open source. Even when it comes to Android devices.
One can simply download the linux kernel source from the manufacturers web site, and import it to the Android Development Environment that one has prepared for this.
Next thing to fetch is the source code for the new camera module. This can be quite tricky, and is a show-stopper in many cases. Manufacturers often refuse to release these sources, and Android open source world end up with a "crippled state" for the module in question. Blame the hardware manufacturers for this.
But let's pretend that one have a camera module that happen to have its kernel driver "open source". Then one only need to download these sources, and patch them in.
Once the linux kernel has been patched, and the new camera module is available in the linux kernel configuration, one only need to enable it as a "module", and compile it.
Once compiled, one will end up with a "camera_module.ko".
This particular ko-file is what one need to transfer to the Android device in question, and tell Android init to load it.
Now... it should work... but it rarely does in real life. As you mention, there might be some special API and other stuff needed for the software in order to access the camera.
Once again: read the documentation for the camera module in question, and hope that the manufacturer of the camera module have used a commonly used API, and not a proprietary one.
That is enough of me babbling on about this. This is not supposed to be "absolute facts". These lines written are more meant as a general pointer of "what to expect if one tries".
Maybe someone else, more experienced in these matters, can shed some more light on this. I could be wrong.
Click to expand...
Click to collapse
Great Explanation! Thank You a lot! I think that is not in my capabilities to do that but.. maybe I'll try when I have some freetime
thank you
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.