# Is Malware Detection Needed for Android TV?
## 3 Methods
### Feature Extraction  
An Android application package is a compressed file containing the components of the application, including \"AndroidManifest.xml\" and \"classes.dex\" files. The \"AndroidManifest.xml\" file contains information about the name, version, access rights, referenced library files, and the used features and components of the application in XML format. The \"classes.dex\" file is the source code of the application compiled for the Dalvik virtual machine. Even though exposing the source code of the application is possible using reverse engineering, various obfuscation techniques are applied in some applications during compilation to prevent disclosure of the source code. In order to be resilient against obfuscation techniques, we extracted features from the DEX files at the bytecode level instead of applying reverse engineering to the source code in this study. On the other hand, we decoded the binary XML files and extracted the features from human-readable XML files. In order to extract the features, DEX and XML files are read at the byte level and divided into sequences of \(n\) bytes called n-grams. The n-grams are obtained by sliding an n-byte-long window by 1 byte from the beginning to the end of the file. In our study, we handled the n-grams in hexadecimal format without using a prefix (0x) or a space between bytes. As an example, every DEX file starts with the \"d\", \"e\", and \"x\" characters, which are 0 x 64, 0 x 65, and 0 x 78 in hexadecimal format, respectively. Therefore, the first 2-byte-long (2-gram) feature of the DEX files is \"6465\", and the second one is \"6578\". We extracted 2-gram features from the DEX files and 3-gram fractures from the XML files because of the fact that the file size of the source files is bigger than that of Android Manifest files. The number of n-grams is correlated with the number of bytes (\(n\)) of a feature and is in the range of \([0,2^{8*n}]\). Therefore, calculation using more features requires more space in terms of memory and takes a longer time. It is not efficient to use all of the n-grams as features, especially for long n-grams. In order to select the features, we adapted the Term Frequency--Inverse Document Frequency (TF-IDF) method, which is widely used to extract features from text documents. Similar to representing documents using the extracted features of the words in them, we represented binary files using the extracted features of the n-grams in them. We counted the occurrence of each n-gram for each file and calculated the frequencies of the n-grams for each file. Then, we calculated the weights (importance) of the n-grams using the TF-IDF method such that the n-grams received weights according to their occurrence in a file, but also n-grams that existed in the majority of the files received less weight since they were less informative. The TF-IDF value (\(tfidf\)) of an n-gram (\(t\)) in a file (\(d\)) is calculated by multiplying the term frequency (\(tf\)) and inverse document frequency (\(idf\)) values, as presented in Equation (1). Term frequency is calculated by dividing the number of occurrences (\(f\)) of an n-gram in a file by the sum of the number of occurrences of the other n-grams in the same file. Inverse document frequency is calculated by adding the constant 1 to a logarithm of the ratio of the total number of files (\(n\)) to the number of files containing the n-gram (\(df\)). In order to prevent zero division, a constant 1 value is added to the numerator and the denominator of the logarithm, which is a widely accepted practice. The TF-IDF value presented in Equation (1) is the raw weight of an n-gram in a file. In order to represent a file in a vector form, the TF-IDF values of all of the n-grams in the file need to be calculated. The obtained vector is normalized by the Euclidean (L2) norm, as presented in Equation (2).