Initial commit.

.gitignore

@@ -0,0 +1,16 @@
+.DS_Store
+*.keystore
+.idea
+*.iml
+bin
+gen
+target
+gen-external-apklibs
+out
+proguard_logs
+build
+.gradle
+obj
+*.apk
+local.properties
+captures

.travis.yml

@@ -0,0 +1,18 @@
+sudo: false
+
+language: android
+jdk: oraclejdk8
+
+before_cache:
+  - rm -f  $HOME/.gradle/caches/modules-2/modules-2.lock
+  - rm -fr $HOME/.gradle/caches/*/plugin-resolution/
+
+cache:
+  directories:
+    - $HOME/.gradle/caches/
+    - $HOME/.gradle/wrapper/
+
+script:
+  - mkdir -p $ANDROID_HOME/licenses
+  - echo "8933bad161af4178b1185d1a37fbf41ea5269c55" > $ANDROID_HOME/licenses/android-sdk-license
+  - ./gradlew --no-daemon clean lib:testRelease

CONTRIBUTING.md

@@ -0,0 +1,64 @@
+# Contributing
+
+Constructive contributions to the project are very welcome, provided they meet certain requirements. This document details the various ways in which it is possible to contribute, and the requirements for each.
+
+## Apparent Bug Reports
+
+Please file an issue in the Github repository [here](https://github.com/Coiney/TrueBlue/issues).
+
+The repository contains a default template which will be displayed when creating a new issue. Please follow the template to provide the required information. 
+
+Please remember to be as detailed as possible when filing an issue. The more information we have, the more likely we are to be able to investigate and resolve it in a timely fashion.
+
+Further, wherever possible, please include sample code which provides a Minimum, Complete, and Verifiable example demonstrating the exact issue is very welcome and greatly appreciated.
+
+We strongly recommend that issues be filed in English. We will certainly do our best to respond to all issues regardless of language, but please understand that we may not be able to respond to issues filed in other languages in a timely fashion or even at all.
+
+
+## Questions, Requests, etc.
+
+Please file an issue in the Github repository [here](https://github.com/Coiney/TrueBlue/issues).
+
+The repository contains a default template which will be displayed when creating a new issue. This template is designed primarily for the reporting of apparent bugs, so please do feel free to delete it and enter free text.
+
+As per apparent bug reports, we would ask that you provide as much information as possible, and strongly recommend that issues be filed in English.
+
+
+## Code (Bug fixes, enhancments, features, etc.)
+
+We welcome any and all constructive code contributions to the project, provided they meet certain requirements.
+
+We always appreciate an issue being created before code is submitted. This helps give us the background we need to do things like confirm issues and decide whether or not a feature is something that fits in with the roadmap for this repository.
+
+If you'd like to contribute code you will need to file a pull request on the original repository. Pull requests must target the `develop` branch. Please see the "Branching" section below for more details on how to prepare and name branches for code changes.
+
+Please understand that due to time constraints and the roadmap for this repository, we cannot guarantee that all contributions will be accepted.
+
+### Code Style
+
+We have not defined a strict code style for the project yet, so please follow what you see in the repository as best you can.
+
+### Tests
+
+Wherever reasonably possible, please add/update the tests appropriately as part of the code you submit as a PR.
+
+### Javadoc
+
+All public classes, interfaces, enums etc. and any methods on them which are not located under the `internal` package must have Javadoc describing their purpose.
+
+As per our code style we have not yet defined a strict standard for Javadoc, so please follow what you see in the repository as best you can.
+
+All documentation must be prepared in English. Please do let us know if you require assistance preparing the documentation - we are more than happy to help.
+
+### Branching
+
+We use [git flow](http://nvie.com/posts/a-successful-git-branching-model/) when working on this repository, and highly recommend that contributors do too.
+
+When preparing a branch for contributing changes:
+
+1. Make sure that the `develop` branch in your cloned repository is up to date with the `develop` branch in the original repository.
+2. Cut a branch from `develop` in your cloned repository with a name fitting the pattern `feature/<description>`.
+
+The description must be in English and should provide a clear, conscise summary of the content of and/or reason for the code change that will be made in the branch. Please aim to keep the description to no more than 30 characters.
+
+When ready, raise a PR for the branch on the original repository with `develop` as the target branch.

ISSUE_TEMPLATE.md

@@ -0,0 +1,48 @@
+### Library Information
+
+Version: 
+
+
+### Build Environment
+
+IDE:
+Version:
+
+Build system:
+Version:
+
+
+#### Device Information (if applicable)
+
+Manufacturer:
+Model:
+OS version:
+
+
+#### Steps to Reproduce
+
+1. 
+
+
+#### Expected Result
+
+1. 
+
+
+#### Actual Result
+
+1. 
+
+
+#### Probability
+
+
+
+#### Sample Code
+
+Please provide a link to a Minimal, Complete and Verifiable working example which clearly demonstrates the issue:
+
+
+
+#### Other Comments (if any)
+

PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,13 @@
+#### Summary
+
+
+
+#### Issues
+
+Please link to any issues which this PR purports to close:
+
+Closes #
+
+
+#### QA / Testing Methodology
+

README.md

@@ -0,0 +1,102 @@
+# TrueBlue
+
+### BETA WARNING
+
+This library is current in beta. All APIs are subject to change without notice.
+
+
+## Introduction
+
+TrueBlue is a small wrapper service around the Android Bluetooth subsystem. It is designed to make 
+interacting with Bluetooth on Android, which can be quite low level and frustrating at times, simpler.
+
+In summary, its functionality includes:
+
+1. Bluetooth adapter/subsystem management;
+2. Bluetooth device pairing and connectivity management; and
+3. Bluetooth discovery scanning.
+
+For the sake of clarity, the service does *not* currently support:
+
+* Bluetooth LE
+* Bluetooth profiles
+* Bluetooth device connectivity as a "server" (as opposed to as a client)
+
+
+## Installation
+
+#### Gradle
+
+Coming soon ...
+
+
+## Initialization
+
+Before the service can be used it must be initialized with a `Context`. This need (and generally should) only be done once, so one good place to do this is in an `Application` subclass (if you have one). For example:
+
+```
+public final class MyApplication extends Application {
+
+    @Override
+    public void onCreate() {
+        super.onCreate();
+        TrueBlue.init(getApplicationContext());
+    }
+}
+```
+
+Another good alternative is to initialize via a DI framework such as Dagger 2. See below for a very simple example:
+
+```
+@Singleton
+@Module
+public class MyModule {
+
+    @Provides
+    TrueBlue provideBluetoothService(Context context) {
+        return TrueBlue.init(context);
+    }
+}
+```
+
+Once initialized, an instance of the service can be obtained for use as required using `TrueBlue.getInstance()`.
+
+Be aware that it is always possible to initialize and obtain an instance of the service, even when no Bluetooth subsystem is available (e.g. emulators). In this situation methods pertaining to the availability and status of Bluetooth will work as expected, but the majority of other features will simply be no-ops.
+
+
+## Usage
+
+Please refer to the [project wiki](https://github.com/Coiney/TrueBlue/wiki/Usage) and Javadoc for 
+more detailed information regarding usage.
+
+
+## Test Application
+
+The project contains a simple test application designed to exercise most of the features provided by the service. It is admittedly rather contrived and overly simple in certain places, but should at least provide a basic example of how the service can be used.
+
+
+## Contributing
+
+Please see [here](CONTRIBUTING.md) for detailed information on contributing to this project.
+
+Additionally, a project [roadmap](ROADMAP.md) exists which details features we are currently considering implementing.
+
+
+## License
+
+```
+Copyright 2017 Coiney, Inc.
+Copyright 2016 - 2017 Daniel Carter
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+```

RELEASE_NOTES.md

@@ -0,0 +1,27 @@
+### TrueBlue version 0.1.0
+
+Initial release.
+
+#### Features
+
+None.
+
+#### Enhancements
+
+None.
+
+#### Bug Fixes
+
+None.
+
+#### Changes
+
+None.
+
+#### Other
+
+None.
+
+#### Requirements
+
+* Android 2.3 and up (Gingerbread, API 9 and up).

ROADMAP.md

@@ -0,0 +1,43 @@
+# Roadmap for TrueBlue
+
+This file lists features which are planned for implementation or may be considered for implementation in the future.
+
+### Bluetooth Profiles
+
+Full support for these as per the Bluetooth guide. 
+
+### Bluetooth LE
+
+Full support for this as per the Bluetooth guide. 
+
+### Bluetooth Server Support
+
+Full support for this as per the Bluetooth guide. 
+
+### Pairing
+
+* Add a pairing (only) feature. This would be easy on APIs 19+ as the Android Bluetooth subsystem supports this, but on earlier versions we would either need to connect and disconnect (messy), or just connect and explain this in the documentation.
+* Add a pairing event listener similar to the existing device connectivity listener.
+* Add support for "unpairing" (removing bonds).
+
+### Connecting
+
+* Provide a means to obtain the instance of the class implementing the `Connection` interface for a given Bluetooth device which has already been connected to via the service after the fact. Currently this is only available via `ConnectionAttemptCallback` when the device is successfully connected to.
+* Attempt to provide a means to prevent pairing with devices which are already paired with. Alternatively, permit this but provide a warning.
+
+### Connections
+
+* Decide whether the asynchronous connection client write error and write success callbacks should return the written data or not.
+* Potentially limit the amount of data which can be written via the asynchronous connection client to prevent the queues getting too large.
+* Add metadata such as the dates and times connections are established.
+* Introduce additional monitoring to ensure that connection tasks and so on never get stuck.
+
+### General
+
+* Consider simplifying concurrency by using `HandlerThread` behind the scenes instead of `Thread` and `ExecutorService`. A few things to consider:
+  * This approach could be difficult for certain tasks such as connecting to Bluetooth devices, which is very complex. Mind you, that very complexity could be at least in part due to the current approach to concurrency, and in any event suggests that there is probably a better way.
+  * The impact on the service interface - in particular, on what is synchronous and what is asynchronous. Methods like `isDeviceConnected` are currently synchronous, and to retain that approach we would probably still need to use synchronisation behind the scenes. The alternative is to go asynchronous, but this seems like it might be overkill (and frustrating?) for simpler tasks.
+
+### Tests
+
+* Improve and expand test coverage.

app/.gitignore

@@ -0,0 +1 @@
+/build