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
Related
【ROM 4.3.1【UN-OFFICIAL PURE AOSP】InsomniaAOSP【10/22/13 v.1.0】
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Open Source
What is the Android Open Source Project?
We use the phrase "Android Open Source Project" or "AOSP" to refer to the people, the processes, and the source code that make up Android.
The people oversee the project and develop the actual source code. The processes refer to the tools and procedures we use to manage the development of the software. The net result is the source code that you can use to build cell phone and other devices.
Why did we open the Android source code?
Google started the Android project in response to our own experiences launching mobile apps. We wanted to make sure that there would always be an open platform available for carriers, OEMs, and developers to use to make their innovative ideas a reality. We also wanted to make sure that there was no central point of failure, so that no single industry player could restrict or control the innovations of any other. The single most important goal of the Android Open-Source Project (AOSP) is to make sure that the open-source Android software is implemented as widely and compatibly as possible, to everyone's benefit.
You can find more information on this topic at our Project Philosophy page.
What kind of open-source project is Android?
Google oversees the development of the core Android open-source platform, and works to create robust developer and user communities. For the most part the Android source code is licensed under the permissive Apache Software License 2.0, rather than a "copyleft" license. The main reason for this is because our most important goal is widespread adoption of the software, and we believe that the ASL2.0 license best achieves that goal.
You can find more information on this topic at our Project Philosophy and Licensing pages.
Why is Google in charge of Android?
Launching a software platform is complex. Openness is vital to the long-term success of a platform, since openness is required to attract investment from developers and ensure a level playing field. However, the platform itself must also be a compelling product to end users.
That's why Google has committed the professional engineering resources necessary to ensure that Android is a fully competitive software platform. Google treats the Android project as a full-scale product development operation, and strikes the business deals necessary to make sure that great devices running Android actually make it to market.
By making sure that Android is a success with end users, we help ensure the vitality of Android as a platform, and as an open-source project. After all, who wants the source code to an unsuccessful product?
Google's goal is to ensure a successful ecosystem around Android, but no one is required to participate, of course. We opened the Android source code so anyone can modify and distribute the software to meet their own needs.
What is Google's overall strategy for Android product development?
We focus on releasing great devices into a competitive marketplace, and then incorporate the innovations and enhancements we made into the core platform, as the next version.
In practice, this means that the Android engineering team typically focuses on a small number of "flagship" devices, and develops the next version of the Android software to support those product launches. These flagship devices absorb much of the product risk and blaze a trail for the broad OEM community, who follow up with many more devices that take advantage of the new features. In this way, we make sure that the Android platform evolves according to the actual needs of real-world devices.
How is the Android software developed?
Each platform version of Android (such as 1.5, 1.6, and so on) has a corresponding branch in the open-source tree. At any given moment, the most recent such branch will be considered the "current stable" branch version. This current stable branch is the one that manufacturers port to their devices. This branch is kept suitable for release at all times.
Simultaneously, there is also a "current experimental" branch, which is where speculative contributions, such as large next-generation features, are developed. Bug fixes and other contributions can be included in the current stable branch from the experimental branch as appropriate.
Finally, Google works on the next version of the Android platform in tandem with developing a flagship device. This branch pulls in changes from the experimental and stable branches as appropriate.
You can find more information on this topic at our Branches and Releases.
Why are parts of Android developed in private?
It typically takes over a year to bring a device to market, but of course device manufacturers want to ship the latest software they can. Developers, meanwhile, don't want to have to constantly track new versions of the platform when writing apps. Both groups experience a tension between shipping products, and not wanting to fall behind.
To address this, some parts of the next version of Android including the core platform APIs are developed in a private branch. These APIs constitute the next version of Android. Our aim is to focus attention on the current stable version of the Android source code, while we create the next version of the platform as driven by flagship Android devices. This allows developers and OEMs to focus on a single version without having to track unfinished future work just to keep up. Other parts of the Android system that aren't related to application compatibility are developed in the open, however. It's our intention to move more of these parts to open development over time.
When are source code releases made?
When they are ready. Some parts of Android are developed in the open, so that source code is always available. Other parts are developed first in a private tree, and that source code is released when the next platform version is ready.
In some releases, core platform APIs will be ready far enough in advance that we can push the source code out for an early look in advance of the device's release; however in others, this isn't possible. In all cases, we release the platform source when we feel the version has stabilized enough, and when the development process permits. Releasing the source code is a fairly complex process.
What is involved in releasing the source code for a new Android version?
Releasing the source code for a new version of the Android platform is a significant process. First, the software gets built into a system image for a device, and put through various forms of certification, including government regulatory certification for the regions the phones will be deployed. It also goes through operator testing. This is an important phase of the process, since it helps shake out a lot of software bugs.
Once the release is approved by the regulators and operators, the manufacturer begins mass producing devices, and we turn to releasing the source code.
Simultaneous to mass production the Google team kicks off several efforts to prepare the open source release. These efforts include final API changes and documentation (to reflect any changes that were made during qualification testing, for example), preparing an SDK for the new version, and launching the platform compatibility information.
Also included is a final legal sign-off to release the code into open source. Just as open source contributors are required to sign a Contributors License Agreement attesting to their IP ownership of their contribution, Google too must verify that it is clear to make contributions.
Starting at the time mass production begins, the software release process usually takes around a month, which often roughly places source code releases around the same time that the devices reach users.
How does the AOSP relate to the Android Compatibility Program?
The Android Open-Source Project maintains the Android software, and develops new versions. Since it's open-source, this software can be used for any purpose, including to ship devices that are not compatible with other devices based on the same source.
The function of the Android Compatibility Program is to define a baseline implementation of Android that is compatible with third-party apps written by developers. Devices that are "Android compatible" may participate in the Android ecosystem, including Google Play; devices that don't meet the compatibility requirements exist outside that ecosystem.
In other words, the Android Compatibility Program is how we separate "Android compatible devices" from devices that merely run derivatives of the source code. We welcome all uses of the Android source code, but only Android compatible devices -- as defined and tested by the Android Compatibility Program -- may participate in the Android ecosystem.
How can I contribute to Android?
There are a number of ways you can contribute to Android. You can report bugs, write apps for Android, or contribute source code to the Android Open-Source Project.
There are some limits on the kinds of code contributions we are willing or able to accept. For instance, someone might want to contribute an alternative application API, such as a full C++-based environment. We would decline that contribution, since Android is focused on applications that run in the Dalvik VM. Alternatively, we won't accept contributions such as GPL or LGPL libraries that are incompatible with our licensing goals.
We encourage those interested in contributing source code to contact us via the AOSP Community page prior to beginning any work. You can find more information on this topic at the Getting Involved page.
How do I become an Android committer?
The Android Open Source Project doesn't really have a notion of a "committer". All contributions -- including those authored by Google employees -- go through a web-based system known as "gerrit" that's part of the Android engineering process. This system works in tandem with the git source code management system to cleanly manage source code contributions.
Once submitted, changes need to be accepted by a designated Approver. Approvers are typically Google employees, but the same approvers are responsible for all submissions, regardless of origin.
You can find more information on this topic at the Submitting Patches page.
Compatibility
What does "compatibility" mean?
We define an "Android compatible" device as one that can run any application written by third-party developers using the Android SDK and NDK. We use this as a filter to separate devices that can participate in the Android app ecosystem, and those that cannot. Devices that are properly compatible can seek approval to use the Android trademark. Devices that are not compatible are merely derived from the Android source code and may not use the Android trademark.
In other words, compatibility is a prerequisite to participate in the Android apps ecosystem. Anyone is welcome to use the Android source code, but if the device isn't compatible, it's not considered part of the Android ecosystem.
What is the role of Google Play in compatibility?
Devices that are Android compatible may seek to license the Google Play client software. This allows them to become part of the Android app ecosystem, by allowing users to download developers' apps from a catalog shared by all compatible devices. This option isn't available to devices that aren't compatible.
What kinds of devices can be Android compatible?
The Android software can be ported to a lot of different kinds of devices, including some on which third-party apps won't run properly. The Android Compatibility Definition Document (CDD) spells out the specific device configurations that will be considered compatible.
For example, though the Android source code could be ported to run on a phone that doesn't have a camera, the CDD requires that in order to be compatible, all phones must have a camera. This allows developers to rely on a consistent set of capabilities when writing their apps.
The CDD will evolve over time to reflect market realities. For instance, the 1.6 CDD only allows cell phones, but the 2.1 CDD allows devices to omit telephony hardware, allowing for non-phone devices such as tablet-style music players to be compatible. As we make these changes, we will also augment Google Play to allow developers to retain control over where their apps are available. To continue the telephony example, an app that manages SMS text messages would not be useful on a media player, so Google Play allows the developer to restrict that app exclusively to phone devices.
If my device is compatible, does it automatically have access to Google Play and branding?
Google Play is a service operated by Google. Achieving compatibility is a prerequisite for obtaining access to the Google Play software and branding. Device manufacturers should contact Google to obtain access to Google Play.
If I am not a manufacturer, how can I get Google Play?
Google Play is only licensed to handset manufacturers shipping devices. For questions about specific cases, contact [email protected].
How can I get access to the Google apps for Android, such as Maps?
The Google apps for Android, such as YouTube, Google Maps and Navigation, Gmail, and so on are Google properties that are not part of Android, and are licensed separately. Contact [email protected] for inquiries related to those apps.
Is compatibility mandatory?
No. The Android Compatibility Program is optional. Since the Android source code is open, anyone can use it to build any kind of device. However, if a manufacturer wishes to use the Android name with their product, or wants access to Google Play, they must first demonstrate that the device is compatible.
How much does compatibility certification cost?
There is no cost to obtain Android compatibility for a device. The Compatibility Test Suite is open-source and available to anyone to use to test a device.
How long does compatibility take?
The process is automated. The Compatibility Test Suite generates a report that can be provided to Google to verify compatibility. Eventually we intend to provide self-service tools to upload these reports to a public database.
Who determines what will be part of the compatibility definition?
Since Google is responsible for the overall direction of Android as a platform and product, Google maintains the Compatibility Definition Document for each release. We draft the CDD for a new Android version in consultation with a number of OEMs, who provide input on its contents.
How long will each Android version be supported for new devices?
Since Android's code is open-source, we can't prevent someone from using an old version to launch a device. Instead, Google chooses not to license the Google Play client software for use on versions that are considered obsolete. This allows anyone to continue to ship old versions of Android, but those devices won't use the Android name and will exist outside the Android apps ecosystem, just as if they were non-compatible.
Can a device have a different user interface and still be compatible?
The Android Compatibility Program focuses on whether a device can run third-party applications. The user interface components shipped with a device (such as home screen, dialer, color scheme, and so on) does not generally have much effect on third-party apps. As such, device builders are free to customize the user interface as much as they like. The Compatibility Definition Document does restrict the degree to which OEMs may alter the system user interface for areas that do impact third-party apps.
When are compatibility definitions released for new Android versions?
Our goal is to release new versions of Android Compatibility Definition Documents (CDDs) once the corresponding Android platform version has converged enough to permit it. While we can't release a final draft of a CDD for an Android software version before the first flagship device ships with that software, final CDDs will always be released after the first device. However, wherever practical we will make draft versions of CDDs available.
How are device manufacturers' compatibility claims validated?
There is no validation process for Android device compatibility. However, if the device is to include Google Play, Google will typically validate the device for compatibility before agreeing to license the Google Play client software.
What happens if a device that claims compatibility is later found to have compatibility problems?
Typically, Google's relationships with Google Play licensees allow us to ask them to release updated system images that fix the problems.
Compatibility Test Suite
What is the purpose of the CTS?
The Compatibility Test Suite is a tool used by device manufacturers to help ensure their devices are compatible, and to report test results for validations. The CTS is intended to be run frequently by OEMs throughout the engineering process to catch compatibility issues early.
What kinds of things does the CTS test?
The CTS currently tests that all of the supported Android strong-typed APIs are present and behave correctly. It also tests other non-API system behaviors such as application lifecycle and performance. We plan to add support in future CTS versions to test "soft" APIs such as Intents as well.
Will the CTS reports be made public?
Yes. While not currently implemented, Google intends to provide web-based self-service tools for OEMs to publish CTS reports so that they can be viewed by anyone. CTS reports can be shared as widely as manufacturers prefer.
How is the CTS licensed?
The CTS is licensed under the same Apache Software License 2.0 that the bulk of Android uses.
Does the CTS accept contributions?
Yes please! The Android Open-Source Project accepts contributions to improve the CTS in the same way as for any other component. In fact, improving the coverage and quality of the CTS test cases is one of the best ways to help out Android.
Can anyone use the CTS on existing devices?
The Compatibility Definition Document requires that compatible devices implement the 'adb' debugging utility. This means that any compatible device -- including ones available at retail -- must be able to run the CTS tests.
Click to expand...
Click to collapse
SOURCE
Click to expand...
Click to collapse
INITIAL RELEASE 10/22/2013 @ 5:54 am
Click to expand...
Click to collapse
InsomniaAOSP v1.0
Click to expand...
Click to collapse
Standard Core gapps
Click to expand...
Click to collapse
WORK IN PROGRESS ALL MAINTAINERS COLLABORATE IN GIVING CREDITS
Click to expand...
Click to collapse
Android Open Source Project
CodeKill13
Ubuntu
Linux Mint
Github
Flar
Peter Poelman
itsme
Stericson
JesusFreke
CyanogenMOD
AOKP
PacROM
Rootbox
Evervolv
ParanoidAndroid
slimroms
Team-Hydra -Device Trees-Kernel
Team Horizon
The mikmik
AndroidSpin
Android Police
VanirAOSP
CodefireXexperiment
albinoman887
TheMuppets
Htc
Samsung
TheBr0ken
snuzzo
T-Macgnolia
ljjehl
Saif Kotwal
pr0xy man1Ac
Djwuh
ammikam
!I am not responsible for anything that happens to you or your device as a result of flashing this rom. If you decide to install this rom then you've taken responsibility for any risks involved !!
reserrrrved
Nice to see another 4.3.1 rom for our sensation
Keep the good work, will flash it tommorow
Sent from my HTC Sensation using XDA Premium 4 mobile app
Looks good shall test in the morning , thanks
Sent from my HTCSensation using Tapatalk
Tried it already from DK's thread on other forum.
There are issues with languages, not everything is translated to russian for instance.
Also there are plenty of CM ringtones, why is that?
WiFi hotspot is not working, cannot even detect an access point.
Launcher has weird wallpaper alingment, that doesn't fit at very left or right...
All these are minor issues to polish in the future.
Oh, why there's a theme engine, is it a part of AOSP now or a bonus from CM?
I'm glad see another pure (or maybe not so much) AOSP ROM.
Since there's no new SuperXE ROMs we welcome the new effort with a big smile on our never well shaved faces.
Noobel said:
Tried it already from DK's thread on other forum.
There are issues with languages, not everything is translated to russian for instance.
Also there are plenty of CM ringtones, why is that?
WiFi hotspot is not working, cannot even detect an access point.
Launcher has weird wallpaper alingment, that doesn't fit at very left or right...
All these are minor issues to polish in the future.
Oh, why there's a theme engine, is it a part of AOSP now or a bonus from CM?
I'm glad see another pure (or maybe not so much) AOSP ROM.
Since there's no new SuperXE ROMs we welcome the new effort with a big smile on our never well shaved faces.
Click to expand...
Click to collapse
hahahah..I agree with this " our never well shaved faces".. New ROM to play with....Good job
Nice to see it's playing again. Don't let our Senny dead.
oooo another AOSP for my Sensation! Bring it on! Thank you!!
---------- Post added at 04:35 AM ---------- Previous post was at 04:34 AM ----------
Any listing of what is working and what is not?
Good work, i'll try it
anyone got any feedback on this one?
Sage said:
anyone got any feedback on this one?
Click to expand...
Click to collapse
Yes, +1, feedback is important for the rom cooker
Is this really pure AOSP without any mods?
I mean "stock" android 4.3.1 ?
Just for the record that I am not running this rom anymore and the bugs I noticed and know of are:
Quit hours not working
Clock Widget settings gives a FC
Setting the navigation bar in Insomnia setting will FC the system UI and can't be recovered and need a factory reset
Browser and the Mail-App have a screen glitches.
I saw this InsomniaAOSP purity test!
☑ [NEW OS] *SDK Package Up - Code �ther Kripton OS Apps *Take The Poll
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
We've developed a new Smart Phone OS called Æther v 0.1 Krypton.
It's a unique code you will find easy and very efficient to work with.
You might be wondering what the "Korephone" mention in the graphic above
is about. Our goal is once the Æther OS is completed we will launch our own
phone to be eventually as innovative as the Æther OS and may partner
with someone meeting our standards and Ideology to make it a reality.
For Starters take the POLL.
Only takes a few seconds!
We want to know what's important to you in an OS.
***Not sure why people are getting the SDK Package Installer errors.
Please ensure you run the Installer with as an Administrator.
A library needs to be put into the GAC, so it may require Admin rights.
Below is a Manual Work Around.
Manual SDK install instructions:
Install the file "Æther OS Application Contracts.dll" into the Windows GAC using
the Visual Studio Command Prompt (with Admin privileges.)
Download link:
https://mega.nz/#!GUckEQaB!O1wrt6IIBkDj8AJT49Tfz6WUMXyXWWWwLDj6apq7xFE
SDK Files. Use them as previously described in this thread:
https://mega.nz/#!LcsxATSB!gcwzluEeGo6yoqujWy6rWNuZ2Di4yNRvLAmxxhb9npw
All necessary APIs required in order to write 99% of apps is now complete
(the exception being some games and apps that do 3D graphics.)
Any extras which may be required will be added by request from any devs writing apps, of course.
The hardware rendering infrastructure is next, followed by hardware integration.
In the meantime devs have essentially everything they would need in order to write their apps.
Could you help us with Apps? Could be any of the ones listed below including their
Bounties or whatever app interests you to Develop in Æther OS.
Why the Æther Kripton OS was created:
"Linux creator says Windows, OS X, iOS and Android are all malware"
http://bgr.com/2015/05/26/ios-android-windows-mac-malware/
"Richard Stallman, known for his instrumental role in the creation of Linux, has written an opinion piece
arguing that nearly any operating system you might use today can be considered malware,
and that goes for popular mobile platforms as well as desktop operating systems."
*Let alone the front door access they are now providing.......
Besides being a possible antidote to all the above we simply want to bring you an awesome OS that will open the door
to the world of Coders and an incredible user experience. Join Us!
Special Requests: A: DEV to port CyanogenMod to a phone.
B: For a Live Streaming Video APP, ASAP.
Inquire Within and verify it's the Video App.
We're looking to attract quality individuals/coders who will want
to be involved at the ground floor of a new game changing
impervious platform unique to the Korephone.
Please post what apps you'd consider translating.
This is a rare opportunity.
Working with us here where it's starting will earn you an Æther "Guru status"
since you are the first and will be the most knowledgeable.
Æther SDK 0.3 Installer Full Package: NOTE: Some were getting error messages
so a "Manual Work Around was posted above. We are keeping this up till further notice
https://mega.co.nz/#!uRlHAaKS!Wzw8Q_0UhxMXFQN31NqnH5PMTAx1kDSpz29uKn0yeM8
Please familiarize yourself with what we have up till today and check back often.
QUESTIONS:
Q: "What language is this?”
A: Details are yet to be announced.
Q: “What do we export it to?”
A: To be announced.
Q: "When can I start"
A: 6th December earliest. December 12th is the official anticipated start date.
Q: "Why then for such an early thread?"
A: To line up the coders for a fast track completion of all Apps
and in case we get some API references done early.
Below is a GIF of the KorePhone OS running in the KorePhone Emulator.
Notice the GIF's Physical Size, Quality and tiny file size.
This was accomplished through the KorePhone's Æther OS v 0.1
http://i.imgur.com/j6L0Nrb.gif
******************************************************************
Updates listed by Date. Most recent first.
____________________________________________________________________
9-12-15
UPDATE:
The Coder who fell seriously ill a few months back is feeling well enough to do only the easiest coding work
so they decided they could at least make some simple apps and He recently posted them. If He feels a bit better
in the coming weeks and months He might tackle some of the more difficult apps and eventually be able to get the Æther OS on a device. One step at a time though. Just an hour meeting I recently had totally drained him and anyone who's been that ill knows what that is like.
Sincerely,
HD2
____________________________________________________________________
5-29-15
UPDATE:
***Not sure why people are getting the SDK Package Installer errors.
Please ensure you run the Installer with as an Administrator.
A library needs to be put into the GAC, so it may require Admin rights.
Below is a Manual Work Around.
Manual SDK install instructions:
Install the file "Æther OS Application Contracts.dll" into the Windows GAC using
the Visual Studio Command Prompt (with Admin privileges.)
Download link:
https://mega.nz/#!GUckEQaB!O1wrt6IIBkDj8AJT49Tfz6WUMXyXWWWwLDj6apq7xFE
SDK Files. Use them as previously described in this thread:
https://mega.nz/#!LcsxATSB!gcwzluEeGo6yoqujWy6rWNuZ2Di4yNRvLAmxxhb9npw
____________________________________________________________________
4-26-15
UPDATE:
After translating the majority of TOR over to Æther OS we decided to shelve the months worth of work.
Seeing how TOR works, it's unneeded bloat, flaws and it's Achilles heel
in it's exit nodes a decision was made to start from scratch.
The reasoning is the same that is the drive behind the Æther OS,
there has to be a better way that's more secure.
This was in mind prior to translating TOR into Æther OS taking months
deciphering how and why TOR works the way it does.
SEE OUR STATEMENT BELOW in our last Update announcement from 3-20-15:
"It's only the first step in our security endeavors we are bringing you and want to improve
the Æther OS security even beyond TOR."
Read the 1-6-15 Update as well...
This has been accomplished and is in testing.
____________________________________________________________________
3-20-15
UPDATE:
We promised to bring you a secure OS and mentioned we were working on additional security coding.
What we were working on is Translating TOR into the Æther OS which is just over 60% completed.
Those aware know this is a monumental task.
It's only the first step in our security endeavors we are bringing you and want to improve
the Æther OS security even beyond TOR.
____________________________________________________________________
1-30-15
We have added a huge coding task to the mix which has caused a delay in the hardware rendering and integration.
Soon as this security related coding endeavor is completed the hardware rendering will commence.
An update will follow when this transition happens.
____________________________________________________________________
1-6-15
Æther OS incorporates seamless Tor and VPN privacy protections. Developers need code only with similar objects and classes they are already familiar with within the .NET/Mono API and Æther takes care of the rest; however, this is merely the first implementation of the privacy layer and more seamless protections are being planned to be added: For example, what we shall refer to at present as "Tor 2.0" will add additional security and privacy protections to the platform and apps running on it.
____________________________________________________________________
1-5-15
New Release Additions: :good:
+ Video Input (input as webcam for emulation purposes)
+ Audio Output
+ Example app (including course code) showcases video input (as a box that can be moved around with the pointer) and audio output by audio generation when buttons are clicked.
+ Fully transparent Tor- and VPN-targeted classes which can be used (as alternatives) to the standard .NET implementations (e.g. AEtherSocket.) Full backend Tor and VPN infrastructure will be implemented on the device. For now the classes are there to be the methods and code building blocks by which seamless TCP security operations will take place in future, on the KOREphone.
+ Bug fixes
Æther SDK 0.3 Installer Full Package: NOTE: Some were getting error messages
so a "Manual Work Around was posted above. We are keeping this up till further notice
https://mega.co.nz/#!uRlHAaKS!Wzw8Q_0UhxMXFQN31NqnH5PMTAx1kDSpz29uKn0yeM8
:victory: All necessary APIs required in order to write 99% of apps is now complete (the exception being some games and apps that do 3D graphics.) Any extras which may be required will be added by request from any devs writing apps, of course.
The hardware rendering infrastructure is next, followed by hardware integration. In the meantime devs have essentially everything they would need in order to write their apps.
FYI: Attached is a summary of the OS components, it’s currently at just under 17K lines of code. That’s a lot more actual code; I’ve still yet to determine exactly how much that is but it’s easily double or triple the number.
____________________________________________________________________
PREVIOUS UPDATES
12-23-14
Combined and updated SINGLE DOWNLOAD Link:
OUTDATED SDK: DO NOT DOWNLOAD!
https://mega.co.nz/#!GI1H3IyI!v1GY3jSKnIkJfmQQV7bWEjwYNDL5pz7jUNMXu5P0Mlg
"I've made an installer, which takes care of stuff like adding assemblies to the GAC (so you don't need to do it manually).
[Which I tried to post here but the forum won't allow me to post links yet. I will ask HD2 to post it for me.]
The folders will go to the "Program Files (x86)" folder and a standalone emulator icon should be found on your Start Menu after the installation.
There are both C# and VB.NET Hello World examples with some added code demonstrating how to receive some events from the OS, such as "pointer down" and "pointer up" events, and "end app" event, delivered to the methods going by those names.
More to come within the next few days"
____________________________________________________________________
12-22-14
Updated API's, SDK, Documentation, Libraries, Explanations and Emulator info.
Outdated Links Removed:
"I've made an installer, which takes care of stuff like adding assemblies to the GAC (so you don't need to do it manually).
[Which I tried to post here but the forum won't allow me to post links yet. I will ask HD2 to post it for me.]
The folders will go to the "Program Files (x86)" folder and a standalone emulator icon should be found on your Start Menu after the installation.
There are both C# and VB.NET Hello World examples with some added code demonstrating how to receive some events from the OS, such as "pointer down" and "pointer up" events, and "end app" event, delivered to the methods going by those names.
More to come within the next few days"
____________________________________________________________________
12-19-14
More API's now fully Completed:
+ GPS
+ Gyroscope
+ Accelerometer
+ ÆtherTextBox
Plus a bug or two fixed!
____________________________________________________________________
12-15-14
Here is the Initial Introduction and essential API's and working Emulator. RE: the Components of the SDK.
This is undeniable evidence the Æther Kripton Mobile OS has been coded.
Detailed Explanation being compiled...
OUTDATED. Do not download.
https://mega.co.nz/#!qFlRkTpQ!Yn64mclLI4LnFz7iPYowf4LoJMBjOwch-egT3ueg4i8
Details are in the included NotePad File.
________________________________________________________________
12-13-14
Release date for Essential API's, SDK and Documentation: 12-15-14 --- Released.
_________________________________________________________________
11-27-14
We are in the process of requesting a separate Æther OS section on the XDA Forums.
The thread will be notified the outcome and if we cannot work something out there
we will create our own unique KorePhone Æther OS Developers Forum.
__________________________________________________________________
"Hi,
A new phone OS has been developed.
We are requesting it be listed as:
Æther OS
Could it be listed in it's above unique form.
Sincerely,
__________________________________________________________________
Sent to XDA Forums Administrator:
11-28-14
Hi,
I'm doing some leg work for a new OS under development called Æther OS.
It's booted in the Emulator and in next few weeks hope to have it on a device.
The RPI Reference is under development and may be posted in increments
so Apps could be developed sooner.
We would like to get a listing located next to "Jolla SailFish" , "Ubuntu Touch" and "Firefox OS"
since it is an OS.
I emailed twice over the last few days with no reply and we were hoping to get the listing
by Monday 12-1-14.
Please advise.
Most Sincerely,
___________________________________________________________________________________________
XDA:DevDB Information
☑ �ther OS App Coders Wanted, App for all devices (see above for details)
Contributors
HD2 crosshair
Version Information
Status: Testing
Created 2014-11-29
Last Updated 2015-10-18
Welcome!
This post Reserved for Testing and special announcements.
Bump after a slow weekend.
Example App
I'm the Dev for this project. For anyone who might be interested, here is some sample code for a simple app (the "Hello World" app.)
APIs are being worked on. So far there are some essential data types and GUI objects. Things are still in early stages of development although the OS is working well enough to be able to write apps with rudimentary GUI features thus-far. MUCH more to come.
Stay tuned.
public:
class Program
{
static Thread MainThread;
static void Main()
{
MainThread = new Thread(DoMainThread);
MainThread.Start();
}
static void DoMainThread()
{
_PrimarySurface = new ÆtherSurface();
_PrimarySurface.BackgroundColour = new ÆtherColour(138, 45, 228);
const float S = 0.48f;
var C1 = new ÆtherEllipse("Yellow Circle 1", new ÆtherPoint(0, 0), new ÆtherSize(S, S), new ÆtherColour(255, 255, 0));
_PrimarySurface.AddControl(C1);
var T1 = new ÆtherLabel("Label 1", new ÆtherPoint(), new ÆtherColour(30, 144, 255), "Segoe UI", 35f, ÆtherFontStyle.Bold, ÆtherTextAlignment.Centre);
T1.Text = "Hello";
_PrimarySurface.AddControl(T1);
var T2 = new ÆtherLabel("Label 2", new ÆtherPoint(), new ÆtherColour(30, 144, 255), "Segoe UI", 35f, ÆtherFontStyle.Bold, ÆtherTextAlignment.Centre);
T2.Text = "World!";
_PrimarySurface.AddControl(T2);
var Pulse = new AutoResetEvent(false);
while (true) {
C1.Position.X = _PointerInfo1.Position.X - S * 0.5f;
C1.Position.Y = _PointerInfo1.Position.Y - S * 0.5f;
T1.Position.X = _PointerInfo1.Position.X;
T1.Position.Y = _PointerInfo1.Position.Y - 0.06f;
T2.Position.X = _PointerInfo1.Position.X;
T2.Position.Y = _PointerInfo1.Position.Y + 0.06f;
RaiseEvent_UpdateSurface();
Pulse.WaitOne(48);
}
}
UPDATE:
The Code is progressing nicely with over 7,400 lines of written code.
Some bugs were dealt with and the OS is performing smoothly.
Essential API's, Documentation and a basic SDK should be released in a week.
We are hoping to present what's needed for a Live Video App.
The GIF showing the inclusion of the korecoin wallet app.
So, is this how an operating system for bankers as it was featured on finances?
Gesendet von meinem XT1039 mit Tapatalk
This looks too much as some kind of android fork to me and what kind of lunetic would nowdays choose java as platform for mobile os?
keenofhiphop said:
So, is this how an operating system for bankers as it was featured on finances?
Gesendet von meinem XT1039 mit Tapatalk
Click to expand...
Click to collapse
Thanks KEEN,
And Keen and Hip you are to the issues of the day.
I tend to use the word "banksters" myself.
Actually it's fantastic to see what HipHop is doing again.
Check out "The Real News Network" on YouTube.
No worries here and thanks for bringing this very important topic to light.
Sincerely,
HD2
Puresoul_CZ said:
This looks too much as some kind of android fork to me and what kind of lunetic would nowdays choose java as platform for mobile os?
Click to expand...
Click to collapse
Hiya PureSoul,
You will be pleasantly surprised and we are looking for "Skilled Coders to Translate".
Best and hope to see you around.
BTW- My sis was in Prague a few years ago looking for our lineage
that took her across a few countries boundaries as the borders were constantly rearranged.
HD2
Nice to hear that, is there some public git or svn?
HD2 crosshair said:
Hiya PureSoul,
You will be pleasantly surprised and we are looking for "Skilled Coders to Translate".
Best and hope to see you around.
BTW- My sis was in Prague a few years ago looking for our lineage
that took her across a few countries boundaries as the borders were constantly rearranged.
HD2
Click to expand...
Click to collapse
Puresoul_CZ said:
Nice to hear that, is there some public git or svn?
Click to expand...
Click to collapse
We are not publishing the Code at this time
and are looking for app Coders to translate apps for the Æther Krypton OS.
Wait, so is this just a heavily modified Android fork or a built-from-the-ground-up completely new OS?
What language do you guys use for this OS?
Puresoul_CZ said:
Nice to hear that, is there some public git or svn?
Click to expand...
Click to collapse
SynchroDrive said:
Wait, so is this just a heavily modified Android fork or a built-from-the-ground-up completely new OS?
What language do you guys use for this OS?
Click to expand...
Click to collapse
It's not a fork.
The Essential API's, SDK and Documentation are being worked on and will be released soon.
More information will be provided at that time.
UPDATE:
The ÆTHER 0.1 Krypton OS now has over 8,000 lines of written code and more importantly is it's level of quality.
Still functioning very smoothly.
We are on schedule for the release date of December 12th for the API's, Documentation and SDK.
http://i.imgur.com/95kJAnN.png
Here is the latest GIF with a few extra included apps.
Just to update the thread: Work on the APIs is still underway. Hopefully there will be something to share not too long from now.
Recent News:
http://www.cryptoarticles.com/press-releases/korecoins-ther-kripton-os-coming-to-a-korephone-near-you
Elemental121212 said:
Just to update the thread: Work on the APIs is still underway. Hopefully there will be something to share not too long from now.
Click to expand...
Click to collapse
KOREPHONE CODER UPDATE:
The Coder putting together the app package has been experiencing rolling power outages
that's been disrupting his work the last few weeks.
He spent last few days researching and going into town to get a fairly large UPS and a 102ah Battery
giving him a considerable amount of time. Well over 6 hours backup.
The release date for the API's, SDK and Documentation is the 15th.
Soon as these are released the app coders can all get started and we can move onto hardware integration.
Though they could have it finished in next few days he's going to wire that set up for when the power goes out.
Better to have a date they could easily make.
If it's completed earlier it will be posted earlier.
Sincerely,
HD2
Release date for the essential API's, SDK and Documentation.
12-15-2014.
Essential API's and working Emulator for the Æther Kripton Mobile OS
Here is the Initial Introduction and essential API's and working Emulator. RE: the Components of the SDK.
This is undeniable evidence the Æther Kripton Mobile OS has been coded.
Detailed Explanation being compiled...
https://mega.co.nz/#!qFlRkTpQ!Yn64mclLI4LnFz7iPYowf4LoJMBjOwch-egT3ueg4i8
Details are in the included NotePad File.
HD2 crosshair said:
Here is the Initial Introduction and essential API's and working Emulator. RE: the Components of the SDK.
This is undeniable evidence the Æther Kripton Mobile OS has been coded.
Detailed Explanation being compiled...
https://mega.co.nz/#!qFlRkTpQ!Yn64mclLI4LnFz7iPYowf4LoJMBjOwch-egT3ueg4i8
Details are in the included NotePad File.
Click to expand...
Click to collapse
Woah. It's only 220 KB?
Okay, can you show the OS running on a phone?
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.
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
I've been working on my own assistant application framework for some time now, and I am coming up to a point where it is functional for an alpha release. There aren't really any other FOSS assistants on the market other than Mycroft, and I noticed that there is no development happening on Saiy/Utter!.
I've been developing it heavily using a Unix mentality which is meant to reduce the mental overhead when it comes to creating skills or new/replacement modules. I paid a lot of attention to the development of the framework so that individual components can be developed or replaced independently, allowing it to be more of a platform than a standalone application. This should also allow it to be easier to dive into individual parts of the application.
There is still a lot to go in terms of making it useful out of the box, but it's almost all there in back end, and I think I'm finishing up the concrete features and flags that it needs to operate with skills and modules that other users develop.
As it is right now, it does offline speech recognition using Vosk STT, and intent matching/entity extraction using the Stanford Core NLP library. I have it set up with a mock Calendar Skill to test its matching and finalize how I want it to interface with complex tasks. Currently it *WILL NOT COMPILE OR WORK* since I am still working out bugs on the alpha. When I am ready to release an actual alpha I'll branch the code, and I'll post/host nightlys somewhere (maybe also put it on F-Droid and Google Play).
I intend to interface it with Termux/Tasker, Google Assistant, Alexa, and Mycroft, as well as at a chatbot feature, but those are all secondary to the task of a stable working assistant/platform. I encourage feedback and questions about how it works and how it could be hacked on to do other things, so that I can write documentation that is as transparent and understandable as possible. Hopefully the code is a bit self documenting as well. I strive for readability over cunning.
Here's the link: https://github.com/Tadashi-Hikari/Sapphire-Assistant-Framework
Let me know what you think