mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-25 23:11:02 +08:00
VicYu
GitHub
commit
dfbf7d3558
@ -1,3 +1,5 @@
|
||||
Firstadream translating
|
||||
|
||||
[How debuggers work: Part 2 - Breakpoints][26]
|
||||
============================================================
|
||||
|
||||
|
||||
@ -1,140 +0,0 @@
|
||||
|
||||
Translating by fristadream
|
||||
|
||||
Will Android do for the IoT what it did for mobile?
|
||||
============================================================
|
||||
|
||||
|
||||
|
||||
Android Things gives the IoT Wings
|
||||
|
||||
### My first 24 hours with Android Things
|
||||
|
||||
Just when I was in the middle of an Android based IoT commercial project running on a Raspberry Pi 3, something awesome happened. Google released the first preview of [Android Things][1], their SDK targeted specifically at (initially) 3 SBC’s (Single Board Computers) — the Pi 3, the Intel Edison and the NXP Pico. To say I was struggling is a bit of an understatement — without even an established port of Android to the Pi, we were at the mercy of the various quirks and omissions of the well-meaning but problematic homebrew distro brigade. One of these problems was a deal breaker too — no touchscreen support, not even for the official one sold by [Element14][2]. I had an idea Android was heading for the Pi already, and earlier a mention in a [commit to the AOSP project from Google][3] got everyone excited for a while. So when, on 12th Dec 2016, without much fanfare I might add, Google announced “Android Things” plus a downloadable SDK, I dived in with both hands, a map and a flashlight, and hung a “do not disturb” sign on my door…
|
||||
|
||||
### Questions?
|
||||
|
||||
I had many questions regarding Googles Android on the Pi, having done extensive work with Android previously and a few Pi projects, including being involved right now in the one mentioned. I’ll try to address these as I proceed, but the first and biggest was answered right away — there is full Android Studio support and the Pi becomes just another regular ADB-addressable device on your list. Yay! The power, convenience and sheer ease of use we get within Android Studio is available at last to real IoT hardware, so we get all the layout previews, debug system, source checkers, automated tests etc. I can’t stress this enough. Up until now, most of my work onboard the Pi had been in Python having SSH’d in using some editor running on the Pi (MC if you really want to know). This worked, and no doubt hardcore Pi/Python heads could point out far better ways of working, but it really felt like I’d timewarped back to the 80’s in terms of software development. My projects involved writing Android software on handsets which controlled the Pi, so this rubbed salt in the wound — I was using Android Studio for “real” Android work, and SSH for the rest. That’s all over now.
|
||||
|
||||
All samples are for the 3 SBC’s, of which the the Pi 3 is just one. The Build.DEVICE constant lets you determine this at runtime, so you see lots of code like:
|
||||
|
||||
```
|
||||
public static String getGPIOForButton() {
|
||||
switch (Build.DEVICE) {
|
||||
case DEVICE_EDISON_ARDUINO:
|
||||
return "IO12";
|
||||
case DEVICE_EDISON:
|
||||
return "GP44";
|
||||
case DEVICE_RPI3:
|
||||
return "BCM21";
|
||||
case DEVICE_NXP:
|
||||
return "GPIO4_IO20";
|
||||
default:
|
||||
throw new IllegalStateException(“Unknown Build.DEVICE “ + Build.DEVICE);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Of keen interest is the GPIO handling. Since I’m only familiar with the Pi, I can only assume the other SBCs work the same way, but this is the set of pins which can be defined as inputs/outputs and is the main interface to the physical outside world. The Pi Linux based OS distros have full and easy support via read and write methods in Python, but for Android you’d have to use the NDK to write C++ drivers, and talk to these via JNI in Java. Not that difficult, but something else to maintain in your build chain. The Pi also designates 2 pins for I2C, the clock and the data, so extra work would be needed handling those. I2C is the really cool bus-addressable system which turns many separate pins of data into one by serialising it. So here’s the kicker — all that’s done directly in Android Things for you. You just _read()_and _write() _to/from whatever GPIO pin you need, and I2C is as easy as this:
|
||||
|
||||
```
|
||||
public class HomeActivity extends Activity {
|
||||
// I2C Device Name
|
||||
private static final String I2C_DEVICE_NAME = ...;
|
||||
// I2C Slave Address
|
||||
private static final int I2C_ADDRESS = ...;
|
||||
|
||||
private I2cDevice mDevice;
|
||||
|
||||
@Override
|
||||
protected void onCreate(Bundle savedInstanceState) {
|
||||
super.onCreate(savedInstanceState);
|
||||
// Attempt to access the I2C device
|
||||
try {
|
||||
PeripheralManagerService manager = new PeripheralManagerService();
|
||||
mDevice = manager.openI2cDevice(I2C_DEVICE_NAME, I2C_ADDRESS)
|
||||
} catch (IOException e) {
|
||||
Log.w(TAG, "Unable to access I2C device", e);
|
||||
}
|
||||
}
|
||||
|
||||
@Override
|
||||
protected void onDestroy() {
|
||||
super.onDestroy();
|
||||
|
||||
if (mDevice != null) {
|
||||
try {
|
||||
mDevice.close();
|
||||
mDevice = null;
|
||||
} catch (IOException e) {
|
||||
Log.w(TAG, "Unable to close I2C device", e);
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### What version of Android is Android Things based on?
|
||||
|
||||
This looks to be Android 7.0, which is fantastic because we get all the material design UI, the optimisations, the security hardening and so on from all the previous versions of Android. It also raises an interesting question — how are future platform updates rolled out, as opposed to your app which you have to manage separately? Remember, these devices may not be connected to the internet. We are no longer in the comfortable space of cellular/WiFi connections being assumed to at least be available, even if sometimes unreliable.
|
||||
|
||||
The other worry was this being an offshoot version of Android in name only, where to accommodate the lowest common denominator, something so simple it could power an Arduino has been released — more of a marketing exercise than a rich OS. That’s quickly put to bed by looking at the [samples][4], actually — some even use SVG graphics as resources, a very recent Android innovation, rather than the traditional bitmap-based graphics, which of course it also handles with ease.
|
||||
|
||||
Inevitably, regular Android will throw up issues when compared with Android Things. For example, there is the permissions conundrum. Mitigated somewhat by the fact Android Things is designed to power fixed hardware devices, so the user wouldn’t normally install apps after it’s been built, it’s nevertheless a problem asking them for permissions on a device which might not have a UI! The solution is to grant all the permissions an app might need at install time. Normally, these devices are one app only, and that app is the one which runs when it powers up.
|
||||
|
||||
|
||||
|
||||
### What happened to Brillo?
|
||||
|
||||
Brillo was the codename given to Googles previous IoT OS, which sounds a lot like what Android Things used to be called. In fact you see many references to Brillo still, especially in the source code folder names in the GitHub Android Things examples. However, it has ceased to be. All hail the new king!
|
||||
|
||||
### UI Guidelines?
|
||||
|
||||
Google issues extensive guidelines regarding Android smartphone and tablet apps, such as how far apart on screen buttons should be and so on. Sure, its best to follow these where practical, but we’re not in Kansas any more. There is nothing there by default — it’s up the the app author to manage _everything_. This includes the top status bar, the bottom navigation bar — absolutely everything. Years of Google telling Android app authors never to render an onscreen BACK button because the platform will supply one is thrown out, because for Android Things there [might not even be a UI at all!][5]
|
||||
|
||||
### How much support of the Google services we’re used to from smartphones can we expect?
|
||||
|
||||
Quite a bit actually, but not everything. The first preview has no bluetooth support. No NFC, either — both of which are heavily contributing to the IoT revolution. The SBC’s support them, so I can’t see them not being available for too long. Since there’s no notification bar, there can’t be any notifications. No Maps. There’s no default soft keyboard, you have to install one yourself. And since there is no Play Store, you have to get down and dirty with ADB to do this, and many other operations.
|
||||
|
||||
When developing for Android Things I tried to make the same APK I was targeting for the Pi run on a regular handset. This threw up an error preventing it from being installed on anything other than an Android Things device: library “_com.google.android.things_” not present. Kinda makes sense, because only Android Things devices would need this, but it seemed limiting because not only would no smartphones or tablets have it present, but neither would any emulators. It looked like you could only run and test your Android Things apps on physical Android Things devices … until Google helpfully replied to my query on this in the [G+ Google’s IoT Developers Community][6] group with a workaround. Bullet dodged there, then.
|
||||
|
||||
### How can we expect the Android Things ecosystem to evolve now?
|
||||
|
||||
I’d expect to see a lot more porting of traditional Linux server based apps which didn’t really make sense to an Android restricted to smartphones and tablets. For example, a web server suddenly becomes very useful. Some exist already, but nothing like the heavyweights such as Apache or Nginx. IoT devices might not have a local UI, but administering them via a browser is certainly viable, so something to present a web panel this way is needed. Similarly comms apps from the big names — all it needs is a mike and speaker and in theory it’s good to go for any video calling app, like Duo, Skype, FB etc. How far this evolution goes is anyone’s guess. Will there be a Play Store? Will they show ads? Can we be sure they won’t spy on us, or let hackers control them? The IoT from a consumer point of view always was net-connected devices with touchscreens, and everyone’s already used to that way of working from their smartphones.
|
||||
|
||||
I’d also expect to see rapid progress regarding hardware — in particular many more SBC’s at even lower costs. Look at the amazing $5 Raspberry Pi Zero, which unfortunately almost certainly can’t run Android Things due to its limited CPU and RAM. How long until one like this can? It’s pretty obvious, now the bar has been set, any self respecting SBC manufacturer will be aiming for Android Things compatibility, and probably the economies of scale will apply to the peripherals too such as a $2 3" touchscreen. Microwave ovens just won’t sell unless you can watch YouTube on them, and your dishwasher just put in a bid for more powder on eBay since it noticed you’re running low…
|
||||
|
||||
However, I don’t think we can get too carried away here. Knowing a little about Android architecture helps when thinking of it as an all-encompassing IoT OS. It still uses Java, which has been hammered to death in the past with all its garbage-collection induced timing issues. That’s the least of it though. A genuine realtime OS relies on predictable, accurate and rock-solid timing or it can’t be described as “mission critical”. Think about medical applications, safety monitors, industrial controllers etc. With Android, your Activity/Service can, in theory, be killed at any time if the host OS thinks it needs to. Not so bad on a phone — the user restarts the app, kills other apps, or reboots the handset. A heart monitor is a different kettle all together though. If that foreground Activity/Service is watching a GPIO pin, and the signal isn’t dealt with exactly when it is supposed to, we have failed. Some pretty fundamental changes would have to be made to Android to support this, and so far there’s no indication it’s even planned.
|
||||
|
||||
### Those 24 hours
|
||||
|
||||
So, back to my project. I thought I’d take the work I’d done already and just port as much as I could over, waiting for the inevitable roadblock where I had to head over to the G+ group, cap in hand for help. Which, apart from the query about running on non-AT devices, never happened. And it ran great! This project uses some oddball stuff too, custom fonts, prescise timers — all of which appeared perfectly laid out in Android Studio. So its top marks from me, Google — at last I can start giving actual prototypes out rather than just videos and screenshots.
|
||||
|
||||
### The big picture
|
||||
|
||||
The IoT OS landscape today looks very fragmented. There is clearly no market leader and despite all the hype and buzz we hear, it’s still incredibly early days. Can Google do to the IoT with Android Things what it did to mobile, where it’s dominance is now very close to 90%? I believe so, and if that is to happen, this launch of Android Things is exactly how they would go about it.
|
||||
|
||||
Remember all the open vs closed software wars, mainly between Apple who never licence theirs, and Google who can’t give it away for free to enough people? That policy now comes back once more, because the idea of Apple launching a free IoT OS is as far fetched as them giving away their next iPhone for nothing.
|
||||
|
||||
The IoT OS game is wide open for someone to grab, and the opposition won’t even be putting their kit on this time…
|
||||
|
||||
Head over to the [Developer Preview][7] site to get your copy of the Android Things SDK now.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://medium.com/@carl.whalley/will-android-do-for-iot-what-it-did-for-mobile-c9ac79d06c#.hxva5aqi2
|
||||
|
||||
作者：[Carl Whalley][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://medium.com/@carl.whalley
|
||||
[1]:https://developer.android.com/things/index.html
|
||||
[2]:https://www.element14.com/community/docs/DOC-78156/l/raspberry-pi-7-touchscreen-display
|
||||
[3]:http://www.androidpolice.com/2016/05/24/google-is-preparing-to-add-the-raspberry-pi-3-to-aosp-it-will-apparently-become-an-officially-supported-device/
|
||||
[4]:https://github.com/androidthings/sample-simpleui/blob/master/app/src/main/res/drawable/pinout_board_vert.xml
|
||||
[5]:https://developer.android.com/things/sdk/index.html
|
||||
[6]:https://plus.google.com/+CarlWhalley/posts/4tF76pWEs1D
|
||||
[7]:https://developer.android.com/things/preview/index.html
|
||||
@ -0,0 +1,129 @@
|
||||
|
||||
安卓IoT能否像在移动终端一样成功？
|
||||
============================================================
|
||||
|
||||
|
||||
Android Things让IoT如虎添翼
|
||||
|
||||
###我在Android Things上的最初24小时
|
||||
正当我在开发一个基于Android的运行在树莓派3的物联网商业项目时，一些令人惊喜的事情发生了。谷歌发布了[Android Things] [1]的第一个预览版本，他们的SDK专门针对（最初）3个SBC（单板计算机） - 树莓派 3，英特尔Edison和恩智浦Pico。说我一直在挣扎似乎有些轻描淡写 - 没有成功的移植树莓派安卓可以参照，我们在理想丰满，但是实践漏洞百出的内测版本上叫苦不迭。其中一个问题，同时也是不可原谅的问题是，它不支持触摸屏，甚至连[Element14][2]官方销售的也不支持。曾经我认为安卓已经支持树莓派，更早时候[commi tto AOSP project from Google][3]提到过Pi曾让所有人兴奋不已。所以当2016年12月12日谷歌发布"Android Things"和其SDK的时候，我马上闭门谢客，全身心地去研究了……
|
||||
|
||||
### 问题？
|
||||
安卓扩展的工作和Pi上做过的一些项目，包括之前提到的，当前正在开发中的Pi项目，使我对谷歌安卓产生了许多问题。未来我会尝试解决它们，但是最重要的问题可以马上解答 - 有完整的Android Studio支持，Pi成为列表上的另一个常规的ADB可寻址设备。好极了。Android Atudio强大的，便利的，纯粹的易用的功能包括布局预览，调试系统，源码检查器，自动化测试等可以真正的应用在IoT硬件上。这些好处怎么说都不过分。到目前为止，我在Pi上的大部分工作都是在python中使用SSH运行在Pi上的编辑器（MC，如果你真的想知道）。这是有效的，毫无疑问硬核Pi / Python头可以指出更好的工作方式，而不是当前这种像极了80年代码农的软件开发模式。我的项目涉及到在控制Pi的手机上编写Android软件，这有点像在伤口狂妄地撒盐 - 我使用Android Studio做“真正的”Android工作，用SSH做剩下的。但是有了"Android Things"之后，一切都结束了。
|
||||
|
||||
所有的示例代码都适用于3个SBC，Pi 只是其中之一。 Build.DEVICE常量在运行时确定，所以你会看到很多如下代码：
|
||||
|
||||
```
|
||||
public static String getGPIOForButton() {
|
||||
switch (Build.DEVICE) {
|
||||
case DEVICE_EDISON_ARDUINO:
|
||||
return "IO12";
|
||||
case DEVICE_EDISON:
|
||||
return "GP44";
|
||||
case DEVICE_RPI3:
|
||||
return "BCM21";
|
||||
case DEVICE_NXP:
|
||||
return "GPIO4_IO20";
|
||||
default:
|
||||
throw new IllegalStateException(“Unknown Build.DEVICE “ + Build.DEVICE);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
我对GPIO处理有浓厚的兴趣。 由于我只熟悉Pi，我只能假定其他SBC工作方式相同，GPIO只是一组引脚，可以定义为输入/输出，是连接物理外部世界的主要接口。 基于Pi Linux的操作系统发行版通过Python中的读取和写入方法提供了完整和便捷的支持，但对于Android，您必须使用NDK编写C ++驱动程序，并通过JNI在Java中与这些驱动程序对接。 不是那么困难，但需要在你的构建链中维护额外的一些东西。 Pi还为I2C指定了2个引脚，时钟和数据，因此需要额外的工作来处理它们。 I2C是真正酷的总线寻址系统，它通过串行化将许多独立的数据引脚转换成一个。 所以这里的优势是 - Android Things已经帮你完成了所有这一切。 你只需要_read（）_和_write（）_to /from你需要的任何GPIO引脚，I2C同样容易：
|
||||
|
||||
```
|
||||
public class HomeActivity extends Activity {
|
||||
// I2C Device Name
|
||||
private static final String I2C_DEVICE_NAME = ...;
|
||||
// I2C Slave Address
|
||||
private static final int I2C_ADDRESS = ...;
|
||||
|
||||
private I2cDevice mDevice;
|
||||
|
||||
@Override
|
||||
protected void onCreate(Bundle savedInstanceState) {
|
||||
super.onCreate(savedInstanceState);
|
||||
// Attempt to access the I2C device
|
||||
try {
|
||||
PeripheralManagerService manager = new PeripheralManagerService();
|
||||
mDevice = manager.openI2cDevice(I2C_DEVICE_NAME, I2C_ADDRESS)
|
||||
} catch (IOException e) {
|
||||
Log.w(TAG, "Unable to access I2C device", e);
|
||||
}
|
||||
}
|
||||
|
||||
@Override
|
||||
protected void onDestroy() {
|
||||
super.onDestroy();
|
||||
|
||||
if (mDevice != null) {
|
||||
try {
|
||||
mDevice.close();
|
||||
mDevice = null;
|
||||
} catch (IOException e) {
|
||||
Log.w(TAG, "Unable to close I2C device", e);
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
### Android Things基于Android的哪个版本？
|
||||
看起来是Android 7.0，这样很好，因为我们可以继承Android以前的所有版本的文档，优化，安全加固等。它也提出了一个有趣的问题 - 与应用程序必须单独管理不同，未来的平台应如何更新升级？请记住，这些设备可能无法连接到互联网。我们可能不在蜂窝/ WiFi连接的舒适空间，虽然之前这些连接至少可用，即使有时不那么可靠。
|
||||
|
||||
另一个担心是，Android Things仅仅是一个名字不同的分支版本的Android，如何选择它们的共同特性，就像启动Arduino（已经发布的一个更像市场营销而不是操作系统的操作系统）这种简单特性。实际上，通过查看[samples] [4]，一些功能可能永不再用 - 比如一个最近的Android创新，甚至使用SVG图形作为资源，而不是传统的基于位图的图形，当然Andorid Things也可以轻松处理。
|
||||
|
||||
不可避免地，与Android Things相比，普通的Android会抛出问题。例如，权限问题。因为Android Things为固定硬件设计，用户通常不会在这种设备上安装App，所以在一定程序上减轻了这个问题。另外，在没有图形界面的设备上请求权限通常不是问题，我们可以在安装时开放所有权限给App。 通常，这些设备只有一个应用程序，该应用程序从设备上电的那一刻就开始运行。
|
||||
|
||||
|
||||
|
||||
### Brillo怎么了？
|
||||
|
||||
Brillo是谷歌以前的IoT操作系统的代号，听起来很像Android的前身。 实际上现在你仍然能看到很多Brillo引用，特别是在GitHub Android Things源码的例子中。 然而，它已经不复存在了。新王已经登基！
|
||||
|
||||
### UI指南？
|
||||
Google针对Android智能手机和平板电脑应用发布了大量指南，例如屏幕按钮间距等。 当然，你最好在可行的情况下遵循这些，但这已经不是本文应该考虑的范畴了。 缺省情况下什么也没有- 应用程序作者决定一切。 这包括顶部状态栏，底部导航栏 - 绝对一切。 多年来谷歌一直叮咛Android应用程序作者不要去渲染屏幕上的返回按钮，因为平台将提供一个抛出异常，因为对于Android Things，[可能甚至不是一个UI！] [5]
|
||||
|
||||
### 多少智能手机上的服务可以期待？
|
||||
有些，但不是所有。第一个预览版本没有蓝牙支持。没有NFC，两者都对物联网革命有重大贡献。 SBC支持他们，所以我们应该不会等待太久。由于没有通知栏，因此不支持任何通知。没有地图。缺省没有软键盘，你必须自己安装一个。由于没有Play商店，你只能屈尊通过 ADB做这个和许多其他操作。
|
||||
|
||||
当开发Android Things时我试图和Pi使用同一个APK。这引发了一个错误，阻止它安装在除Android Things设备之外的任何设备：库“_com.google.android.things_”不存在。 Kinda有意义，因为只有Android Things设备需要这个，但它似乎是有限的，因为不仅智能手机或平板电脑不会出现，任何模拟器也不会。似乎只能在物理Android Things设备上运行和测试您的Android Things应用程序...直到Google在[G + Google的IoT开发人员社区] [6]组中回答了我的问题，并提供了规避方案。但是，躲过初一，躲不过十五 。
|
||||
|
||||
### 让我如何期待Android Thing生态演进？
|
||||
|
||||
我期望看到移植更多传统的基于Linux服务器的应用程序，这对Android只有智能手机和平板电脑没有意义。例如，Web服务器突然变得非常有用。一些已经存在，但没有像重量级的Apache，或Nginx。物联网设备可能没有本地UI，但通过浏览器管理它们当然是可行的，因此需要用这种方式呈现Web面板。类似的那些如雷贯耳的通讯应用程序 - 它需要的仅是一个麦克风和扬声器，在理论上对任何视频通话应用程序，如Duo，Skype，FB等都可行。这个演变能走多远目前只能猜测。会有Play商店吗？他们会展示广告吗？我们可以确定他们不会窥探我们，或让黑客控制他们？从消费者的角度来看，物联网应该是具有触摸屏的网络连接设备，因为每个人都已经习惯于通过智能手机工作。
|
||||
|
||||
我还期望看到硬件的迅速发展 - 特别是更多的SBC并且拥有更低的成本。看看惊人的5美元 树莓派0，不幸的是，由于其有限的CPU和RAM，几乎肯定不能运行Android Things。多久之后像这样的设备才能运行Android Things？这是很明显的，标杆已经设定，任何自重的SBC制造商将瞄准Android Things的兼容性，规模经济也将波及到外围设备，如23美元的触摸屏。没人购买不会播放YouTube的微波炉，你的洗碗机会在eBay上购买更多的粉末商品，因为它注意到你很少使用它……
|
||||
|
||||
然而，我不认为我们会失去掌控力。了解一点Android架构有助于将其视为一个包罗万象的物联网操作系统。它仍然使用Java，并几乎被其所有的垃圾回收机制导致的时序问题锤击致死。这仅仅是问题最少的部分。真正的实时操作系统依赖于可预测，准确和坚如磐石的时序，或者它不能被描述为“mission critical”。想想医疗应用程序，安全监视器，工业控制器等。使用Android，如果主机操作系统认为它需要，理论上可以在任何时候杀死您的活动/服务。在手机上不是那么糟糕 - 用户可以重新启动应用程序，杀死其他应用程序，或重新启动手机。心脏监视器完全是另一码事。如果前台Activity / Service正在监视一个GPIO引脚，并且信号没有被准确地处理，我们已经失败了。必须要做一些相当根本的改变让Android来支持这一点，到目前为止还没有迹象表明它已经在计划之中了。
|
||||
|
||||
###这24小时
|
||||
所以，回到我的项目。 我认为我会接管我已经完成和尽力能为的工作，等待不可避免的路障，并向G+社区寻求帮助。 除了一些在非Android Things上如何运行程序 的问题之外 ，没有其他问题。 它运行得很好！ 这个项目也使用了一些奇怪的东西，自定义字体，高精定时器 - 所有这些都在Android Studio中完美地展现。对我而言，可以打满分 - 最后我可以开始给出实际原型，而不只是视频和截图。
|
||||
|
||||
### 蓝图
|
||||
今天的物联网操作系统环境看起来非常零碎。 显然没有市场领导者，尽管炒作之声沸反连天，物联网仍然在草创阶段。 谷歌Android物联网能否像它在移动端那样，现在Android在那里的主导地位非常接近90％？ 我相信果真如此，Android Things的推出正是重要的一步。
|
||||
|
||||
记住所有的关于开放和封闭软件的战争，它们主要发生在从不授权的苹果和一直担心免费还不够充分的谷歌之间？ 那个老梗又来了，因为让苹果推出一个免费的物联网操作系统的构想就像让他们免费赠送下一代iPhone一样遥不可及。
|
||||
|
||||
物联网操作系统游戏是开放的，大家机遇共享，不过这个时候，封闭派甚至不会公布它们的开发工具箱……
|
||||
|
||||
转到[Developer Preview] [7]网站，立即获取Android Things SDK的副本。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://medium.com/@carl.whalley/will-android-do-for-iot-what-it-did-for-mobile-c9ac79d06c#.hxva5aqi2
|
||||
|
||||
作者：[Carl Whalley][a]
|
||||
译者：[firstadream](https://github.com/firstadream)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://medium.com/@carl.whalley
|
||||
[1]:https://developer.android.com/things/index.html
|
||||
[2]:https://www.element14.com/community/docs/DOC-78156/l/raspberry-pi-7-touchscreen-display
|
||||
[3]:http://www.androidpolice.com/2016/05/24/google-is-preparing-to-add-the-raspberry-pi-3-to-aosp-it-will-apparently-become-an-officially-supported-device/
|
||||
[4]:https://github.com/androidthings/sample-simpleui/blob/master/app/src/main/res/drawable/pinout_board_vert.xml
|
||||
[5]:https://developer.android.com/things/sdk/index.html
|
||||
[6]:https://plus.google.com/+CarlWhalley/posts/4tF76pWEs1D
|
||||
[7]:https://developer.android.com/things/preview/index.html
|
||||
Loading…
Reference in New Issue
Block a user