Hi guys!
I had this thought recently when using my mediafire account- it sucks... probably it doesn't suck more than average filehosting account, but still...
The idea (in fact two of them) I came up is the following:
Distribute evrything via bittorrent
For now I can't see any major downsides of the concept - but I think it'll be most useful for bigger distributions that build daily builds and/or support many phones. It could considerably ease the load on their uplinks thanks to the way bt works.
How I imagine it to work:
The person who would like to contribute would downoad the client, install it on his server/pc, register to the central repository, and in the end set a few config options (bandwidth he wants to contribute, how much disk space, and to what projects/phones/developers) and that's it. The client would then ask the central repo for some torrents to mirror and it'll run by itself (periodically asking the repo for new downloads or removals) - hopefully without any maintanance ever needed.
I imagine "the client" to be as simple as possible - maybe even a one shell script using curl to communicate with the repo. And of course some torrent client - if the project develops, support for many clients (and windows) can be added.
The server would do all the thinking as it'd have the most complete information about the entire "pool" - how much space is available to which projects, how many dowloads of each torrent there are etc. so it'd be easier for it to decide who should mirror what (of course within their defined filters). But in the beginning I don't think it would have to be very complicated either - if more clients connect, the algorithm can be made smarter.
The thing is - many of your users would be happy to contribute in some way to rom development, but usually they lack the skill necessary. But they could contribute hardware/bandwidth, especially that it doesn't require any effort from them and gives them the satisfaction of contributing.
The other thing is distributed build system based on similar principles: provide people with a configured VM image of a building system for various virtualization technologies and operating systems and that's it. The initial setup would be made as simple as possible for the end user. Having one vmimage would guarantee that everybody has consistent build environments.
This would of course be useful only to large android rom distributions that support multiple devices - building 20+ nightlies/a day (and distributing them) can be quite a challenge and requires considerable processing power and bandwidth, but if they had a farm of build servers (even small), this wouldn't be a problem and they could commit their hardware for pure development/debuging efforts.
Of course the system would inform the developer if his build failed somewhere and provided a log, so that he (or a person responsible) can investigate. The system could also do some automated recovery, i.e.: build fails -> clean ccache and rebuild, if fails, restart on another machine and if this fails, inform the developer. The system could also detect a faulty build machine (that fails some builds that run successfuly elsewhere) and exclude it from the pool (and of course send an email to machine owner). And of course ready builds would be reported to the repo server and distributed via torrent.
The whole trick is that for both distribution and compilation none individual contribution has to be large - users can dedicate 1GB of mirror space and it'll allow to host 4-5 rom builds. For build machines, they don't need to have a 6-core monster because it doesn't matter if it builds 1,2 or 3 hours as long as it builds (my 4x3.2GHz machine builds a rom in <90mins). What's more, they don't have to run those severs 24/7 - the system will know which machines are always on and which are not and distribute the load taking this information into account.
When the community grows beyond some critical mass, the system will work despite people droping in and out of the "grid"...
Just a loose idea... Tell me what you think.
Related
Good day community,
Over the past several months, a few of us have been working on a projerct some may be familiar with. We have bundled an add-on to specific BlueStacks versions to allow for a complete Operating System environment, full of communications tools.
We didn't "develop", any of it. We have taken the time to scour the internet and primarily this site to garner the education, information and knowledge to actually bring it to fruition. We would like to say a big THANK YOU to the entire community here. We feel this is am important piece to a software life-cycle where developed information is compiled into a fully functioning system, exposing your people's craftsmanship.
The motive here is a moral one. I have been a communications engineer for 22 years and have seen and done things I thought weren't possible. I have been tasked with trying to develop an education platform technology matrix for schools. Specifically using my innovation abilities to solve problems. I am not a coder, I am more of a script writer. I have found success in making disparate hardware and software work together, and producing middle-ware scripts and functions to technologically solve challenges. In every sector.
I believe I have identified one of the major issues related to student success rates. Basic communications is hindered in many schools, internet cut out, and dictator like classroom regime. I feel communications is the king of industry and whomever has the information the fastest, cheapest, and accurate, wins. This is proven time and time again in capitalism. I feel students should be able to sms, or exchange pictures and peruse social networks, both to each other and their teachers. These are real-world tools, and the primary back-bone of a child's social life. But students need to learn to be accountable for they digital actions,
This "OS" changes things ever so slightly., not every student can afford the gear required to have that type of communication. If every kid could afford an iphone and ipad, than I don't need to do this project. Android on the other hand, little or no cost at all.
I will be deploying Android for Windows across the board. Students will have to setup a Google account and online storage. Copies of AW can be had for their home computer. The environment is the environment kids all love and use, the emulated touch interface is "cool" and the kids can support it and maintain it mostly themselves, and sync it to their PC phones or other devices, but those are NOT required. And no need to upgrade the PC's for a while, BlueStacks is Linux(ish), it's hardware demands are low, and I can keep the PC's at there current level.
I distribute it on thepratebay, another long story for another day, but this is the best way to ensure it stays out there, and the price is right to be able to push it out to the world. We have tirelessly worked to ensure compatibility with the apps the devs release and I know this particular release of AW has restored many of the items BlueStacks cripples
We have started a mini marketing campaign to drum up interest, although modest. And for you devs, this open an ENTIRE new revenue stream you didn't even have before. Making Android the primary OS used.
---------------------------
That's the agenda, I would like to open a support thread for it somewhere on here. I have an armada of info, tools, rootkits, tricks and troubleshooting information that we feel can be valuable to the community. I'll get things posted here ASAP. Anyone that has played with this at all before will be able to appreciate all of the challenges we had to solve.
We did not knowingly disassemble or modify any of the original distribution files of any applications, staying in accordance with about every license agreement on earth.
--------------------------
Looking for some feedback, questions, thoughts, ideas.. have to get 10 posts or something anyway...
Thank you to everyone!
-js
What's the difference between your project and the Android x86 project?
syung said:
What's the difference between your project and the Android x86 project?
Click to expand...
Click to collapse
AFAIK Bluestacks has its own VM, so you doesn't need to install Virtual Machine any more.
I used this for a several months and it helps me to try an application without to send it to any Android device.
If you use Android x86 project, yo need to install it inside a Virtual Machine or make a USB Bootable, and as far I know it has limitations in the Play Store. Only some application that supports the architecture can be downloaded..
The Android x86 project is a piece of this absolutely. What BlueStacks is and what they have done is this:
Taken x86 gingerbread and ad an arm translator inside there. This is very unique, all of the other arm emulations fail out there after you even try to put them to the test with heavier use or apps. Basically the compatibility is just not there.
BlueStacks then added the vm player which is the most sophisticated player there is. Network mounts to shared fordler without installing drivers, and opengl support for limited HD graphics.
What we did
BlueStacks also crippled the hell out of the original ROM. All kinds of things missing that had to be put back in piece by piece, and still ensure compatibility. Some things fine to leave out, other maybe useful.
poring over the information, rooting bluestacks came easy, so we rooted every single v7.x of bluestacks, and began the mountain task of building compatibility. The winners are 7.4 for SD and 7.8 for HD. 7.8 handle the interface scrolling operations WAY better than later revisions. I can tell it was after this rev they forced on Surface Pro support, not back checking compatibility. And 7.4 installs on any machine but drops the arm translator. Still a nice product to put on an old machine, but little support for modern apps, and there won't be
Then doing a fair assessment of applications to do all the tasks one needs, file manipulation, printing, music, calling etc, We've spent over 200 hours trying to get a reliable lock screen, failed on that But we got most of it.
Finally adding and getting gapps to fully function was about like trying to drink a beer while standing on your head, it was like a marathon game of whack mole, we'd fix something, then something else friggen slam us over the head. Then we got to writing script, and adding widows apps like virtual keyboards and mouse to basically be able to run the entire OS with 1 finger as if you were Stephen Hawking.
We had an excellent response to the initial concept stuff version 1.1. It held on to around 400 seeders and 1000 user swam for about a week then began to fizzle. We expect that to triple and estimate 100,000 downloads in the first week. It is my opinion thepiratebay is the most accurate source for demand of anything digital, people that keep a copy and seed, actually really like something, versus an artificial "like" that other sites have and profit from. That's all Trip9d0zen stuff, about removing fake values and replacing it with real information exchange freedoms, so actually all financial can get to a creator, don't want to digress to far in this thread, but there is an ideology we have in common with thee twitters and thepitatebay's who have just the extreme basics of censorship, only to ensure safety, but never manipulated the information. We have evidence and models to change current businesses, and put the devs out in-front of these projects (or the artist selected agents). The more systems Android runs on, more success one can have. And Windows being the biggest, hands down, why not?
We feel this is by far the most compatible Android environment one can use, and can actually be used by anyone as an effective tool.
We know full well that once released, the ungodly amount of app work requests will be at its highest, but that's why I am here, where the devs are.. is this a revenue stream they want to suppport,?
I am personally using it exclusively for all my communications, social media and document creation, I only use windows for video playing files.
Hope that helps answer, here is the info to commercials for it, as our lil-1337s eloquently cranked out, smartasses...
youtube search for js99912
-js
It looks interesting, i'll check that up!
Dexcellium said:
It looks interesting, i'll check that up!
Click to expand...
Click to collapse
Me too. Thanks
Android for Windows 2.0
new version just went live..... can someone reply with a hot-link, thanks
thepiratebay.sx
/torrent/8440340
Adding Game Data / Mount SDcard.sparse BlueStacks
Ok, I have been asked about this more than anything,
Used to be the SDcard was a .fs file and could be manipulated easy, now it's a bit more involved, but none to difficult.
You need to download:
thepiratebay.sx/
torrent/8453985
This will get you to be able to mount the SDcard.sparsefs as a drive letter in windows... Nothing new, just consolidating info as I have been requested for this more than anything else. Enjoy!
-js
First of all I want to applaud the integrity of the team working on OmniRom and for standing for software freedom. As the only GPL ROM on the phone, I believe it will reach a certain prominence once critical mass of functionality is achieved. I have some suggestions that I was hoping to get feedback for from the Devs here.
1- What is the possibility for devising an in-place upgrade system that works across future OS version upgrades for major changes in AOSP? (something akin the upgrade systems of current GNU/Linux systems)
2- Incorporating apps from the guardianproject (.info) a privacy and security oriented group that make secure messaging apps and TOR for Android. That will be our anwser to the so called secure chat of CM.
3- Cooperation with the largest FOSS software repo F-Droid and perhaps including it as a default app repo option for OmniRom.
4- Now this is a big one, but as a distro that prizes Software Freedom and the GPL above all else you are in a unique position to be a demo showcase for incorporating the major app frameworks being ported to Android like Qt and Gnome. Arranging with the devs from KDE and Gnome to make this a reality would be a major milestone for the FOSS movement's efforts to bring free software in an environment that is being increasingly closed off like what Google is doing with their absorption of features in proprietary apps and the treachery of the CM turncloaks.
Casual observer here. I don't think it's accurate to call it a GPL ROM given how many non-free drivers are required to get working WiFi and so on. OmniROM encourages GPL as a way of keeping the community honest but I don't think it's set in stone.
1. upgrades on Android don't happen in same way as GNu/Linux: it's always a fresh install. CM already does this, or you can use recovery mode.
2. good idea! more generally, system wide proxy settings which would allow all traffic to go through Tor. Tor is one part of remaining anonymous, the browser needs to be locked down for example. Guardian Project say that their companion browser, Or web, doesn't work on Android 4.4, and they might stop developing it. There are other Android techniques for anonymity e.g. xprivacy.
3. F-Droid builds and signs apps, it's hard to see room for cooperation. It will soon have ability to install apps silently if part of a ROM. They dropped their Android.mk; looks like time to bring it back, maybe with package name change option.
4. Qt was announced on day one at the BBQ!
Kodi™ Foundation are ready to end Android support and development !!
ARE YOU ????
Call out for developers
As you may or may not know is that Kodi is maintained by a group of volunteers since its first inception dating back to the original XBOX days. Over the years many volunteers have spent countless days if not months on every aspects of what makes Kodi great. This consist of writing and maintaining the code base of Kodi, expanding to new platforms, maintaining the forum, wiki, website and download server and more……
So why do we need you? Well the fact is that over the years the core team of Kodi has remained about the same size while the amount of users went from couple of thousand to many, many millions. Not forgetting the fact that it went from only a XBOX application to what is now running on Linux, Windows, iOS, OSX, Android. All this still with the same amount of people. Now comes the time that we will actually start calling out for some help. To put it simple we want to ensure that Kodi remains alive on all platforms while at the same time lowering the support burden each developer now faces these days. Each of the core developers has his own specialty and since Kodi is quite big you quickly run out of developers that know enough of certain sections. Add to that the changes needed for each operating system upgrade that happens and all the problems that arise with that.
To put it in perspective we basically have only 1 developer for each section or even complete platform. As already mentioned the entire team consists of volunteers which means everything is done in their spare time next to having an actual day time job and a personal life. This results in having only a few hours at most to spend on what they see as their hobby which i can say they are passionate about.*Over the years the team consisted of many different developers who gave all they could but due to whatever reason had to change priorities which resulted in not spending time in Kodi anymore.
So in short what we are looking for are C/C++ developers who are willing to put in some of their spare time in maintaining and improving our core code. This can either be doing some minor bugfixing, reviewing existing pull requests for code contributions or even creating some of their own code refactoring or feature additions. It really doesn’t matter if you are just a student just starting out on C/C++ or are already a senior programmer. We would welcome anyone who is willing to do their part on any improvement that is needed. A fair warning is that our codebase isn’t for the faint hearted as it’s quite massive and we are quite strict regarding code review before we merge anything. However don’t let this frighten you off as our current (or outside developers) will certainly give you pointers on improvements to get it included.
What we currently need most are developers with knowledge of the following components to improve current implementations:
• Windows DirectX11 / audio / video•*Android NDK / audio / video• iOS & OSX / audio / video• General knowledge of C/C++ and willing to do some coding in areas of their interest.
Any bugfix can be send to our main github code repository for review straight away. If you are not sure or want to take on a bigger task or change feel free to open up a thread on our forum where you write down your proposal to get some initial feedback.
Wiki pages to get you started:*http://kodi.wiki/view/Development
Forum:*Developer sucbsection
Code on Github:*https://github.com/xbmc/xbmc
Regards As Always
Welcome!
Introduction
After three years of inactivity, of me (the developer) simply enjoying life and riding bikes, I'm proud to announce that JDroidLib is being resurrected!
Originally inspired by AndroidLib by @regaw_leinad, JDroidLib is a Java class library aimed to ease the development of Java applications designed to communicate with Android-powered devices.
The end goal was to make the library as easy and efficient to use as possible, and while the original library was easy to use, some fairly bad design choices were made on my part to make that happen.
After a turn of recent events, I've found myself to have somewhat more free time on my hands and decided to re-visit the project.
After looking through the (well-documented) source code of the original library, I decided that in order for an update to make sense, I'd have to completely re-write the library.
After a couple of hours of development and building the base, I had come up with a structure and code design that I was happy with and continued from there.
A few days after development began, I created a new repository on GitHub and thus, JDroidLibv2 was born!
The original version of JDroidLib was featured multiple times on the XDA platform and on other networks, as well.
Ok, great! But why should we care?
There are two very simple answers to this question!
If you're not a Java developer, or you have no interest in building Java applications that communicate with Android devices, such as flashing, rooting, or diagnostic tools, then you absolutely don't have to care! That's the beauty of it.
If, however, you are either of those, then you should give JDroidLib a closer look!
JDroidLib is designed to be efficient and easy to use.
Getting the library integrated in to your project is as easy as clicking a couple of times and calling it a day!
Now, I hear you ask: What's the upside to using your library?
Also a question that is very easy to answer.
Using JDroidLib, your application has next to no boilerplate code, meaning the footprint of your actual application is minimal and thanks to fast initialisation routines, your application will suffer minimal latency.
Thanks to both synchronous and asynchronous operations, your UI application will feel responsive to your users and your application less bloated.
JDroidLib includes shortcuts to commands that are often used and helper classes that cleanly sort and store data, so your application doesn't have to!
What design choices have you made?
JDroidLib is designed to be as easy to use as possible, while being efficient at what it does.
To implement these ideas and this design, JDroidLib uses a variety of designs that all work together to create an efficient library:
Factories to easily define the things you need
Singletons to prevent resource hogging and minimise the risks of memory leaks
Both synchronous and asynchronous methods so you can choose what's best for you!
Strongly typed
Provides features that otherwise prove useful in applications, such as tuples
Genericism
Ok, that's cool and all, but when will it be ready?
As it is, JDroidLibv2 is currently in an early beta. Its features are not yet fully implemented and a lot of things are missing.
All I can say for now, is it'll be ready when it's ready.
It could take weeks, or even months - depending on how much time I have.
I'm hoping the repository will be updated regularly!
End notes
If you're interested in the project, the link to the source code repository can be found below.
In later posts I will add current features, todos, and more relevant information!
Happy coding!
XDA:DevDB Information
JDroidLibv2, Tool/Utility for all devices (see above for details)
Contributors
Beatsleigher, Beatsleigher
Source Code: https://github.com/Beatsleigher/JDroidLibv2
Version Information
Status: Beta
Created 2017-10-06
Last Updated 2017-10-07
Reserved
Current Features
Automatic initialisation
Installation/downloading of platform-specific platform-tools packages
Start/stop ADB server
Get list of devices
Execute custom commands (sync and async!)
Connect to and disconnect from devices via TCP/IP
Manage device filesystems
Get root and busybox information
Get device battery information
Current Todos
Complete Device class
Build file manager
Get battery information
Get SU/busybox information
Get CPU/RAM information
Build buildprop manager
Add reboot methods
Finish JavaDocing everything
Add (complete) wiki to GitHub
Add homepage to GitHub (I've no more website)
Add feature requests from potential users?
Continue updating
Elements that are stroked are completed/ideas that have been scrapped.
Reserved
Useful Links
Source Code
https://github.com/Beatsleigher/JDroidLibv2
Issue Tracker
https://github.com/Beatsleigher/JDroidLibv2/issues
Wiki and Guides
https://github.com/Beatsleigher/JDroidLibv2/wiki
Release Downloads
https://github.com/Beatsleigher/JDroidLibv2/releases
Todo: Upload to Maven Central
Social Media (Updates)
Google+
Twitter (not as regular, though)
JDroidLibv2 has been released in an open beta!
https://github.com/Beatsleigher/JDroidLibv2/releases
Welcome!
Introduction
After three years of inactivity, of me (the developer) simply enjoying life and riding bikes, I'm proud to announce that JDroidLib is being resurrected!
Originally inspired by AndroidLib by @regaw_leinad, JDroidLib is a Java class library aimed to ease the development of Java applications designed to communicate with Android-powered devices.
The end goal was to make the library as easy and efficient to use as possible, and while the original library was easy to use, some fairly bad design choices were made on my part to make that happen.
After a turn of recent events, I've found myself to have somewhat more free time on my hands and decided to re-visit the project.
After looking through the (well-documented) source code of the original library, I decided that in order for an update to make sense, I'd have to completely re-write the library.
After a couple of hours of development and building the base, I had come up with a structure and code design that I was happy with and continued from there.
A few days after development began, I created a new repository on GitHub and thus, JDroidLibv2 was born!
The original version of JDroidLib was featured multiple times on the XDA platform and on other networks, as well.
Ok, great! But why should we care?
There are two very simple answers to this question!
If you're not a Java developer, or you have no interest in building Java applications that communicate with Android devices, such as flashing, rooting, or diagnostic tools, then you absolutely don't have to care! That's the beauty of it.
If, however, you are either of those, then you should give JDroidLib a closer look!
JDroidLib is designed to be efficient and easy to use.
Getting the library integrated in to your project is as easy as clicking a couple of times and calling it a day!
Now, I hear you ask: What's the upside to using your library?
Also a question that is very easy to answer.
Using JDroidLib, your application has next to no boilerplate code, meaning the footprint of your actual application is minimal and thanks to fast initialisation routines, your application will suffer minimal latency.
Thanks to both synchronous and asynchronous operations, your UI application will feel responsive to your users and your application less bloated.
JDroidLib includes shortcuts to commands that are often used and helper classes that cleanly sort and store data, so your application doesn't have to!
What design choices have you made?
JDroidLib is designed to be as easy to use as possible, while being efficient at what it does.
To implement these ideas and this design, JDroidLib uses a variety of designs that all work together to create an efficient library:
Factories to easily define the things you need
Singletons to prevent resource hogging and minimise the risks of memory leaks
Both synchronous and asynchronous methods so you can choose what's best for you!
Strongly typed
Provides features that otherwise prove useful in applications, such as tuples
Ok, that's cool and all, but when will it be ready?
As it is, JDroidLibv2 is currently in an early beta. Its features are not yet fully implemented and a lot of things are missing.
All I can say for now, is it'll be ready when it's ready.
It could take weeks, or even months - depending on how much time I have.
I'm hoping the repository will be updated regularly!
End notes
If you're interested in the project, the link to the source code repository can be found below.
In later posts I will add current features, todos, and more relevant information!
Happy coding!
XDA:DevDB Information
JDroidLibv2, Tool/Utility for all devices (see above for details)
Contributors
Beatsleigher, Beatsleigher
Source Code: https://github.com/Beatsleigher/JDroidLibv2
Version Information
Status: Beta
Current Beta Version: oct_17_beta
Created 2017-10-14
Last Updated 2017-10-13
Reserved
Current Features
Automatic initialisation
Installation/downloading of platform-specific platform-tools packages
Start/stop ADB server
Get list of devices
Execute custom commands (sync and async!)
Connect to and disconnect from devices via TCP/IP
Manage device filesystems
Get root and busybox information
Get device battery information
Current Todos
Complete Device class
Build file manager
Get battery information
Get SU/busybox information
Get CPU/RAM information
Build buildprop manager
Add reboot methods
Finish JavaDocing everything
Add (complete) wiki to GitHub
Add homepage to GitHub (I've no more website)
Add feature requests from potential users?
Continue updating
Elements that are stroked are completed/ideas that have been scrapped.
Reserved
Useful Links
Source Code
https://github.com/Beatsleigher/JDroidLibv2
Issue Tracker
https://github.com/Beatsleigher/JDroidLibv2/issues
Wiki and Guides
https://github.com/Beatsleigher/JDroidLibv2/wiki
Release Downloads
https://github.com/Beatsleigher/JDroidLibv2/releases
Todo: Upload to Maven Central
Social Media (Updates)
Google+
Twitter (not as regular, though)
JDroidLibv2 has been released in an open beta!
https://github.com/Beatsleigher/JDroidLibv2/releases