BAB II
LANDASAN TEORI
a) Protokol Upnp
UPnP merupakan protokol yang muncul setelah dikembangkannya protokol PnP (Plug and
Play). UpnP mengembangkan fitur dasar yang terdapat pada PnP sehingga memungkinkan untuk
pencarian dan kontrol perangkat keras yang ada pada jaringan lokal kita, termasuk juga service seperti
printer yang terkoneksi dengan jaringan, Internet gateway dan barang elektronik lainnya.
UPnP memungkinnan perangkat keras untuk bergabung dengan jaringan, mendapatkan alamat
IP, mengabarkan kemampuan perangkat tersebut, dan memberikan presensi dan kemampuan dari
perangkat lain. Tiap perangkat keras dapat berkomunikasi dengan perangkat lain secara langsung
sehingga memungkinkan adanya jaringan peer to peer.
Implementasi dari protokol UpnP memungkinkan terwujudnya banyak skenario, seperti rumah
otomatis yang memungkian penggunanya untuk melakukan printing, audio/video playing, mengerjakan
pekerjaan dapur tanpa harus berpindah tempat.
UpnP menggunakan TCP/IP dan standar Internet protocol, sehingga memungkinkan integrasi
dengan jaringan yang telah ada. Penggunaan protokol standar ini memungkinkan UpnP untuk
digunakan pada banyak perangkat.
Karena UpnP merupakan protokol yang terdistribusi, menggunakan arsitektur jaringan terbuka,
ia independen dari sistem operasi tertentu atau media tertentu. UpnP tidak menyebutkan API yang
digunakan, sehingga memungkinkan pengembang untuk membuat API yang sesuai dengan kebutuhan
mereka sendiri.
// With the addition of Device Plug and Play (PnP) capabilities to the operating system it became a
great deal easier to setup, configure, and add peripherals to a PC. Universal Plug and Play (UPnP)
extends this simplicity to include the entire network, enabling discovery and control of devices,
including networked devices and services, such as network-attached printers, Internet gateways, and
consumer electronics equipment.
UPnP is more than just a simple extension of the Plug and Play peripheral model. It is designed to
support zero-configuration, "invisible" networking, and automatic discovery for a breadth of device
categories from a wide range of vendors.
With UPnP, a device can dynamically join a network, obtain an IP address, convey its capabilities, and
learn about the presence and capabilities of other devices—all automatically; truly enabling zero
configuration networks. Devices can subsequently communicate with each other directly; thereby
further enabling peer to peer networking.
The varieties of device types that can benefit from a UPnP enabled network are large and include
intelligent appliances, wireless devices, and PCs of all form factors.
The scope of UPnP is large enough to encompass many existing, as well as new and exciting scenarios
including home automation, printing and imaging, audio/video entertainment, kitchen appliances,
automobile networks, and proximity networks in public venues.
UPnP uses standard TCP/IP and Internet protocols, enabling it to seamlessly fit into existing networks.
Using these standardized protocols allows UPnP to benefit from a wealth of experience and knowledge,
and makes interoperability an inherent feature.
Because UPnP is a distributed, open network architecture, defined by the protocols used, it is
independent of any particular operating system, programming language, or physical medium (just like
the Internet). UPnP does not specify the APIs applications will use, allowing operating system vendors
to create the APIs that will meet their customer needs. //
Protokol Spesifik UpnP
TCP/IP
Protokol TCP/IP merupakan pondasi dari UpnP. Dengan menggunakan protokol TCP/IP standar, makan
UpnP dapat digunakan pada media fisik yang berbeda beda dan memastikan interoperabilitas pada
vendor yang berbeda beda.
Perangkat yang mendukung UpnP dapat menggunakan ?sebagian besar? protokol yang terdapat pada
TCP/IP termasuk TCP, UDP, IGMP, ARP dan IP serta servis TCP/IP seperti DHCP dan DNS. Karena
TCP/IP merupakan salah satu protokol jaringan yang ubiquitos, maka pembuatan implementasi atau
deteksi perangkat UpnP cukup mudah.
HTTP, HTTPU, HTTPMU
TCP/IP menyediakan pondasi untuk membangun jaringan antar perangkat UPnP. HTTP juga
merupakan inti utama dari UpnP. Seluruh aspek dari UpnP dibangun di atas HTTP atau variasinya.
HTTPU dan HTTPMU merupakan varian dari HTTP yang mempunyai fungsi untuk mengirimkan
pesan dan dibuat di atas UDP/IP. Protokol tersebut akan digunakan oleh SSDP. Format dari pesan yang
digunakan oleh protokol – protokol di atas sesuai dengan HTTP dan HTTP juga dibutuhkan saat
komunikasi multicast dan saat pengiriman pesan tidak membutuhkan overhead.
SSDP
SSD merupakan akronim dari Simple Service Discovery Protocol. Sesuai dengan namanya, protokol ini
mendefinisikan bagaimana cara pencarian sebuah perangkat yang terkoneksi pada jaringan. SSD
dibangun di atas HTTPU dan HTTPMU dan mengatur cara dari control point untuk mencari lokasi dan
properti dari perangkat yang tersedia pada jaringan. Dengan mendefinisikan metode pencarian dan
pengumuman ketersediaan pernagkat, SSDP menghilangkan overhead yang ada ketika hanya salah satu
mekanisme di atas yang diimplementasikan. Konsekuensinya, setiap control point pada jaringan
memiliki informasi lengkap mengenai kondisi jaringan namun traffic jaringan tetap terjaga.
Control points dan perangkat keras menggunakan SSDP. Sebuah UpnP control point, ketika mulai
menyala dapat mengirimkan perintah pencarian SSDP melalui HTTPMU untuk mencari perangkat dan
layanan yang tersedia pada jaringan. Control point dapat memodifikasi pencarian untuk mencari
perangkat dengan tipe tipe tertentu (misalkan VCR, atau TV) ataupun layanan tertentu (misalkan
perangkat yang dilengkapi dengan jam) atau bahkan perangkat dengan merk tertentu.
Perangkat UpnP memantau sinyal dari port multicast. Ketika sinyal pencarian didapatkan, perangkat
mengevaluasi kriteria pencarian untuk memasikan bahwa kriteria yang dimiliki cocok. Ketika
kecocokan ditemukan, unicast SSDP melalui HTTPU dikirimkan ke control point. Selain itu, ketika
sebuah perangkat bergabung dengan jaringan, ia akan mengirimkan sinyal kehadiran menggunakan
multiple SSDP untuk memberitahukan layanan yang dia dukung.
Sinya kehadiran dan respon unicast pesan dari perangkat mengandung petunjuk untuk lokasi dari
perangkat, dan mempunyai informasi mengenai ciri ciri dan layanan yang didukung oleh perangkat tsb
SSDP juga menyediakan cara agar perangkat dan layanannya untuk meninggalkan jaringan dengan
memberikan notifikasi dan timeout untuk deteksi keberadaan perangkat.
GENA
GENA (Generic Event Notification Architecture) menyediakan layanan untuk mengirimkan atau
menerima notifikasi menggunakan HTTP melalui TCP/IP dan multicast UDP. GENA juga mempunyai
konsep subscriber-publisher untuk notifikasi agar memungkinkan adanya events-based activities.
UpnP menggunakan GENA agar sinyal kehadiran dapat dikirimkan melalui SSDP dan memungkinkan
adanya perubahan sinyal saat ada event UpnP. Sebuah control point dapat menerima notifikasi layanan
saat dia berlangganan pada sebuah sumber notifikasi. Permintaan berlangganan dilakukan dengan
mengirimkan permintaan berlangganan yang berisi lokasi tujuan notifikasi, waktu berlanggaan dan
layanan yang diinginkan yang sesuai dengan notifikasi. Permintaan berlangganan harus dikirimkan
berkala agar informasi yang didapatkan selalu valid dan notifikasi bisa dikirimkan atau dibatalkan
menggunakan GENA.
SOAP
SOAP (Simple Object Access Protocol) menggunakan XML (Extensible Markup Language) dan HTTP
untuk menjalankan perintah prosedural secara remote. SOAP menjadi standar untuk komunikasi
berbasis RCP di Internet. Dengan menggunakan infrastruktur Internet yang telah tersedia, SOAP dapat
bekerja secara efektif dengan firewalls dan proxies. SOAP juga dapat dikombinasikan dengan SSL
(Secure Sockets Layer) untuk keamanan dan menggunakan fasilitas manajemen koneksi yang dimiliki
HTTP sehingga memungkinkan persebaran komunikasi di Internet semudah mengakses halaman web.
UpnP menggunakan SOAP untuk mengirimkan pesan kontrol kepada perangkat dan menerima sinyal
berhasil atau sukses ke control points.
Setiap permintaan kontrol dari UpnP merupakan pesan SOAP yang menganduk aksi yang akan
dijalankan sesuai dengan parameter yang ada. Respon yang diterima juga merupakan pesan SOAP yang
berisi status, nilai kembalian dan parameter kembalian.
XML
XML (Extensible Markup Language) adalah format universal untuk data terstruktur di Web. XML
memiliki kemiripan dengan HTML dalam penggunaan tag dan attribute. Perbedaan utamanya adalah
tag dan attribute dari XML tidak didefinisikan secara global, tapi diartikan sesuai dengan konteks dan
konten yang dikandungnya. Konsep ini membuat XML menjadi format yang bagus untuk
pengembangan skema untuk berbagai macam dokumen. UpnP menggunakan XML dalam pembuatan
deskripsi perangkat, layanan, pesan kontrol dan eventing.
UPnP Specific Protocols
TCP/IP
The TCP/IP networking protocol stack serves as the base on which the rest of the UPnP protocols are
built. By using the standard, prevalent TCP/IP protocol suite, UPnP leverages the protocol’s ability to
span different physical media and ensures multiple vendor interoperability.
UPnP devices can use many of the protocols in the TCP/IP stack including TCP, UDP, IGMP, ARP and
IP as well as TCP/IP services such as DHCP and DNS. How these protocols and services are used to
provide what is required for UPnP to work will become clear as we discuss the other protocols in this
section and discuss how UPnP works in subsequent sections.
Since TCP/IP is one of the most ubiquitous networking protocols, locating or creating an
implementation for a UPnP device that is tuned for footprint and/or performance is relatively easy.
A basic understanding of the TCP/IP protocol suite and services is assumed in this document. More
information on TCP/IP can be found in the references listed at the end of this document.
HTTP, HTTPU, HTTPMU
TCP/IP provides the base protocol stack to provide network connectivity between UPnP devices.
HTTP, which is hugely responsible for the success of the Internet, is also a core part of UPnP. All
aspects of UPnP build on top of HTTP or its variants.
HTTPU (and HTTPMU) are variants of HTTP defined to deliver messages on top of UDP/IP instead of
TCP/IP. These protocols are used by SSDP, described next. The basic message formats used by these
protocols adheres with that of HTTP and is required both for multicast communication and when
message delivery does not require the overhead associated with reliability.
Some of the explanations of higher-level protocols and the workings of UPnP assume a basic
knowledge of the HTTP protocol. More information on HTTP can be found through the references
listed at the end of this document.
SSDP
Simple Service Discovery Protocol (SSDP), as the name implies, defines how network services can be
discovered on the network. SSDP is built on HTTPU and HTTPMU and defines methods both for a
control point to locate resources of interest on the network, and for devices to announce their
availability on the network. By defining the use of both search requests and presence announcements,
SSDP eliminates the overhead that would be necessary if only one of these mechanisms is used. As a
result, every control point on the network has complete information on network state while keeping
network traffic low.
Both control points and devices use SSDP. A UPnP control point, upon booting up, can send an SSDP
search request (over HTTPMU), to discover devices and services that are available on the network. The
control point can refine the search to find only devices of a particular type(such as a VCR), particular
services (such as devices with clock services) or even a particular device.
UPnP devices listen to the multicast port. Upon receiving a search request, the device examines the
search criteria to determine if they match. If a match is found, a unicast SSDP (over HTTPU) response
is sent to the control point.
Similarly, a device, upon being plugged into the network, will send out multiple SSDP presence
announcements advertising the services it supports.
Both presence announcements and unicast device response messages contain a pointer to the location
of the device description document, which has information on the set of properties and services
supported by the device.
In addition to the discovery capabilities provided, SSDP also provides a way for a device and
associated service(s) to gracefully leave the network (bye-bye notification) and includes cache timeouts
to purge stale information for self healing.
GENA
Generic Event Notification Architecture (GENA) was defined to provide the ability to send and receive
notifications using HTTP over TCP/IP and multicast UDP. GENA also defines the concepts of
subscribers and publishers of notifications to enable events.
GENA formats are used in UPnP to create the presence announcements to be sent using Simple Service
Discovery Protocol (SSDP) and to provide the ability to signal changes in service state for UPnP
eventing. A control point interested in receiving event notifications will subscribe to an event source by
sending a request that includes the service of interest, a location to send the events to and a subscription
time for the event notification.
The subscription must be renewed periodically to continue to receive notifications, and can also be
canceled using GENA.
SOAP
Simple Object Access Protocol (SOAP) defines the use of Extensible Markup Language (XML) and
HTTP to execute remote procedure calls. It is becoming the standard for RPC based communication
over the Internet. By making use of the Internet’s existing infrastructure, it can work effectively with
firewalls and proxies. SOAP can also make use of Secure Sockets Layer (SSL) for security and use
HTTP’s connection management facilities, thereby making distributed communication over the Internet
as easy as accessing web pages.
Much like a remote procedure call, UPnP uses SOAP to deliver control messages to devices and return
results or errors back to control points.
Each UPnP control request is a SOAP message that contains the action to invoke along with a set of
parameters. The response is a soap message as well and contains the status, return value and any return
parameters.
XML
Extensible Markup Language (XML), to use the W3C definition, is the universal format for structured
data on the Web. Put another way, XML is a way to place nearly any kind of structured data into a text
file.
XML looks a lot like HTML in that it uses tags and attributes. Actually, it is quite different in that these
tags and attributes are not globally defined as to their meaning, but are interpreted within the context of
their use. These features of XML make it a good fit for developing schemas for various document
types. The use of XML as a schema language is defined by the W3C.
XML is a core part of UPnP used in device and service descriptions, control messages and eventing.
Langkah – Langkah yang diperlukan dalam UPnP
Pengalamatan
Dasar/fondasi dari jaringan UPnP adalah TCP/IP protokol. TCP/IP mempunyai elemen utama
addressing. Setiap perangkat harus mempunyai klien DHCP (Dynamic Host Configuration Protocol)
dan mencari server DHCP setiap terkoneksi ke jaringan. Jika ada server DHCP yang tersedia, perangkat
harus menggunakan alamat IP yang didapatkan dari server. Jika tidak ada DHCP server, maka
perangkat harus menggunakan auto IP untuk mendapatkan alamat IPnya.
Secara singkat, auto IP mendefinisikan bagaimana cara sebuah perangkat mendapatkan alamat IP dari
kumpulan alamat yang telah disiapkan sebelumnya dan dapat berpindah dengan mudah dari jaringan
terstruktur ke jaringan tidak terstuktur. Sebuah perangkat mungkin mengimplementasikan protokol
selain UPnP yang menggunakan nama panggilan untuk perangkat tsb. Dalam kasus ini, harus dilakukan
perubahan nama panggilan perangkat menjadi alamat IP perangkat tersebut. DNS (Domain Name
Services biasanya digunakan pada kasus seperti ini. Perangkat yang membutuhkan fungsi pemetaan
dari nama panggilan ke alamat IP biasanya menyediakan klien DNS dan mendukung registrasi DNS
dinamis untuk pemetaan alamat.
Pencarian/Penemuan ?/
Ketika perangkat telah tergabung ke dalam jaringan dan mendapatkan alamat yang sesuai, maka
penemuan perangkat menjadi memungkinkan. Penemuan diatur oleh SSDP seperti yang dibahas
sebelumnya. Ketika perangkat ditambahkan ke dalam jaringan, SSDP memungkinkan perangkat tsb
untuk memberitahukan layanan yang didukungnya kepada control points jaringan, Ketika sebuah
control point ditambahkan ke dalam jaringan, SSDP memungkinkan control point tersebut untuk
mencari perangkat dengan kriteria yang diinginkan dalam jaringan. Pertukaran informasi yang paling
fundamental adalah dengan pengiriman pesan penemuan yang berisi spesifikasi inti mengenai
perangkat atau layanan yang didukungnya
Dekripsi
Langkah selanjutnya dalam pembuatan jaringan UPnP adalah deskripsi. Setelah control poin
menemukan sebuah perangkat, control point tersebut belum mengetahui detail informasi dari perangkat
yang ada. Control point harus mendapatkan informasi lebih detail mengenai perangkat dan layanan
yang didiukungnya agar bisa berinteraksi secara lebih efektif. Untuk mendapatkan informasi ini,
Control point harus mendapatkan deskripsi perangkat melalui URL yang disediakan oleh perangkat di
pesan penemuan. Perangkat mungkin mempunyai perangkat dan layanan logika. Deskripsi UPnP untuk
sebuah perangkat tersimpan dalam sebuah berkas XML dan termasuk juga di dalamnya informasi
spesifik dari vendor dan pembuat perangkat meliputi nama, nomor, nomor serial, alamat URL vendor,
dan lain lain. Deskripsi juga berisi kumpulan perangkat dan layanan lain yang tertanam di dalam
perangkat tersebut. Selain itu terdapat juga URL untuk kontrol, eventing dan presentasi perangkat.
Kontrol
Setelah Control point mendapatkan deskripsi perangkat, maka control point tersebut mempunyai
kemampuan untuk melakukan kontrol terhadap perangkat. Untuk mengetahui datail layanan yang
ditawarkan perangkat, control point harus mendapatkan deskripsi UPnP layanan secara mendetail.
Deskripsi dari layanan juga dinyatakan dalam berkas XML dan berisi daftar perintah atau aksi berserta
parameternya yang bisa diterima dan dijalankan oleh layanan. Deksripsi tersebut juga berisi daftar
variabel yang digunakan oleh layanan beserta deksripsi data, kapasitas dan karakteristik variabel.
Untuk mengontrol perangkat, control point mengirimkan permintaan aksi kepada sebuah layanan dari
perangkat. Untuk melakukan hal ini, control point mrngirimkan permintaan aksi ke URL kontrol dari
layanan (yang tersedia di deskripsi perangkat). Pesan kontrol dinyatakan dalam berkas XML
menggunakan SOAP. Layanan kemudian akan merespon pesan tersebut dengan mengirimkan kode
sukses atau gagal.
Eventing
Deskripsi UPnP untuk layanan salah satunya berisi daftar aksi yang didukung oleh layanan dan variabel
yang dibutuhkan layanan saat berjalan. Layanan akan mengirimkan update ketika terjadi perubahan
variabel dan control point dapat berlangganan untuk menerima informasi tersebut.
Layanan mengirimkan update melalui pesan event. Pesan event mengandung nama dan kondisi dari
variabel. Pesan ini dinyatakan dalam berkas XML dan diformat menggunakan GENA.
Ketika control point berlangganan untuk pertama kali, pesan even spesial dikirimkan. Pesan spesial ini
berisi nama dan nilai dari seluruh variabel event dan memungkinkan pelanggan untuk menginisialisasi
model dan kondisi layanan.
Untuk mendukung multiple control points, setiap pelanggan harus mengirimkan semua pesan event,
pelanggan menerima semua pesan event untuk semua variabel event dan setiap pesan even harus
dikirim tanpa memperdulikan penyebab perubahan variabel.
Presentasi
Apabila sebuah perangkat memiliki URL untuk presentasi, maka control point dapat mengambil
halaman dari URL tersebut kemudian mengirimkan halaman tersebut ke browser dan memungkinkan
pengguna untuk mengontrol perangkat atau melihat status perangkat. Tingkat kontrol tergantung dari
kemampuan halaman presentasi dan perangkat
Steps Involved in UPnP Networking
Addressing
The foundation for UPnP networking is the TCP/IP protocol suite and the key to this suite is
addressing. Each device must have a Dynamic Host Configuration Protocol (DHCP) client and search
for a DHCP server when the device is first connected to the network. If a DHCP server is available, the
device must use the IP address assigned to it. If no DHCP server is available, the device must use Auto
IP to get an address.
In brief, Auto IP defines how a device intelligently chooses an IP address from a set of reserved private
addresses, and is able to move easily between managed and unmanaged networks.
A device may implement higher layer protocols outside of UPnP that use friendly names for devices. In
these cases, it becomes necessary to resolve friendly host (device) names to IP address. Domain Name
Services (DNS) are usually used for this. A device that requires or uses this functionality may include a
DNS client and may support dynamic DNS registration for its own name to address mapping.
Discovery
Once devices are attached to the network and addressed appropriately, discovery can take place.
Discovery is handled by the SSDP as discussed earlier. When a device is added to the network, SSDP
allows that device to advertise its services to control points on the network. When a control point is
added to the network, SSDP allows that control point to search for devices of interest on the network.
The fundamental exchange in both cases is a discovery message containing a few, essential specifics
about the device or one of its services, for example its type, identifier, and a pointer to its XML device
description document.
Description
The next step in UPnP networking is description. After a control point has discovered a device, the
control point still knows very little about the device. For the control point to learn more about the
device and its capabilities, or to interact with the device, the control point must retrieve the device's
description from the URL provided by the device in the discovery message.
Devices may contain other, logical devices and services. The UPnP description for a device is
expressed in XML and includes vendor-specific, manufacturer information including the model name
and number, serial number, manufacturer name, URLs to vendor-specific Web sites, and so forth. The
description also includes a list of any embedded devices or services, as well as URLs for control,
eventing, and presentation.
Control
After a control point has retrieved a description of the device, the control point has the essentials for
device control. To learn more about the service, a control point must retrieve a detailed UPnP
description for each service. The description for a service is also expressed in XML and includes a list
of the commands, or actions, the service responds to, and parameters or arguments, for each action. The
description for a service also includes a list of variables; these variables model the state of the service at
run time, and are described in terms of their data type, range, and event characteristics.
To control a device, a control point sends an action request to a device's service. To do this, a control
point sends a suitable control message to the control URL for the service (provided in the device
description). Control messages are also expressed in XML using SOAP.
In response to the control message, the service returns action specific values or fault codes.
Eventing
A UPnP description for a service includes a list of actions the service responds to and a list of variables
that model the state of the service at run time. The service publishes updates when these variables
change, and a control point may subscribe to receive this information.
The service publishes updates by sending event messages. Event messages contain the names of one of
more state variables and the current value of those variables. These messages are also expressed in
XML and formatted using GENA.
A special initial event message is sent when a control point first subscribes; this event message contains
the names and values for all evented variables and allows the subscriber to initialize its model of the
state of the service.
To support multiple control points, all subscribers are sent all event messages, subscribers receive event
messages for all evented variables, and event messages are sent no matter why the state variable
changed (in response to an action request or due to a state change).
Presentation
If a device has a URL for presentation, then the control point can retrieve a page from this URL, load
the page into a browser, and depending on the capabilities of the page, allow a user to control the
device and/or view device status. The degree to which each of these can be accomplished depends on
the specific capabilities of the presentation page and device.
[microsoft's white paper about upnp protocol]
b) Sistem Operasi Android
Android
Android adalah sebuah perangkat lunak untuk perangkat mobile yang berisi sistem operasi, aplikasi
utama dan beberapa aplikasi pendukung. Android dikembangkan berdasarkan kernel Linux 2.6 yang
mempunyai fungsi inti seperti keamanan, manajemen memori, manajemen proses, jaringan dll. Kernel
tersebut juga berfungsi sebagai layer abstrak di antara perangkat keras dan perangkat lunak.
Komponen utama dari Android adalah sebagai berikut :
Aplikasi
Android berisi aplikasi utama termasuk email klien, program SMS, kalender, peta, peramban, kontak
dan lain lain. Seluruh aplikasi utama ditulis menggunakan bahasa pemrograman Java.
Kerangka Aplikasi
Dengan penyediaan platform terbuka, Android menawarkan pengembang kemampuan untuk
membangun aplikasi yang inovatif. Pengembang dapat mengakses kemampuan perangkat keras, lokasi,
layanan di balik layar, alarm, notifikasi dan hal hal lainnya. Pengembang mempunyai API yang sama
dengan API yang digunakan oleh aplikasi inti.
Di dalam setiap aplikasi terdapat kumpulan layanan dan sistem yang meliputi :
View = bagian dari aplikasi yang berfungsi sebagai tampilan yang meliputi grid, list, text box, dan
peramban web.
Penyedia Konten (Content Providers) = memungkinkan aplikasi untuk mengakses data dari aplikasi
lain atau membagi data dari dalam aplikasi tsb
Manajer Berkas (Resource Manager) = memberikan akses kepada berkas di luar kode program seperti
grafik, berkas tampilan, dll.
Manajer Notifikasi = memungkinkan aplikasi untuk menampilkan peringatan atau poesan khusus di
status bar.
Manajer aktivitas = memanajemen siklus aplikasi dan memungkinkan backstack navigasi
Libraries
Android mempunyai kumpulan C/C++ libraries yang digunakan dalam berbagai komponen sistem.
Beberapa library yang digunakan adalah sebagai berikut
System C library – sebuah implementasi yang diturunkan dari BSD berrisi standar system C library
untuk Linux yang biasa digunakan dalam perangkat embedded.
Media Libraries – berdasarkan OpenCORE dari PacketVideo, library ini mendukung rekaman dan bisa
memainkan audio, video dan image format yang umum beredar meliputi MPED4, H.264, MP3, AAC,
AMR, JPG dan PNG
Manajer Layar – memanajemen akses untuk menampilkan subsistem dan 2D / 3D layer gambar dari
banyak aplikasi yang berbeda
LibWebCore – Peramban web yang diguanakan secara default oleh Android
SGL – mesin grafik 2D
3D libraries – implementasi berdasarkan OpenGL
FreeType – Lirary yang digunakan untuk menampilkan bitmap dan vector font
SQLite – Database yang bisa diakses oleh banyak aplikasi.
Android Runtime
Setiap aplikasi android berjalan di prosesnya masing masing dengan setiap instance dari Dalvik virtual
machine. Dalvik telah dibuat sedemikian rupa sehingga dapat menjalankan banyak Virtual Machine
secara efisien. Dalvik VM tergantung pada kernel linux, terutama pada low level memory manajemen
dan threading.
android overview
Android relies on Linux version 2.6 for core system services such as security, memory management,
process management, network stack, and driver model. The kernel also acts as an abstraction layer
between the hardware and the rest of the software stack.
What is Android?
Android is a software stack for mobile devices that includes an operating system, middleware and key
applications. The Android SDK provides the tools and APIs necessary to begin developing applications
on the Android platform using the Java programming language.
Features
Application framework enabling reuse and replacement of components
Dalvik virtual machine optimized for mobile devices
Integrated browser based on the open source WebKit engine
Optimized graphics powered by a custom 2D graphics library; 3D graphics based on the OpenGL ES
1.0 specification (hardware acceleration optional)
SQLite for structured data storage
Media support for common audio, video, and still image formats (MPEG4, H.264, MP3, AAC, AMR,
JPG, PNG, GIF)
GSM Telephony (hardware dependent)
Bluetooth, EDGE, 3G, and WiFi (hardware dependent)
Camera, GPS, compass, and accelerometer (hardware dependent)
Rich development environment including a device emulator, tools for debugging, memory and
performance profiling, and a plugin for the Eclipse IDE
Android Architecture
The following diagram shows the major components of the Android operating system. Each section is
described in more detail below.
Applications
Android will ship with a set of core applications including an email client, SMS program, calendar,
maps, browser, contacts, and others. All applications are written using the Java programming language.
Application Framework
By providing an open development platform, Android offers developers the ability to build extremely
rich and innovative applications. Developers are free to take advantage of the device hardware, access
location information, run background services, set alarms, add notifications to the status bar, and much,
much more.
Developers have full access to the same framework APIs used by the core applications. The application
architecture is designed to simplify the reuse of components; any application can publish its capabilities
and any other application may then make use of those capabilities (subject to security constraints
enforced by the framework). This same mechanism allows components to be replaced by the user.
Underlying all applications is a set of services and systems, including:
A rich and extensible set of Views that can be used to build an application, including lists, grids, text
boxes, buttons, and even an embeddable web browser
Content Providers that enable applications to access data from other applications (such as Contacts), or
to share their own data
A Resource Manager, providing access to non-code resources such as localized strings, graphics, and
layout files
A Notification Manager that enables all applications to display custom alerts in the status bar
An Activity Manager that manages the lifecycle of applications and provides a common navigation
backstack
For more details and a walkthrough of an application, see the Notepad Tutorial.
Libraries
Android includes a set of C/C++ libraries used by various components of the Android system. These
capabilities are exposed to developers through the Android application framework. Some of the core
libraries are listed below:
System C library - a BSD-derived implementation of the standard C system library (libc), tuned for
embedded Linux-based devices
Media Libraries - based on PacketVideo's OpenCORE; the libraries support playback and recording of
many popular audio and video formats, as well as static image files, including MPEG4, H.264, MP3,
AAC, AMR, JPG, and PNG
Surface Manager - manages access to the display subsystem and seamlessly composites 2D and 3D
graphic layers from multiple applications
LibWebCore - a modern web browser engine which powers both the Android browser and an
embeddable web view
SGL - the underlying 2D graphics engine
3D libraries - an implementation based on OpenGL ES 1.0 APIs; the libraries use either hardware 3D
acceleration (where available) or the included, highly optimized 3D software rasterizer
FreeType - bitmap and vector font rendering
SQLite - a powerful and lightweight relational database engine available to all applications
Android Runtime
Every Android application runs in its own process, with its own instance of the Dalvik virtual machine.
Dalvik has been written so that a device can run multiple VMs efficiently. The Dalvik VM executes
files in the Dalvik Executable (.dex) format which is optimized for minimal memory footprint. The VM
is register-based, and runs classes compiled by a Java language compiler that have been transformed
into the .dex format by the included "dx" tool.
The Dalvik VM relies on the Linux kernel for underlying functionality such as threading and low-level
memory management.
Linux Kernel
Android relies on Linux version 2.6 for core system services such as security, memory management,
process management, network stack, and driver model. The kernel also acts as an abstraction layer
between the hardware and the rest of the software stack.
[ http://developer.android.com/guide/basics/what-is-android.html ]
[http://onlamp.com/pub/a/onlamp/2007/11/12/google-calling-inside-the-gphone-sdk.html ]
android technical aspect
[ http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/A-developers-perspective-onGoogles-Android-SDK/ ]
platform distribution & history
[http://developer.android.com/resources/dashboard/platform-versions.html ]
c) Streaming dan manipulasi video
Streaming merupakan sebuah cara menampilkan multimedia kepada pengguna dengan menggunakan
streaming provider. Dengan streaming, klien dapat menampilkan data sebelum keseluruhan berkas
diterima. Nama streaming menggambarkan metode pengiriman melalui medium, bukan
menggambarkan medium itu sendiri. Pembedanya biasanya ada pada media yang terdistribusi melalui
jaringan telekomunikasi, seperti kebanyakan sistem pengiriman yang menggunakan streaming ( radio,
televisi ) atau yang bersifat bukan streaming ( buku, kaset, audio CD ).
Pembuatan protokol jaringan untuk mendukung media streaming membutuhkan banyak perhatian, di
antaranya :
Protokol Datagram, seperti User Datagram Protocol, mengirimkan media stream sebagai kumpulan
paket paket kecil. Ini simpel dan efisiean, namun tidak ada mekanisme dalam protokol yang menjamin
pengiriman. Kesalahan data hanya bisa dideteksi oleh klien dan apabila memungkinkan dilakukan
koreksi kesalahan dengan cara meminta ulang data yang hilang.
RTSP (Real Time Streaming Protocol) , RTP (Real-time Transport Protocol) dan RTCP (Real-time
Transport Protocol) merupakan protokol spesial yang dibuat agar streaming menjadi mudah dilakukan
pada jaringan. RTSP bisa diterapkan pada banyak protokol, sementara yang lain hanya bisa berjalan
pada UDP.
Pendekatan lain yang juga menggunakan protokol web standar adalah HTTP adaptive bitrate streaming.
HTTP adaptive bitrate streaming siimplementasikan berdasarkan HTTP progressive download, namun
dilakukan dengan melakukan download pada berkas berukuran kecil, mirip RTSP dan RTP
Protokol yang lebih reliabel seperti TCP (Transmission Control Protocol) menjamin pengiriman berkas
dalam media streaming. Namun hal ini dicapai dengan menggunakan mekanisme kirim ulang dan
timeout shingga menyebabkan sistem menjadi lebih kompleks. Hal ini juga berakibat lambatnya media
streaming ketika data loss terjadi pada jaringan disebabkan pengecekan dan pengiriman ulang data.
Klien dapat meminimalisis efek ini dengan menyimpan data terlebih dahulu sebelum ditampilkan.
Waktu tunggu untuk melakukan buffering video biasanya tidak terlalu mengganggu apabila diterapkan
pada layanan video per- permintaan. Akan tetapi untuk video chat atau video conference, hal ini akan
mengganggu konsistensi streaming, terutama ketika waktu tunggu melebih 200ms.
Protokol unicast mengirim kopian terpisah dari media stream dari server kepada setiap penerima.
Unicast adalah norma untuk sebagian besar koneksi internet, tapi tidak akan mengubah skalanya ketika
banyak pengguna ingin melihat program televisi yang sama.
Multicasting menyiarkan kopi dari sebuah multimedia kepada seluruh klien pada jaringan. Protokol
multicast dikembangkan untuk mengurangi duplikasi data dan mengurangi beban yang diterima
jaringan yang muncul ketika banyak penerima mendapatkan konten streaming secara unicast dan
independen. Protokol ini mengirimkan stream individu dari banyak penerima. Kemungkinan
implementasi darit transmisi multicast tergantung dari infrastruktur dan tipe jaringan yang ada. Salah
satu kerugian dari multicast adalah tidak memungkinkannya implementasi video per-permintaan.
Streaming setara kontinyu biasanya tidak memungkinkan penerima untuk mengatur playback dari
media.. Namun, masalah ini bisa diatasi dengan penggunaan cache di service, set top box digital dan
media player yang bisa menyimpan data (buffer).
IP multicast menyediakan cara untuk mengirimkan media stream individu kepada kumpulan penerima
di sebuah jaringan komputer. Protokol multicast, biasanya Internet Group Management Protocol
digunakan untuk mengatur pengiriman stream multicast kepada grup penerima di LAN. Salah satu
tantangan dalam implementasi IP multicast adalah bahwa routers dan firewalls antar LAN harus
membolehkan packet yang dikirimkan sampai ke grup multicast. Jika organisasi yang
bertanggungjawab atas konten mempunyai kontrol terhadap jaringan antara server dan penerima, maka
protokol seperti Protocol Independent Multicast dappt digunakan untuk mengirimkan konten streaming
ke banyak LAN.
Protokol peer-to-peer mengatur pengiriman stream antar komputer. Hal ini dilakukan untuk mencegak
terjadinya bottlenect antara server dan koneksi jaringan. Namun ini memiliki berbagai hal yang harus
diperhatikan seperti aspek teknis, performa, kualitas dan bisnis.
Streaming media is multimedia that is constantly received by and presented to an end-user while being
delivered by a streaming provider. With streaming, the client browser or plug-in can start displaying the
data before the entire file has been transmitted.[note 1] The name refers to the delivery method of the
medium rather than to the medium itself. The distinction is usually applied to media that are distributed
over telecommunications networks, as most other delivery systems are either inherently streaming (e.g.,
radio, television) or inherently nonstreaming (e.g., books, video cassettes, audio CDs). The verb "to
stream" is also derived from this term, meaning to deliver media in this manner. Internet television is a
commonly streamed medium. Streaming media can be something else other than video and audio. Live
closed captioning and stock tickers are considered streaming text, as is Real-Time Text.
Live streaming, delivering live over the Internet, involves a camera for the media, an encoder to
digitize the content, a media publisher, and a content delivery network to distribute and deliver the
content.
Designing a network protocol to support streaming media raises many issues, such as:
Datagram protocols, such as the User Datagram Protocol (UDP), send the media stream as a series of
small packets. This is simple and efficient; however, there is no mechanism within the protocol to
guarantee delivery. It is up to the receiving application to detect loss or corruption and recover data
using error correction techniques. If data is lost, the stream may suffer a dropout.
The Real-time Streaming Protocol (RTSP), Real-time Transport Protocol (RTP) and the Real-time
Transport Control Protocol (RTCP) were specifically designed to stream media over networks. RTSP
runs over a variety of transport protocols, while the latter two are built on top of UDP.
Another approach that seems to incorporate both the advantages of using a standard web protocol and
the ability to be used for streaming even live content is the HTTP adaptive bitrate streaming. HTTP
adaptive bitrate streaming is based on HTTP progressive download, but contrary to the previous
approach, here the files are very small, so that they can be compared to the streaming of packets, much
like the case of using RTSP and RTP.[5]
Reliable protocols, such as the Transmission Control Protocol (TCP), guarantee correct delivery of
each bit in the media stream. However, they accomplish this with a system of timeouts and retries,
which makes them more complex to implement. It also means that when there is data loss on the
network, the media stream stalls while the protocol handlers detect the loss and retransmit the missing
data. Clients can minimize this effect by buffering data for display. While delay due to buffering is
acceptable in video on demand scenarios, users of interactive applications such as video conferencing
will experience a loss of fidelity if the delay that buffering contributes to exceeds 200 ms.[6]
Unicast protocols send a separate copy of the media stream from the server to each recipient. Unicast is
the norm for most Internet connections, but does not scale well when many users want to view the
same television program concurrently.
Multicasting broadcasts the same copy of the multimedia over the entire network to a group of clients
Multicast protocols were developed to reduce the data replication (and consequent server/network
loads) that occurs when many recipients receive unicast content streams independently. These protocols
send a single stream from the source to a group of recipients. Depending on the network infrastructure
and type, multicast transmission may or may not be feasible. One potential disadvantage of
multicasting is the loss of video on demand functionality. Continuous streaming of radio or television
material usually precludes the recipient's ability to control playback. However, this problem can be
mitigated by elements such as caching servers, digital set-top boxes, and buffered media players.
IP Multicast provides a means to send a single media stream to a group of recipients on a computer
network. A multicast protocol, usually Internet Group Management Protocol, is used to manage
delivery of multicast streams to the groups of recipients on a LAN. One of the challenges in deploying
IP multicast is that routers and firewalls between LANs must allow the passage of packets destined to
multicast groups. If the organization that is serving the content has control over the network between
server and recipients (i.e., educational, government, and corporate intranets), then routing protocols
such as Protocol Independent Multicast can be used to deliver stream content to multiple Local Area
Network segments.
Peer-to-peer (P2P) protocols arrange for prerecorded streams to be sent between computers. This
prevents the server and its network connections from becoming a bottleneck. However, it raises
technical, performance, quality, and business issues.
[ http://en.wikipedia.org/wiki/Streaming_media ]