I have a knack to take up old android projects that have been left in the dust and see if they have potential with our current devices and most used Android OS. This current project takes place of something that some of us remember and some of us that never even knew that it existed because the basic functionality of it was eh... So...Here we go.
Welcome to the Slab Open Beta! Slab is currently in development and you will encounter things of un-natural application behavior or just not working.
Slab is a fork of CyanogenMods CMhome application from cm11 rebooted as a Material application and supporting On-Tap on Android 5+. Android N is not officially supported at this time, more testing is underway. Slab will be open sourced in do time once everything is back to working order. My goal is to see this application back in CyanogenMod builds but I'm probably asking for to much.
Slab is a Dashclock extension host application that uses Dashclock widget apps and showcases them in a dashboard like approach. Use the most right fab to clear the "Slab" and use the most left fab to refresh the "Slab". Use the middle fab to bring up a bottom menu of which has a built in Google Search method for users who want to replace Google On-Tap with Slab. To set Slab as a On-Tap application, navigate to the app settings in the android setting and select the menu item default apps, than select assist apps and choose voice application as Slab. If the "Slab" is clear on launch, simply press the clear fab and refresh fab.
Current Issues:
Slab is still experiencing some force closes on entering and exiting so just ignore those until I find methods around them. Click on the Check menu item to exit the application without it hanging and causing errors after you've exiting and it monitors Dashclock Extensions successfully.
Some Extensions are locked to Dashclock Widget which is running out of date and I hope 3rd party extension devs take the time to understand this and allow them to be more free for apps like Chronus and Slab.
I want Slab to operate without the Dashclock Widget app installed.
Goal is to allow it to monitor Extensions without the use of Dashclock Widget installed.
Contributing:
If you'd like to contribute and have free time, I'll push this to github sooner than I plan to only if devs actively want to contribute. I don't want a grab and go operation. If no one wants to contribute than be patient with updates as I maintain other more important projects. This one is just for experience and free time.
Works well on AOSP and CyanogenMod firmware. Im building this application using Android Studio on Ubuntu 16.10, A Nexus 7 2013 with an AOSP 7.1 rom I built myself (Usually flashing different roms for different project reasons), my HTC10 and ofcourse the Virtual SDK.
Again, Application is not complete so some things are either not working correctly or null.
Join the Google Plus Group for bug reports and other community information.
Google Play Link
XDA:DevDB Information
Slab, App for all devices (see above for details)
Contributors
Nx Biotic
Version Information
Status: Beta
Current Beta Version: 1.10.11
Beta Release Date: 2016-11-06
Created 2016-11-07
Last Updated 2016-11-07
https://youtu.be/L5ZQaj3eQRg
Small demo of the application running. Found that heavily modified or skinned firmware have a hard time running this app. Android 7 has a hard time using the Dashclock host, probably need to build a helper app.
Troubleshooting
The app is not 100 percent yet and you may come to install it and it may seem like its not working but its just hanging and confused so here is a tip to get it working.
Go ahead and Uninstall Slab. Install Dashclock Widget and a few Dashclock Extensions. Now install Slab and check your results.
I may take some time and develop a helper class to replace Dashclock Widget as it seems to be getting outdated. I wish Dlab to be a replacement.
Related
Hi All,
While working on a Software project where I bumped into this typical software development problem;
I wanted to test my app in the field using beta testers, but didn't want to use the Android Market yet because the app isn't "Market-Ready" yet. (Or you couldnt use the Market because its an enterprise app.) I figured it would be nice to have a separate app which updates your (beta) apps. This way you only have to tell your users to run this Remote Software Deployment app, and your beta applications get updated.
I have made a simple "Remote Software Deployment" tool, which enables developers to update their app using a webserver.
The app loads URLs from its resources, downloads the APKs and installs them.
I figured that more developers like me are searching for the exact same thing and decided to share and ask you to participate. I would love having some fellow developers develop this app with me. This way we can add more functionality's and use it in our own projects.
Still todo (rev #2):
- Better feedback to the user about the current download state
- Automatic exit after all apps are updated
Todo future features:
- login / secure connection to the server
- Add a local database, so versions can be checked to the ones on the server
- Options screen where the app can be configured (with password that can be changed via resources > Strings > adminpassword)
- Enable the app to be launched at boot / run as a constant service ; polling every x minutes/hours/days etc.
Official homepage on Google Code:
- Cannot post links yet, search google code for remote-software-deployment-for-android
Link to the Source Code (SVN):
- Cannot post links yet, search google code for remote-software-deployment-for-android
So, who wants to help?
Cheers,
~NLS
Looks Good!
~Bump
Would like to see a Alpha version
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!
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
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