Related
As far as my stock quantum goes, I really can't complain about wp7. Great features, flows great, everything I could ask of a marketplace based OS. I got the phone knowing it would be locked down, but hoping the possibilities would grow. I do miss the seemingly endless capabilities wm offered though. Access to all resources, running native apps without the need to sideload.
I noticed a month or so ago a few guys in the forum were discovering ways to gain higher priveledges within WP7 and with the little knowledge my noob self has, have looked into the differences between wm6 and wp7, new kernel, beeing sandboxed and whatnot. And im curious, are we waiting for m$'s release of limited native code execution to oem's to be exploited, or is there an update in the privilege adventure?
With the amount of wp7 devices released and soon to be, I doubt I can look forward to an exploited bootloader to run a custom rom on my first gen wp7 quantum (such as a tricked out wp7 or possibly wm support...?), but a ported version of haret to run xdandroid as I did on my diamond would be exceptional, and from what I understand not too impossible considering wp7 uses ce7 (not sure if there's backward compatibility for ce6 though). We would just need a new UI, and an understanding of the device specific hardware for support in android...?
Where do we stand on any of these options, are they likely or if so, nearing?
I can understand your frustration with the restrictions on WP7 but for most scenarios, access to native APIs isn't that essential in my opinion (and I have been developing on WM6 myself). WP7 uses WinCE 6.0 R3 and not CE7. The Windows Phone team do recognise that they have been quite strict with the exposed APIs and I am sure that was a combination of fear of what developers write (in terms of crashing your phone) and work need to be done with Silverlight for WP. Mango brings new low level functionality and should be made available soon - Sockets been the first that comes up in my mind. Is something wrong with sandbox solutions? I believe not
For any other reasons I probably wouldn't have much to say on the subject, but I've always been one to tinker with my Xbox, psp, router, anything fun. If I can get more functionality out of it, I look for a way. Unfortunately I am not skilled enough to make it happen, so I look upon the gurus. In this case I consider dualbooting wm or even starting android from within the current OS as expanding possibilities. Which is why I look for answers to my question. Any answers?
I am not a developer so I don't understand why it is so hard to receive updates on some android devices.
Today, particularly I am concerned with the ICS update . Why is it that even though TF meets all the hardware requirements it still can't receive ICS?
To a n average user like me this is like saying "we both have similar computers but Windows 7 won't work on yours and it's nothing do do with hardware".......
it is not the same at all. For windows computers all of the components are supported by their respective manufactures and all of those manufactures write the drivers for the operating system. By doing this you can install windows (or linux) on most platforms because of the cumulative support. In android there are many more steps. Most drivers have to be written by a single manufacturer which may get hardware from other manufactures but they do not provide software support for that hardware. writing those drivers takes some time and implementing them into each release of android as it changes the parameters it accepts ect. then each device has to be tested rather than just testing one part to make sure everything is in order then it goes through google who do even more checks to make sure that it is near perfect before it is released to the general public
It is possible to get 3 different phones with ubuntu phone now, none of them too expensive.
good.
i wonder what people's experience or informed opinion is?
ubuntu is pushing "convergence", which basically means that one operating system runs on all devices, that i can use my smartphone as a computer...
how far along is it?
now there's loads of blog articles and reviews out there, but most of them focus on comparing ubuntu phone (UP from now on) to other phone OSs - with their fully grown app universe. of course UP comes up short!
but that's not what i'm interested in. OS stability, and the standard browsing, music and video, and of course phone and sms is good enough for me.
but, i want the same freedom i have with my linux desktop install: to Do Things.
(my most important project is still to get a usable connection to the data & media stored on my kitchenserver.)
the day before yesterday i had a chat with someone on #ubuntu-phone - i think it was a dev.
i asked if i can use & upgrade it like any normal ubuntu/debian-based, install apps and utilities and so on.
basically he said, gui apps are difficult because UP uses a different gui model than Xorg, but basically yes, but you loose you guarantee that OTA (over the air) updates will work. but they should, regardless.
yesterday i was browsing the ubuntu phone section on ubuntu forums; of course people only post if something doesn't work - it looks like a normal and healthy distro forum to me.
OTA updates come in almost daily, i gather. very lively development.
there was, however, a lot of familiar discussions about how to get some app or other working; familiar from my 2 android phones: convoluted and fragile solutions, like installing ubuntu desktop in a chroot.
UP even recommends adb (android debug bridge?) as the only way to access the phone from your computer. or the standard mtp connection. so it's the same **** as everywhere.
the other aspect is this:
- ok, android is big, evil google, but there's a few established solutions around to use it without an account, use f-droid instead of play store, well documented security hacks and so on.
- UP certainly isn't the white knight here, but if not google, what do they use, is it really "better" than google and can i opt out easily?
yes, i am seriously considering to buy a UP phone, as soon as i get the feeling that it is an improvement freedom and security wise.
i wonder what people's experience or informed opinion is?
bump
...just a gentle one before the weekend ends.
i'd love to get some answers...
As advanced android users, we quickly became obsessed with rooting, unlocking, and controlling our phone. On the other side of the poker table, we have device manufacturers and carriers trying to lock the ecosystem down. It's curious to me how this came to be.
Looking at personal computers: I wanted to install linux on my personal computer because I am a developer by trade, so I installed linux. I took a USB, loaded the linux ISO, and followed the installer (actually I didn't, arch btw). I did not need to get unlock codes from my device manufacturer or my internet company, I just did it and no one complained (aside from windows who was glitching out as I tried to reboot)
This computer ecosystem feels healthy, it's my computer, and I can use it as I wish. I'm curious how and why android got to this point where 90% of manufacturers:
1. Don't allow unlocking
2. Make you jump through hoops to get an unlock code
3. Have hardware root checks
Of course, before we even start talking about verizon (they forgot to lock my pixel )
Is the fact that mobile devices are harder to unlock and modify them computers a flaw in android? Is there some actual reason life is like this?
That's even before we start talking about update cycles. I used my old computer for 10 years, going from god knows what to windows 10 before finally deciding that I just could not. My device manufacturer did not control the updates I got, they just came. Why is it the case that updates come from the manufacture, not directly from modifications to the android codebase? Shouldn't the manufacture just add "drivers" to the device to handle the peripherals?
I presume in some way google is complient with this, because android is based on linux, and linux has no such problems.
Many times, consumers that bootloader unlock their devices have no clue that they will lose features such as banking and Widevine D1; these users are oblivious as to what rooting truly does to their device and instinctively contact their OEM's support to get a device replacement as many times relocking the bootloader is impossible.
Verizon's thought process is somewhat similar, but there is likely a darker undertone to their practices: preventing bootloader unlocks and processes of the sort could aid them when blacklisting their devices, as there is no way to circumvent something tagged to a permanent IMEI kept by the same bootloader and firmware. There is a reason why T - Mobile requires you to have your device completely paid off before you can make any modifications to the system firmware.
Compared to laptops and computers, it is, generally, a one - time purchase and not an investment; carriers depend on their consumers to keep paying their devices off time and time again to make money.
Drivers are essentially non - existent on Android; the only thing that comes somewhat close is the kernel and any OEM modifications to the firmware.
Xryphon said:
Many times, consumers that bootloader unlock their devices have no clue that they will lose features such as banking and Widevine D1; these users are oblivious as to what rooting truly does to their device and instinctively contact their OEM's support to get a device replacement as many times relocking the bootloader is impossible.
Verizon's thought process is somewhat similar, but there is likely a darker undertone to their practices: preventing bootloader unlocks and processes of the sort could aid them when blacklisting their devices, as there is no way to circumvent something tagged to a permanent IMEI kept by the same bootloader and firmware. There is a reason why T - Mobile requires you to have your device completely paid off before you can make any modifications to the system firmware.
Compared to laptops and computers, it is, generally, a one - time purchase and not an investment; carriers depend on their consumers to keep paying their devices off time and time again to make money.
Drivers are essentially non - existent on Android; the only thing that comes somewhat close is the kernel and any OEM modifications to the firmware.
Click to expand...
Click to collapse
This explains why carriers do do this, and it makes sense, but how can they do this? The fact that should someone in the black box want to, loose control over my device no matter what I do is frankly scary. Could a laptop manufacturer do the same thing if they wanted to? (Ignoring the fact they could not because of the outrage). I had always thought somehow android as an operating system was connected to this, somehow complient, but perhaps it is really just a choice by the manufactures that android has nothing to do with. (Google could enforce this via GMS I think, but I don't expect them to)
Scaledish said:
This explains why carriers do do this, and it makes sense, but how can they do this? The fact that should someone in the black box want to, loose control over my device no matter what I do is frankly scary. Could a laptop manufacturer do the same thing if they wanted to? (Ignoring the fact they could not because of the outrage). I had always thought somehow android as an operating system was connected to this, somehow complient, but perhaps it is really just a choice by the manufactures that android has nothing to do with. (Google could enforce this via GMS I think, but I don't expect them to)
Click to expand...
Click to collapse
Chromebooks are a prime example of locking down the bootloader. So is the same with macOS laptops and related devices - albeit Apple lets you boot into other operating systems, the process to do so requires jumping through quite a bunch of loopholes due to Apple's Secure Boot, file system, etc.
Just to play devil's advocate for a moment (because in reality, I, too, prefer to own my equipment).....
Security can be a lot more critical on mobile devices than stationary devices like desktop computers. Even in *some* respects, compared to rackmount servers. This is because it can be pretty simple to grab someone's phone and do what you want with it. Having physical access to a piece of equipment is 99.999% of the task of breaking into it. Its relatively far fetched for someone to break into your home or a high security datacenter in order to gain physical access to your equipment, so the need to have it protected against the kinds of intrusions that become possible through physical access is much lower than it is on a phone, which you just might accidentally leave on the counter at a coffee shop.
And that is about the only part of the move towards lockdowns that I actually understand. The rest of it is either ill-conceived "security" or coercion to separate you from your money.
First off, I wanted to say I posted a few threads about this thing here asking questions about stuff I needed to get it working in the way I'd like and I'd want to thank you because I have made a lot of progress in getting it to be what I'd like it to be. I also don't know if this is the best forum to post this report because it's neither a question nor necessarily a tutorial but rather a summary and description of work already done so far, and especially because this device, while it sure runs Android (very well!) does not fit into any of the categories on this site neatly.
The story so far
This post concerns my experience working with the ITX-3588J, a board released just a few months ago by the Chinese manufacturer Firefly (or T-Chip Intelligent Technology Co. Ltd, based in Zhongshan) that is in the coveted mini-ITX form factor which means it can actually fit into a small-size desktop computer case and indeed has enough compute power to theoretically - and perhaps not so theoretically! - function as an honest desktop system with an ARM processor: namely the - also very new - Rockchip RK3588 system-on-a-chip.
About two months ago, I was looking into acquiring a new kind of computer to replace my somewhat longer on the tooth x86 machine that would be compact, low-power, and easy to transport while also being a fully capable desktop. And I certainly didn't want Apple. I had seen some very small form x86 desktops before, but I also knew there were many boards - like Raspberry Pi - that featured the ARM processor. Not content with the Pi, which is still very weak for this application at least when compared against modern software, I wanted to see if there was something else by now in a similar vein, and when I saw this board I thought it was an amazing option, esp. given I have not yet found a peer. Many ARM single-board devices exist but this is the only one I've found so far that looks to be in a proper desktop form factor and sporting a processor powerful enough to work at that level.
So I got the board, a case, and - noting it had SATA ports - a cheap 250 GB SSD, and put it all together ... and fired it up! And to my surprise, it booted up Android! Which was a real shocker because I generally thought this'd be like another PC board, not having had much experience with this ecosystem beyond phones, so that it would just give the usual "OS not found" stuff. Nope - pre-loaded on the board. Very minimal, very bare-bones though, not even the Google Play and similar essentials required for a usable Android experience. Yet with the little bit I had, I couldn't help but notice it was extremely fluid, responsive, and snappy, moreso than my aging 2018 era x86 box. Moreover, it was very, very interesting (and exciting!) to see Android booted onto a full-size monitor screen like Linux or Microsoft Windows - and actually and surprisingly, to see that it didn't look and feel all that bad!
However, of course, I wanted more. First, I wanted a fully-featured installation of Android. Second, I wanted to run Linux on it - especially given that, a short while later, I found that the board manufacturers were offering a stock Ubuntu 20.04 to be installable to it. Although, in the early stages, I didn't know how to do this at all, and then soon after learned how to reflash the embedded MMC chip to change the OS. And I did so, trying the Ubuntu and finding it also very performant, but not liking either that it was not quite the newest version but also more that it was mutually exclusive with Android - so far.
And that would begin a long - and at many times frustrating, especially given how much information out there is not at all tuned to a device like this being pressed into this application - learning journey toward exploring topics as diverse as how ARM processors and SoCs work under the hood, U-Boot, kernel features, the Firefly-Rockchip developer kit - and having to essentially single-handedly discover many of that kit's ins and outs given there was pretty much no documentation - and more, ultimately leading to where I've got it to now.
What it can do at this point
And that is, right now, I have it sitting here, loaded up with the stock Android 12 and Ubuntu 20.04 - with the former on the eMMC and the latter on the SSD hard drive. On the Android side, Google Play is now loaded and functional, though Google Chrome is not (it crashes with a "Telephony is null" exception for some reason, which seems to suggest for some reason it's trying to act like it's on a phone but isn't). Zoom - an app that I really, really wanted to have (and why I wanted to keep Android around on it) - works and works smoother and cleaner than my 2018 x86 Linux clunker. On the Ubuntu side, though, things are not yet coming - mostly because of seeming inability to use U-Boot to boot from the SSD. I managed to install GRUB, and given that Firefly's generous board SDK provides the full U-Boot source code was able to recompile it with the necessary "bootefi" command enabled which is not present in stock, but nonetheless alas this U-Boot seems to have its SATA support bugged or incomplete, because it would crash immediately upon trying to initialize that subsystem.
Where I'd like to go with it
Obviously, full dual boot of Android and Ubuntu, so getting U-Boot to boot the GRUB resident on the hard drive, is the biggest issue so far, and that means investigating whatever is the problem (or not?) in its SATA subsystem. Getting Google Chrome working on Android is another important step. Moreover - though it would cost extra money that I do not have right now - there's the very interesting possibility, owing to the fact that it has a built in M.2 slot on the board, and alluded to in the title - that the device could be made to act as a cell phone. And finally, the possibility of upgrading to a newer version of Ubuntu (ideally 22.04) - however from what I know so far, it looks like this will have to wait because the stock Linux kernels do not currently support the RK3588 fully - though I'd suggest the Linux kernel developers really should take a look at the SDK that came with this thing because it has lots of code in it including for the kernel, all under GPL.
Final note
One of the most interesting things I've learned from this project, and mentioned earlier, is just how well Android seems to work as a desktop OS. While there have apparently been some attempts to port it to x86, this is perhaps one of the first devices that is desktop-workable and which runs it natively. And one of the things I find that's nice about it is that ironically, because all the apps are designed for small screens, when they are run on a very big screen (and this monitor is not "very big" even by today's monitor standards, being a used and earlier LCD type), they are extremely easy on the eyes and have minimal UI clutter when compared to a typical desktop app on most Linux WMs and on MS Windows.
If you want to know more about the details, or anything else, feel free to ask any questions you might have!
UPDATE:
I believe I may have found an easier way to dual-boot Linux with Android, and that consists of configuring a custom ROM that will put both kernels, and GRUB, on the board's eMMC, while the rootfs for both OSes is placed on the hard disk. Will be seeing how it works.
UPDATE:
I have almost completed the custom ROM! I have now both Android and at least the base system for Ubuntu 20.04 (Kernel 5.10.66) bootable with Android now storing user data on the hard drive; though I'm still running into some hardware initialization issues in the latter that are keeping me from actually installing the desktop system. With regard to the Ubuntu system, there is some interesting issue in that for some reason the provided SDK kernel, which I had to rebuild, seems to build more Android-like because it wants to look in "/vendor" for some things related seemingly to the networking facilities, and it is possible this is preventing me from bringing up wifi, which I need in order to download the rest of the system.
But lots of progress overall - it seems that a full-fledged ARM desktop running simultaneously Android and Ubuntu is within reach to be wrung from this board!
Ignore my request for an update in another post. Seems you like you moving along. I don't need dual boot, just a working Android 12 with GPlay and Chrome. Did you get Chrome to work?
mebalzer said:
Ignore my request for an update in another post. Seems you like you moving along. I don't need dual boot, just a working Android 12 with GPlay and Chrome. Did you get Chrome to work?
Click to expand...
Click to collapse
Thanks. Yeah, I want to say that I have pretty successfully gotten Android 12 working on it for sure, but Ubuntu is proving much more difficult due to graphics support issues, and I'm not sure if it will be possible until RK3588 is supported in the mainline Linux kernel tree which is still something under development. And yes! I got Chrome to work Everything works, actually - it's great as an Android system, though obviously Android is kinda funny to use as a desktop OS. I am wondering if I can't get a "pseudo" Linux using something like Linux Deploy in lieu of running it natively, at least until the kernel development catches up with this new processor.
(FWIW, I'm posting this post from that machine while it is running A12. )
Good to see someone else is interested in it, though. What are you planning on using yours for?
Insofar as getting Android 12 to work w/GApps - it depends on if you want to do it purely on the eMMC or you want to also put user data on an attached hard drive like I did. In either case, the best option, I feel, is to create a custom ROM - I could provide custom ROMs for it for download, but don't know because of Google's licensing conditions around the GApps and have heard of people getting in trouble with Google for distributing custom ROMs for phones that have GApps in them. You basically need to unpack the stock Android image, unpack the "super.img", then load the apps from a package like NikGApps into the "product" partition (NOT "oem" - that was a big mistake), then repack everything and flash to the eMMC again. You will need the board SDK from Firefly for all this as it has the custom ROM-packing and flashing tools.
Alternatively, it is possible to manually install the NikGApps GApps using the Android console - as it's a fully unlocked system, obtaining root access is trivial: just put it into Developer mode and you will find the root access in the "Developer options..." menu under "System".
Shimmy99 said:
Insofar as getting Android 12 to work w/GApps - it depends on if you want to do it purely on the eMMC or you want to also put user data on an attached hard drive like I did. In either case, the best option, I feel, is to create a custom ROM - I could provide custom ROMs for it for download, but don't know because of Google's licensing conditions around the GApps and have heard of people getting in trouble with Google for distributing custom ROMs for phones that have GApps in them. You basically need to unpack the stock Android image, unpack the "super.img", then load the apps from a package like NikGApps into the "product" partition (NOT "oem" - that was a big mistake), then repack everything and flash to the eMMC again. You will need the board SDK from Firefly for all this as it has the custom ROM-packing and flashing tools.
Alternatively, it is possible to manually install the NikGApps GApps using the Android console - as it's a fully unlocked system, obtaining root access is trivial: just put it into Developer mode and you will find the root access in the "Developer options..." menu under "System".
Click to expand...
Click to collapse
Thanks I will keep this in mind. See my reply to you other reply on another post as well.
I would to run gplay as well please send me instruction the nikapps github doesnt say nothing